Weird button behavior

Peter Haworth pete at mollysrevenge.com
Sun Feb 6 02:01:50 EST 2011


Thanks for the tips.  The breakpoint statement sounds useful, although in this case, I never would have guessed where to put the breakpoint.  Unfortunately, they way my code is constructed, the offending statement didn't get executed unless the card was modal.  I guess that's another thing to watch out for.

Pete Haworth

On Feb 5, 2011, at 9:45 PM, J. Landman Gay wrote:

> On 2/5/11 5:31 PM, Peter Haworth wrote:
>> I just figured out what was going on and I guess it's worth
>> mentioning since it points out the dangers of testing modal dialogs.
>> 
>> In the preOpenCard handler for the modal dialog there was this
>> statement:
>> 
>> set the width of this card to 425
>> 
>> This, of course, is not a valid statement since cards don't have a
>> width property.
> 
> They do, actually, but it is read-only. You can't set it.
> 
>> 
>> So I guess now my question for the community is - What techniques do
>> you use to test modal dialogs?
> 
> I debug first without using a modal, like you did. That catches most stuff. Then if it behaves differently while modal, sometimes placing the word "breakpoint" on a line works, where setting a red-dot temporary breakpoint doesn't. The engine interprets "breakpoint" and will halt the script when possible; the IDE interprets the dots and can't always intercept. If that fails, you can resort to putting info into the message box after every suspicious statement. In particular, putting the result works well for lots of things. But if the script is aborting, you might have to wrap it in a "try" structure instead:
> 
> try
> set the width of this card to 425
> catch tErr
> put "Setting width:" && tErr
> end try
> 
> Usually testing the stack as a non-modal first catches almost everything though.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 





More information about the use-livecode mailing list