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<tabname>" 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 <proth...@earthednet.org> 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. Hmmmm... Many paths to nirvana. > > Best, > Bill > > William Prothero > http://es.earthednet.org > >> On Nov 8, 2015, at 6:33 AM, "Peter M. Brigham" <pmb...@gmail.com> 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
