Tab control-multiple cards or hidden groups?
bobsneidar at iotecdigital.com
Mon Nov 9 12:11:14 EST 2015
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
> On Nov 8, 2015, at 07:37 , Earthednet-wp <prothero at 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.
> William Prothero
>> On Nov 8, 2015, at 6:33 AM, "Peter M. Brigham" <pmbrig at 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
>> pmbrig at gmail.com
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode