Bug???? Discuss please!

Mark Smith mark at maseurope.net
Wed Nov 15 10:56:07 EST 2006 

 From the docs: "If the field is a card field (not part of a group),  
its sharedText property has no effect."

Which we now know is not strictly true. Which suggests that what  
we're seeing is some kind of side-effect, so maybe not to be relied  
upon.

Best,

Mark

On 15 Nov 2006, at 15:46, Dave wrote:

> Hi,
>
> I just dug up the test stack and verified that EITHER the Shared  
> Text property OR using the long id form of the reference works. e.g.
>
> If sharedText = false then
>     put "XXX" into me
> else
>     set the text of the long id of me to "XXX"
> end if
>
> works ok if sharedText = true or false. If course the:
>
>     set the text of the long id of me to "XXX"
>
> works regardless of the setting of sharedText, but is slower.
>
> It's really difficult to know what to do for the best here. Is this  
> a side-effected action of sharedText or it be relied on to work  
> forever? Or should I go for the long hand safer (hopefully?) code  
> that runs slower? If I have to design 50 windows for an application  
> it's a question I think I would like to know the answer to before  
> doing much coding!
>
> All the Best
> Dave
> ---------------------------------
>
> Hi,
>
> The secret was revealed by finding out that if you set the "shared  
> text" property of the field all works ok, e.g. put "x" into me work  
> as expected, there seems to be a "ghost" context in which "me" is  
> not actually me, or the context gets restored back to it's former  
> state IF the shared text property is off. However I'm not sure if  
> the shared text property is just causing a side-effect that may  
> well change in future releases so I have used the long hand form  
> (which takes longer to execute.
>
> Which version of RunRev are you using and which platform(s)??
>
> On 15 Nov 2006, at 14:40, Mark Smith wrote:
>
>> If I add "select the text of me" to the script of the field on cd  
>> 2, and I press the button on cd 1, I get this error:
>>
>> Chunk: can't select object that isn't open
>>
>> Which is perhaps some sort of clue. However, if there is some text  
>> in the field on cd 2, and you change it's script to
>> on messageY
>>   put me
>> end messageY
>>
>> press the button on cd 1 and it happily puts it's contents into  
>> the message box.
>>
>> So it seems hard to see exactly when we can use "me" and when we  
>> can't.
>> It seems to work in accessing a closed objects own properties --  
>> the long id of me, in your work around -- but not in setting them.
>>
>> However, if we now change the on messageY handler to
>>
>> set the height of me to the height of me * 2
>>
>> and press the button on cd 1, go to cd 2, the field is twice as tall!
>>
>> So that theory goes out the window!
>>
>> Perhaps this "me" trouble is confined to the text of fields?
>>
>> Whether or not this is a bug, it seems to me an ideal subject for  
>> some sort of Wiki - I don't know if RunRev have theirs up and  
>> running, yet. They didn't, last time I looked.
>>
>> I also think there may be a good argument for having special  
>> sections in the Docs that deal with these "me", "it", "the result"  
>> words, which do seem to get confusing, at times.
>
> yes, and add something on the shared text property too.
>
>
>>
>> Best,
>>
>> Mark
>
> Cheers
> Dave
>>
>>
>> On 15 Nov 2006, at 13:55, Dave wrote:
>>
>>> Hi,
>>>
>>> I thought I'd re-visit this as people seem to be in the mood for  
>>> bug fixing or changing documentation. How should this be filed?  
>>> I'm really not sure what needs to be changed, I have listed the  
>>> work arounds I have found at the end. I would suggest that at the  
>>> very least this is mentioned in the PDF and the Online Docs.
>>>
>>> All the Best
>>> Dave
>>>
>>> -------------------------------------------------------------------- 
>>> -------------------------------------------------------
>>> I have a Stack, StackMain.
>>>
>>> In StackMain Card 1, I do:
>>>
>>> -- On a field
>>> on MessageX
>>> put "MessageX" into me
>>> end MessageX
>>>
>>> -- on a button
>>> on mouseUp
>>> send "MessageX" to field 1 of card 1 of  stack "StackMain"
>>> send "MessageY" to field 1 of card 2 of  stack "StackMain"
>>> end mouseUp
>>>
>>>
>>> In StackMain Card 2 I do:
>>>
>>> --On a field
>>> on MessageY
>>> put "MessageY" into me
>>> end MessageY
>>>
>>> --on a button
>>> on mouseUp
>>> send "MessageY" to field 1 of card 2 of  stack "StackMain"
>>> end mouseUp
>>>
>>>
>>> If I press the button on Card 1, then MessageX gets called in  
>>> Card 1 ok and the field gets set to "MessageX". All is fine.  
>>> MessageY in Card 2 field 1 gets called ok too, BUT the field is  
>>> NOT set to "MessageY" as expected????? However if I select card 2  
>>> and then press the button in Card 2, again the MessageY in Card 2  
>>> field 1 gets called AND the field is set ok. All is fine.
>>>
>>> It seems like the following path does not work:
>>>
>>> Card 1:Button 1:mouseUp -->Card2:field 1:MessageY does not work.
>>>
>>> But
>>>
>>> Card 2:Button 1:mouseUp -->Card2:field1:MessageY works fine.
>>>
>>> The weird thing is that the handlers do get called and I have  
>>> stepped over the statement that does:
>>> put "MessageY" into me and that seems to work. However, when you  
>>> select card 2, the field has not been changed.
>>>
>>> -------------------------------------------------------------------- 
>>> -----------------------------------------------
>>> KNOWN WORK-AROUNDS:
>>> -------------------------------------------------------------------- 
>>> -----------------------------------------------
>>> 1. Instead of using the form:
>>>
>>> put "MessageY" into me
>>>
>>> Use:
>>>
>>> set the text of the long id of me to "MessageY"
>>>
>>> 2.  Set the Shared Text Property in the property inspector of the  
>>> field.
>>>
>>> Easy to solve, VERY HARD to TRACK DOWN!!!!!!!!!!!!!!!!!!!!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

More information about the use-livecode mailing list