One of the advantages of using a splashstack, ie, a stub mainstack that opens the actual user interface, is that you can implement the positioning and appearance of your user interface stack before you open it. E.g.: in your mainstack, you set the rect of the interface stack, the visible controls and their locations, load any fields you need to, and only then open the interface stack. This is not necessarily appropriate for all situations, eg, for a utility stack you may want to keep things simple by only having a mainstack that does everything, but in many cases using a stub mainstack to initialize the working window is very easy and clean.
-- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Sep 22, 2012, at 1:36 PM, Peter Haworth wrote: > Here's another nuance on lock screen, throwing in preOpenCard processing > just for good measure! > > My preOpenCard code includes lock and unlock screen commands. While the > screen is locked, I alter the stack's topLeft property, expecting that the > user would see the stack in the location I set it to. > > However, the stack is initially displayed in one location then jumps to the > location I set it to. > > My understanding of preOpenCard is that it happens before the stack is > displayed so this behavior puzzles me. I had to move the code that > adjusts the stack's topLeft into another handler and execute it via a "send > in zero" command in order to get round some other issues with preOpenCard - > could it be that delays the setting of topLeft long enough that it doesn't > happen until after preOpenCard is done? > > This all with LC 5.5.0 and OS X 10.7.4. > > Pete > lcSQL Software <http://www.lcsql.com> > > > > On Thu, Sep 20, 2012 at 8:00 AM, Mark Wieder <mwie...@ahsoftware.net> wrote: > >> Richmond- >> >> Thursday, September 20, 2012, 1:29:32 AM, you wrote: >> >>> That 'multiple lockscreen' thing does seem illogical and/or daft, and it >>> might not be a bad thing if it were changed so that 'locked' meant >>> 'locked once' and was not ambiguous. >> >> It's actually quite useful as is. It means I can write smaller >> routines that fiddle with the screen, locking before and unlocking >> afterwards. I can then string these routines together in a larger >> construct, locking before and unlocking after, without needing to >> worry about the screen suddenly popping to life (and slowing things >> down) in the middle. Remembering to unlock after you've locked isn't >> any more cumbersome than remembering to close parentheses or quotes. >> >> -- >> -Mark Wieder >> mwie...@ahsoftware.net >> >> >> _______________________________________________ >> 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 _______________________________________________ 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
