store and compare data in variable?

[tusa]

It might be simple, but right now i'm totaly blank, hopefully som of you guys can get me on the right track?

When I click a button, I want to show a group of fields, buttons, text etc. and want to hide the previous group.
Right now I can show the group:

Code: Select all

on mouseUp
   show group INDSTILLINGER
end mouseUp

I thought it would be easy to store the group name in a variable and the previous stored group name in the the variable.

Code: Select all

on mouseUp
   show group INDSTILLINGER
   put "Indstillinger" into previousMenu
end mouseUp

But how do I get the data from the variable?

Code: Select all

hide group ????

[dunbarx]

Hi.

You are storing the name of the visible group in a local variable. That variable is discarded by the engine as soon as the handler ends.

You need to store it into something that persists between handlers. This could be a global variable, a custom property or a field. I recommend a custom property.

Code: Select all

on mouseUp
  show group "whatever"
  set the lastVisibleControl of this card to the name of group "whatever"
end mouseUp

Does the other mouseUp handler reside in the script of the same control? In other words, is your second "mouseUp" handler in the same button?

I assume not, so that in the handler of the other button:

Code: Select all

on mouseUp
  hide group the lastVisibleControl of this card
 show group "someNewGroup"
end mouseUp

And do watch out; you need to use quotes to frame your control references.

Craig Newman

[tusa]

Now it works:

Code: Select all

on mouseUp
   show group "AFVIKLING"
   if lastVisibleControl is not "AFVIKLING" then
      hide group the lastVisibleControl of this card
   end if
   set the lastVisibleControl of this card to "AFVIKLING"
end mouseUp

But how can i prevent that when I push the button again, it hides the group?
I tried with the if statement, but i does'nt seem to work?

[dunbarx]

We can do this, but I am a little confused.

Are you using the word "lastVisibleControl" as both the name of a variable AND the name of a custom property? It seems so, and therefore I do not see how your handler can work, at least as the snippet is written.

Another important thing to know is that sometimes a little analysis is worth a million lines of code. What I mean by that is: are there only two groups? If so, why not:

Code: Select all

on mouseUp
if the visible of grp "firstGroup" then
    hide grp "firstGroup"
    show grp "secondGroup"
  else
    hide grp "secondGroup"
    show grp "firstGroupGroup"
end if

But if there are more than two, this just will not work at all. I just want to tell you to stop and think of other ways to work now and then.

So, how many groups? If many, we still need to save the currently visible one in a custom property, but then need to figure out what the next one to be shown ought to be.

Craig

[hpsh]

just wonder if something like this can help?

script under a pulldown or option menu

Code: Select all

on mouseUp
   local mString,mVal
   put the menuhistory of me into mVal
   repeat for each line tLine in me
      hide grp tLine
   end repeat
   put line mVal of me into mString
   show grp mString
end mouseUp

just make the text in the pulldownmenu to

Code: Select all

AFVIKLING
INDSTILLINGER

[dunbarx]

HPSH is thinking along different lines, just as I mentioned. Bravo.

I often get stuck somewhere, and have to force myself to think "what if I rethink the whole thing?" This is hard sometimes, because of the investment in time and energy one often makes going down a particular road.

But why not simplify that offering:

Code: Select all

on mouseUp
   repeat for each line tLine in me
      hide grp  tLine
   end repeat
     show grp selectedText of me
end mouseUp

Now this becomes cumbersome if the number of groups is large, because the list in the menu button becomes unwieldy. Did I mention that I would like to know how many groups you have? And also important, how many you might possible ever have?

Craig

[jacque]

You need to store it into something that persists between handlers. This could be a global variable, a custom property or a field. I recommend a custom property.

Script local variables are my preferred method for this if the handlers are all in the same script. Properties have to be managed to ensure they don't retain old information on the next launch, because they are persistent. It's too easy to introduce errors that way. Script locals take care of themselves without any babysitting.

[jacque]

Are you using the word "lastVisibleControl" as both the name of a variable AND the name of a custom property? It seems so, and therefore I do not see how your handler can work, at least as the snippet is written.

In this case the syntax defines the usage. But you're right it would be clearer to use different names and would make the script easier to understand later.

[hpsh]

HPSH is thinking along different lines, just as I mentioned. Bravo.

I often get stuck somewhere, and have to force myself to think "what if I rethink the whole thing?" This is hard sometimes, because of the investment in time and energy one often makes going down a particular road.

well, its helps sometimes to be old and strange

look at you script, and it looks like you also can do it with a scrolling list field, something my script didn't do, and it looks that better for me.

if its many choices, i think i would make a temporary scrolling field, put the names in the group in there, and make a button with a script to transfer the choices from the temporally field to a scrolling list field, and then delete the button and the temporally field.

but somehow, i don't think it will be that big, its almost the same language as my first language.

just hits me one thing here, i wonder if this situation would be better fixed with more cards, then to make object visible or invisible, at least INDSTILLINGER (setup) seems to me something to put on a separate card.

[dunbarx]

@ Jacque.

Love script locals.

But the OP, in the first instance, had TWO mouseUp handlers. I assumed they had to either reside in two separate buttons, or he was just illustrating a need. Anyway, neither scenario would support script locals.

Also, in the "AFVIKLING" handler, the OP had, perhaps, made the variable either global or script local. But that was not evident in the handler, and I said what I did because there was no obvious way that variable contained any content. Of course, for that matter, the custom property similarly was either empty or loaded elsewhere.

@ Tusa. You see we are struggling with your precise needs. And it is indeed difficult to precisely communicate these in a text-based forum. So might you address some of the points raised by all:

- How many groups right now? How many might there ever, ever be? Oftentimes, this is not even knowable.
- How do you want to do this selecting thing?
- What is your opinion of the several methods so far? Have you tried any right out of the box?
- Where are you now in this effort?

Craig

[tusa]

For now I have 5 groups, but I need 2 more.
I did'nt have time to try it out yet.

[sturgis]

In the case of multiple mouseups that do generally the same thing I move the main handler to the card or stack and then call that one with a passed parameter.

2 buttons both alike each with the handler

Code: Select all

on mouseup
  switchgroups "mygroup1"
end mouseup

on mouseup
  switchgroups "mygroup2"
end mouseup

And on the card

Code: Select all

local sCurrentGroup -- can hold the name of the currently visible group
command switchgroups pVar
   lock screen -- could use a visual effect when unlocking screen..

   if pVar is sCurrentGroup or sCurrentGroup is empty then
      -- since this may be the first time through, make sure the group is showing. 
      set the visible of grp pVar to true -- has no effect if the group is already visible
      put pVar into sCurrentGroup
      unlock screen -- probably not necessary but if we exit here, it'd bug me to have an unbalanced lock screen pair
      exit switchgroups -- when trying to show the same group again or to show the first group, confirm the right group is showing as above and then exit the handler
   end if
   set the visible of grp pVar to true
   set the visible of grp sCurrentGroup to false
   put pVar into sCurrentGroup 
   unlock screen
end switchgroups