Surprising little issue

[Eric Chatonet]

Hi Scott,

I agree: as fields, buttons should have a "sharedText" property.
I did not find anything about such an enhancement request in Bugzilla.
But I think you have imagined the right solution yet :-)

on preOpenCard -- in the stack's script
   local tCurComboMenuHistory
   -----
   if there is a btn "MyCombo" then
     put the uCurComboMenuHistory of this card into tCurComboMenuHistory
     if tCurComboMenuHistory is an integer then
       set the menuHistory of btn "MyCombo" to tCurComboMenuHistory
     else set the menuHistory of btn "MyCombo" to 1
   end if
end preOpenCard

On the other hand:

on menuPick pItem
   <Statements>
   set the uCurComboMenuHistory of this card to the menuHistory of me
end menuPick

Le 24 nov. 06 à 09:40, Scott Kane a écrit :

> OK.  I know Rev is a little different.  But when programming using  
> combo boxes I kind of expected the selected contents of a combo box  
> on a card to pertain only to the card the selection was made on in  
> a multi-card stack. However it seems that, unlike fields, this  
> isn't the case and once selected the option carries over to all  
> cards in the stack.  So...  I assume I could trap the menu pick and  
> store it somewhere - a custom property or something like that, but  
> is there a better way to trap the selection so that each card shows  
> a selection according to what the user wants for that card?  (this  
> is a card with the contents set as a background object).


Best Regards from Paris,
Eric Chatonet
------------------------------------------------------------------------ 
----------------------
http://www.sosmartsoftware.com/    eric.chatonet at sosmartsoftware.com/