pos / neg on a button/checkbox

[BvG]

Ah i see now. I thought you had created a fake checkbox button from scratch, using mouseUp, other mouse messages and setting the icon. but instead you simply used the hilitedicon and depended on the built in behaviours.

I still say you should not use two custom buttons, but instead three option buttons: yes,no and unanswered (or 'not applicable' or whatever)

[sylvanr]

Thanks! This is the second big "bug" I have encountered while using LiveCode and glad the "bugs" are getting fixed. The best thing is knowing when there IS a "bug" because otherwise, I just keep trying things, trying to figure out what I'm doing wrong. Thank-you, thank-you, thank-you.

Do we know when the next version is coming out?

Another question has come up in the meantime. It is really the same question as I had previously about the "radio" buttons and the "checkboxes" which was resolved with deselecting "shared hilite" but pertains to the "option" button that allows you to create a list of choices. In LiveCode these buttons create a pop-up of choices from which the end user can select. When put into the simulator, the pop-up is replaced with the click wheel which I love, BUT whatever choice is made, it is that choice on ALL the cards in the stack, rather than just on the individual card. There is no "shared hilite" to deselect? Is there a way to have the selection just show up on individual cards in the stack or do you think this is also a bug??

[bn]

Hi Sylvan,

I dont know if the option menu should behave like you expect it.

A solution is to do this:
in the stack script

Code: Select all

on closeCard
   set the cHistoryOfOptionMenu of this card to the menuhistory of btn "om"
end closeCard

on preopencard
   put the cHistoryOfOptionMenu of this card into tHistory
   if tHistory is not "" then 
      set the menuhistory of btn "om" to the cHistoryOfOptionMenu of this card
   end if
end preopencard

assuming your option menu btn is called "om" and is on all cards if it is only on cards that share the same background and you have cards without the background I would place this in the background script. You create a custom property of the card when leaving the card with the state of the option menu button. When going to another card it reads the custom property and sets the state of the option menu button on the fly. Did work in limited testing on iOS and desktop.

As it looks now the bug is fixed for the desktop, not yet for iOS. Will keep you posted.

Kind regards

[sylvanr]

A workaround for now would be to not set the background behavior of the radio group and copy the group on each new card.

Code: Select all

on newcard
   lock screen
   copy grp "rBtns" of card 1 to this card
end newcard

Hey Bernd,
I have been playing with this script as it seems like it would be a solution but unable to get it to work. I tried it as a button script for when I add a new card and I tried it as a stack script. Since "this card" does not exist until the user clicks an "add card" button, I'm confused as to where the script goes? In the button script? In the stack script?

[bn]

Hi Sylvan,

Code: Select all

on newcard
   lock screen
   copy grp "rBtns" of card 1 to this card
end newcard

put this script into the script of of the stack. It worked for me that way. When you get the newCard message the new card exists.
When the user clicks the button that adds a new card that triggers the newCard message. But the group with the radio buttons will be outside of a background group, which is the whole purpose of the exercise. Then you can set the radio buttons for each card separately.

Kind regards

Bernd

[sylvanr]

I got it to work and it works great! Thank you again, Bernd. You are brilliant!

I did have one problem with it, though, which I have some ideas about. When the user opens this app, and adds a new card, all the choice buttons are in their initial state and the new card will copy and paste them in that state, BUT, if the user makes choices on that FIRST card, where the group of buttons reside, then the buttons are copied in that modified state and pasted on the new cards with those first choices. Since I want each card to start with an "initialized" state with the initial choice state, before the user has taken any action and made their choice, I am thinking that maybe a need another, identical group of buttons hidden somewhere- maybe behind the background?? Then the first card can have the modifiable set of buttons in the foreground which will not get copied to paste to new cards. Or is there a better way to accomplish this?? ... a way to initialize the choice buttons back to their original state each time they are copied and pasted onto new cards? I will play with it today and see what I can do with "hiding" a clean set but if you have any advise on this, it is always appreciated! Thanks again for everything!

BTW, my first little app is in the Apple Store: http://itunes.apple.com/us/app/student- ... 43776?mt=8

[bn]

Hi Sylvan,

BTW, my first little app is in the Apple Store

Now that is fantastic. Congratulations.

I downloaded it and felt right at home

.. a way to initialize the choice buttons back to their original state each time they are copied and pasted onto new cards?

Code: Select all

on newcard
   lock screen
   copy grp "rBtns" of card 1 to this card
   repeat with i = 1 to the number of btns of grp "rBtns"
      set the hilite of btn i of grp "rBtns" to false
   end repeat
end newcard

This works for me.

May I humbly make you aware of a stack that makes buttons for the iPhone?
http://forums.runrev.com/phpBB2/viewtop ... t=+buttons

Kind regards

Bernd

[sylvanr]

Regarding:

on newcard
lock screen
copy grp "rBtns" of card 1 to this card
repeat with i = 1 to the number of btns of grp "rBtns"
set the hilite of btn i of grp "rBtns" to false
end repeat
end newcard

Bernd,
I added the
repeat with i = 1 to the number of btns of grp "rBtns"
set the hilite of btn i of grp "rBtns" to false
end repeat

but then the app quit copying the buttons to the new card altogether. I have played around with this but wondering if it might be due my using "option menu" buttons? These "option menu" buttons contain lists of choices for the end user so they are not in just a true or false state? Should they work anyway or is there a different state that I should be using other than "false?" Is there a way to have each button default to "menuitem 1" of if each "choice menu" button could be rolled back to "no choice made" at the top position of the list that pops up. Is the state of an "option menu" still considered a "hilite" or something else? Is there a variation of what you suggested that might work?? I will keep playing with it in the meantime.. maybe change "false" to "no choice made??" Any thoughts? Thanks for the hundredth time!

Addendum- I finally went back to the idea of having a duplicate group of buttons on the first card for the user to enter choices. Hidden behind that, is my set of identical buttons which are the ones that get copied in the "default" state. This seems to work fine but still curious if there is a way to set choice menu buttons to a default?

[bn]

Hi Sylvan,

I thought you were using radio buttons. To avoid all problems go the way you describe: have a pristine version of the buttons group hidden and copy it to a new card.

If you want to use a option-menu button then you would set the menuhistory of the button. If you change the menuhistory of an option-menug button by script you also trigger a menupick event. To avoid that you set the lockmessages to true before setting the menuhistory and then set the lockmessages to false afterwards, like

Code: Select all

lock messages
   set the menuhistory of btn "myOptionMenuButton" to 1
   -- and so on
unlock messages

if of course you want to trigger the menupick then you leave out the lock messages

menuhistory -> dictionary
lock messages -> dictionary
lockmessages -> dictionary

kind regards

Bernd

[sylvanr]

Thanks, Bernd!

[sylvanr]

How about a "quit" button?? If I have button with the following script, shouldn't it quit the app and take the user back to the springboard?

on mouseup
quit
end mouseup

For some reason, on the iPhone, it just takes the user to a black screen rather than back to the springboard? Is this a bug or am I missing something?

[bn]

Hi Sylvan,

in iOS there is no concept of quit. You quit the app by pressing the button on the device.

If you want to return to your start stack you would issue a "go stack "nameOfYourStack"

Kind regards

Bernd