I've just come across another inconsistency with this. The QC asked me to supply a stack to demonstrated the problem so I put together a simple stack and substack for them that mimics the stacks that caused the problem, but the defaultstack is set correctly! I'm still working on it because while the QC stack does add and delete fields, it doesn't have quite all the logic from the original stack so I'll add everything and see if I can reproduce the problem. Maybe it's something other than adding/deleting controls and resizing the stack.
Pete Haworth On Feb 1, 2011, at 10:57 AM, J. Landman Gay wrote: > On 2/1/11 11:10 AM, Peter Haworth wrote: >> destroyStack is false. Sounds feasible but doesn't explain why the >> problem only occurs when I dynamically add new controls to the modal >> dialog and change its height. >> >> I'm about to submit a bug report for this. > > The act of manually manipulating controls will reset the defaultstack. That > makes sense, since the user will be actively working with it and the engine > needs to direct its instructions to that stack. If your user doesn't change > the controls, then the defaultstack doesn't have to change. > > The workaround is to do what you did -- reset the defaultstack when the > script returns to the originating handler. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
