Re: Tab control-multiple cards or hidden groups?

[James Hale]

Thanks you all for your thoughtful replies.

@Paul Yes this is the direction my thinking has been heading. I think when I 
first toyed with this I didn't really find the application browser accessible 
(in a meaningful way to me) and thought multiple groups just too messy. But 
with the Project Browser and use of other plugins (lcStackBrowser and 
flcControlManager, both excellent alternatives) the overwhelming aspect of 
multiple groupings on a single card are no longer there.

@Peter Thanks for the example of the picker to use should I go this way.

@Bill Thankfully I do not have shifting fields between my tabs. Where a field 
is shared (well duplicated at this time) it is located basically in the same 
place. The coding side might take me a bit to get my head around in bringing 
all the individual cards scripts into one. open card handlers will need to be 
rewritten as well as ensuring no clashes in variables that were local within 
the confines of one script now having to share that same domain. I guess the 
upside is that there will be room to economize.

@Mike That is how I originally thought. It just seemed simpler to have multiple 
cards. It is only now after reading the initial thread and realising the 
maintenance of all these seperate cards scripts might not be the optimal 
approach.

@Scott Thankfully my app does not have hundreds of controls. And although they 
do probably number in the dozens the ability to show/hide them by a click in 
the appropriate browser makes that management well, manageable.

I am more convinced this is worth pursuing/exploring.


James




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Bob Sneidar]

I have a separate group of controls for each tab, and by group I really mean 
"group". This way I just have the selectionChanged handler in the tab object 
show and hide the corresponding group. In fact I name each group "grp" 
so if for example I am showing the sites group:

on selectionChanged pTab
   put "grp" & pTab  into tGroup
   show group tGroup
   -- loop to hide other groups
end selectionChanged

Bob S


> On Nov 8, 2015, at 07:37 , Earthednet-wp  wrote:
> 
> I've recently started doing this also, for a student/instructor login system. 
> Depending on who is logging in, some of the input fields and buttons are 
> different, and there may be multiple steps to the login and registration 
> process. The main complication is that some buttons and fields need to be in 
> different places in each group. Rather than write code to reposition them, I 
> use controls with the same name, but in different locations in groups. The 
> name of a field is important, as it corresponds to a field name on a remote 
> database. This means I have to do some extra coding to make sure I get the 
> field (which may have the same name as another field in another group) that 
> is in the group that's showing when I get or set its contents. Ultimately, 
> I'm hoping this makes the interaction between text fields and my MySQL db 
> pretty seamless.
> 
> Anyway, I think this makes the organization nicer. I could probably simplify 
> it if I used custom properties, though. H... Many paths to nirvana.
> 
> Best,
> Bill
> 
> William Prothero
> http://es.earthednet.org
> 
>> On Nov 8, 2015, at 6:33 AM, "Peter M. Brigham"  wrote:
>> 
>>> On Nov 8, 2015, at 8:02 AM, Paul Dupuis wrote:
>>> 
 On 11/8/2015 7:27 AM, James Hale wrote:
 Recently there was some discussion concerning the use of hidden groups 
 with the tab control. An app I am working on currently uses a tab control 
 with five tabs that currently go to different cards. The cards concerned 
 all share a number of other controls responsible for about 60% of their 
 area with the tabbed panel taking the rest. Some of the panels are simply 
 variations of another (e.g. Simple vs complex search).
 I am now wondering whether there would be an advantage in reducing these 
 five cards down to one and use the hidden group method.
 Given I am not starting from scratch my question is, would there be 
 advantages to me in making this transition?
 So for those of you employing this method, why do you?
 Is it having a single card script?
 Is it keeping the stack structure simple?
 Is it...?
 I would be very interested in your thoughts.
>>> 
>>> I use a single card and multiple groups when the majority of the UI is
>>> (or will be) the same - i.e there would be a lot of common controls on
>>> different cards
>>> 
>>> I use multiple cards when the UI for each card is substantially different.
>>> 
>>> So it is basically a linear scale with tabbed groups being on one end
>>> where there a lot of common UI elements and tabbed cards being on the
>>> other end with little common UI elements. Where the dividing line is is
>>> probably a matter of personal preference. Organization of handlers plays
>>> a role in the choice as well. Recently, I have been leaning more towards
>>> multiple groups as I find accessing the objects and scripts in the IDE
>>> via the Application Browser a bit easier.
>> 
>> I do the same. If you go with the multiple groups/one card solution, an easy 
>> way of managing the clicks in the tab button is something like this:
>> 
>> on showGroup tGroup
>>  put "group1,group2,group3,group4" into gpList
>>  repeat for each item i in gpList
>> set the visible of group i to (i = tGroup)
>>  end repeat
>> end showGroup
>> 
>> and if the group names are the same as the tab labels, it's quite 
>> straightforward:
>> 
>> on menuPick pItemName
>>  showGroup pItemName
>> end menuPick
>> 
>> -- Peter
>> 
>> Peter M. Brigham
>> pmb...@gmail.com
>> http://home.comcast.net/~pmbrig
>> 
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Peter M. Brigham]

On Nov 8, 2015, at 8:02 AM, Paul Dupuis wrote:

> On 11/8/2015 7:27 AM, James Hale wrote:
>> Recently there was some discussion concerning the use of hidden groups with 
>> the tab control. An app I am working on currently uses a tab control with 
>> five tabs that currently go to different cards. The cards concerned all 
>> share a number of other controls responsible for about 60% of their area 
>> with the tabbed panel taking the rest. Some of the panels are simply 
>> variations of another (e.g. Simple vs complex search).
>> I am now wondering whether there would be an advantage in reducing these 
>> five cards down to one and use the hidden group method.
>> Given I am not starting from scratch my question is, would there be 
>> advantages to me in making this transition?
>> So for those of you employing this method, why do you?
>> Is it having a single card script?
>> Is it keeping the stack structure simple?
>> Is it...?
>> I would be very interested in your thoughts.
>> 
> 
> I use a single card and multiple groups when the majority of the UI is
> (or will be) the same - i.e there would be a lot of common controls on
> different cards
> 
> I use multiple cards when the UI for each card is substantially different.
> 
> So it is basically a linear scale with tabbed groups being on one end
> where there a lot of common UI elements and tabbed cards being on the
> other end with little common UI elements. Where the dividing line is is
> probably a matter of personal preference. Organization of handlers plays
> a role in the choice as well. Recently, I have been leaning more towards
> multiple groups as I find accessing the objects and scripts in the IDE
> via the Application Browser a bit easier.

I do the same. If you go with the multiple groups/one card solution, an easy 
way of managing the clicks in the tab button is something like this:

on showGroup tGroup
   put "group1,group2,group3,group4" into gpList
   repeat for each item i in gpList
  set the visible of group i to (i = tGroup)
   end repeat
end showGroup

and if the group names are the same as the tab labels, it's quite 
straightforward:

on menuPick pItemName
   showGroup pItemName
end menuPick

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Earthednet-wp]

I've recently started doing this also, for a student/instructor login system. 
Depending on who is logging in, some of the input fields and buttons are 
different, and there may be multiple steps to the login and registration 
process. The main complication is that some buttons and fields need to be in 
different places in each group. Rather than write code to reposition them, I 
use controls with the same name, but in different locations in groups. The name 
of a field is important, as it corresponds to a field name on a remote 
database. This means I have to do some extra coding to make sure I get the 
field (which may have the same name as another field in another group) that is 
in the group that's showing when I get or set its contents. Ultimately, I'm 
hoping this makes the interaction between text fields and my MySQL db pretty 
seamless.

Anyway, I think this makes the organization nicer. I could probably simplify it 
if I used custom properties, though. H... Many paths to nirvana.

Best,
Bill

William Prothero
http://es.earthednet.org

> On Nov 8, 2015, at 6:33 AM, "Peter M. Brigham"  wrote:
> 
>> On Nov 8, 2015, at 8:02 AM, Paul Dupuis wrote:
>> 
>>> On 11/8/2015 7:27 AM, James Hale wrote:
>>> Recently there was some discussion concerning the use of hidden groups with 
>>> the tab control. An app I am working on currently uses a tab control with 
>>> five tabs that currently go to different cards. The cards concerned all 
>>> share a number of other controls responsible for about 60% of their area 
>>> with the tabbed panel taking the rest. Some of the panels are simply 
>>> variations of another (e.g. Simple vs complex search).
>>> I am now wondering whether there would be an advantage in reducing these 
>>> five cards down to one and use the hidden group method.
>>> Given I am not starting from scratch my question is, would there be 
>>> advantages to me in making this transition?
>>> So for those of you employing this method, why do you?
>>> Is it having a single card script?
>>> Is it keeping the stack structure simple?
>>> Is it...?
>>> I would be very interested in your thoughts.
>> 
>> I use a single card and multiple groups when the majority of the UI is
>> (or will be) the same - i.e there would be a lot of common controls on
>> different cards
>> 
>> I use multiple cards when the UI for each card is substantially different.
>> 
>> So it is basically a linear scale with tabbed groups being on one end
>> where there a lot of common UI elements and tabbed cards being on the
>> other end with little common UI elements. Where the dividing line is is
>> probably a matter of personal preference. Organization of handlers plays
>> a role in the choice as well. Recently, I have been leaning more towards
>> multiple groups as I find accessing the objects and scripts in the IDE
>> via the Application Browser a bit easier.
> 
> I do the same. If you go with the multiple groups/one card solution, an easy 
> way of managing the clicks in the tab button is something like this:
> 
> on showGroup tGroup
>   put "group1,group2,group3,group4" into gpList
>   repeat for each item i in gpList
>  set the visible of group i to (i = tGroup)
>   end repeat
> end showGroup
> 
> and if the group names are the same as the tab labels, it's quite 
> straightforward:
> 
> on menuPick pItemName
>   showGroup pItemName
> end menuPick
> 
> -- Peter
> 
> Peter M. Brigham
> pmb...@gmail.com
> http://home.comcast.net/~pmbrig
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Mike Kerner]

I go completely the other way.  I've frequently thought about the many
groups one card method, but I like the mechanics of dealing with the
controls better when I have them over multiple cards (not to mention it's
easier to keep it all straight in my brane).  The only time I have multiple
groups on a card that I show and hide is when I have subcontrols specific
to a particular control that I want to bring up.  For example, I have a
barcode scanner and its related controls on an inventory detail card.

Generally, unless the vast majority of controls are going to remain in
place, I use a different card.

On Sun, Nov 8, 2015 at 10:37 AM, Earthednet-wp 
wrote:

> I've recently started doing this also, for a student/instructor login
> system. Depending on who is logging in, some of the input fields and
> buttons are different, and there may be multiple steps to the login and
> registration process. The main complication is that some buttons and fields
> need to be in different places in each group. Rather than write code to
> reposition them, I use controls with the same name, but in different
> locations in groups. The name of a field is important, as it corresponds to
> a field name on a remote database. This means I have to do some extra
> coding to make sure I get the field (which may have the same name as
> another field in another group) that is in the group that's showing when I
> get or set its contents. Ultimately, I'm hoping this makes the interaction
> between text fields and my MySQL db pretty seamless.
>
> Anyway, I think this makes the organization nicer. I could probably
> simplify it if I used custom properties, though. H... Many paths to
> nirvana.
>
> Best,
> Bill
>
> William Prothero
> http://es.earthednet.org
>
> > On Nov 8, 2015, at 6:33 AM, "Peter M. Brigham"  wrote:
> >
> >> On Nov 8, 2015, at 8:02 AM, Paul Dupuis wrote:
> >>
> >>> On 11/8/2015 7:27 AM, James Hale wrote:
> >>> Recently there was some discussion concerning the use of hidden groups
> with the tab control. An app I am working on currently uses a tab control
> with five tabs that currently go to different cards. The cards concerned
> all share a number of other controls responsible for about 60% of their
> area with the tabbed panel taking the rest. Some of the panels are simply
> variations of another (e.g. Simple vs complex search).
> >>> I am now wondering whether there would be an advantage in reducing
> these five cards down to one and use the hidden group method.
> >>> Given I am not starting from scratch my question is, would there be
> advantages to me in making this transition?
> >>> So for those of you employing this method, why do you?
> >>> Is it having a single card script?
> >>> Is it keeping the stack structure simple?
> >>> Is it...?
> >>> I would be very interested in your thoughts.
> >>
> >> I use a single card and multiple groups when the majority of the UI is
> >> (or will be) the same - i.e there would be a lot of common controls on
> >> different cards
> >>
> >> I use multiple cards when the UI for each card is substantially
> different.
> >>
> >> So it is basically a linear scale with tabbed groups being on one end
> >> where there a lot of common UI elements and tabbed cards being on the
> >> other end with little common UI elements. Where the dividing line is is
> >> probably a matter of personal preference. Organization of handlers plays
> >> a role in the choice as well. Recently, I have been leaning more towards
> >> multiple groups as I find accessing the objects and scripts in the IDE
> >> via the Application Browser a bit easier.
> >
> > I do the same. If you go with the multiple groups/one card solution, an
> easy way of managing the clicks in the tab button is something like this:
> >
> > on showGroup tGroup
> >   put "group1,group2,group3,group4" into gpList
> >   repeat for each item i in gpList
> >  set the visible of group i to (i = tGroup)
> >   end repeat
> > end showGroup
> >
> > and if the group names are the same as the tab labels, it's quite
> straightforward:
> >
> > on menuPick pItemName
> >   showGroup pItemName
> > end menuPick
> >
> > -- Peter
> >
> > Peter M. Brigham
> > pmb...@gmail.com
> > http://home.comcast.net/~pmbrig
> >
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   

Tab control-multiple cards or hidden groups?

[James Hale]

Recently there was some discussion concerning the use of hidden groups with the 
tab control. An app I am working on currently uses a tab control with five tabs 
that currently go to different cards. The cards concerned all share a number of 
other controls responsible for about 60% of their area with the tabbed panel 
taking the rest. Some of the panels are simply variations of another (e.g. 
Simple vs complex search).
I am now wondering whether there would be an advantage in reducing these five 
cards down to one and use the hidden group method.
Given I am not starting from scratch my question is, would there be advantages 
to me in making this transition?
So for those of you employing this method, why do you?
Is it having a single card script?
Is it keeping the stack structure simple?
Is it...?
I would be very interested in your thoughts.

James
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Paul Dupuis]

On 11/8/2015 7:27 AM, James Hale wrote:
> Recently there was some discussion concerning the use of hidden groups with 
> the tab control. An app I am working on currently uses a tab control with 
> five tabs that currently go to different cards. The cards concerned all share 
> a number of other controls responsible for about 60% of their area with the 
> tabbed panel taking the rest. Some of the panels are simply variations of 
> another (e.g. Simple vs complex search).
> I am now wondering whether there would be an advantage in reducing these five 
> cards down to one and use the hidden group method.
> Given I am not starting from scratch my question is, would there be 
> advantages to me in making this transition?
> So for those of you employing this method, why do you?
> Is it having a single card script?
> Is it keeping the stack structure simple?
> Is it...?
> I would be very interested in your thoughts.
>

I use a single card and multiple groups when the majority of the UI is
(or will be) the same - i.e there would be a lot of common controls on
different cards

I use multiple cards when the UI for each card is substantially different.

So it is basically a linear scale with tabbed groups being on one end
where there a lot of common UI elements and tabbed cards being on the
other end with little common UI elements. Where the dividing line is is
probably a matter of personal preference. Organization of handlers plays
a role in the choice as well. Recently, I have been leaning more towards
multiple groups as I find accessing the objects and scripts in the IDE
via the Application Browser a bit easier.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tab control-multiple cards or hidden groups?

[Scott Rossi]

In addition to what others have said, another issue can develop with
multiple groups on a single card when you have to work with the groups
visually.  Having dozens (hundreds) of controls present can sometimes make
editing challenging.  Placing the tabbed groups across multiple cards
encapsulates them nicely.  But this might be more of an extreme case than
yours.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 11/8/15, 4:27 AM, "use-livecode on behalf of James Hale"

wrote:

>Recently there was some discussion concerning the use of hidden groups
>with the tab control. An app I am working on currently uses a tab control
>with five tabs that currently go to different cards. The cards concerned
>all share a number of other controls responsible for about 60% of their
>area with the tabbed panel taking the rest. Some of the panels are simply
>variations of another (e.g. Simple vs complex search).
>I am now wondering whether there would be an advantage in reducing these
>five cards down to one and use the hidden group method.
>Given I am not starting from scratch my question is, would there be
>advantages to me in making this transition?
>So for those of you employing this method, why do you?
>Is it having a single card script?
>Is it keeping the stack structure simple?
>Is it...?
>I would be very interested in your thoughts.
>
>James
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode