On Jul 20, 2004, at 2:04 AM, Ken Ray wrote:
I could refer to it in any of the following ways (assuming the
context/defaultStack is the stack "Stack1" and the currently displayed card
is card #1):
field "Greetings" of group "innerGroup" of group "outerGroup" of card 1 of
stack "Stack1"
field "Greetings" of group "innerGroup" of group "outerGroup" of card 1
field "Greetings" of group "innerGroup" of group "outerGroup"
field "Greetings" of group "innerGroup"
field "Greetings"
Additionally, I could have used:
field "Greetings" of this card field "Greetings" of card 1 of this stack (etc.)
Based on reading this, my guess would have to be that often the defaultStack is not what I think it is at any given time, or more specifically, portions of my code my not be aware that other portions of my code have opened another stack, thereby changing the defaultStack... so I frequently resort to the first version, which looks like the long name less the file path to the actual stack file.
It seems that the whole defaultStack thing is aimed at a very linear and procedural type of coding. "When the user clicks this button, this happens." My code is full of callbacks and asynchronous routines via "send in time." "When the user clicks this button, six other non-related things may be happening at the same time (at least insomuch as a non-threaded tool can make them happen at the same time.)" I really have no way of determining what some other portion of the app has modified, or opened... so I use very explicit paths to ensure that my messages are received.
Is it a case that one needs to constantly say - if the defaultStack is not "myStack" then...
But then, changing the defaultStack at that point could effect the other portion of the interface which is working with the defaultStack as a different stack.
So then, virtually every handler has to be wrapped in something like -
put the DefaultStack into oldStack set the defaultStack to "newStack" -- do stuff put oldStack into the defaultStack
Which is a routine more typical of setting the defaultFolder, I think.
BUT, is that actually more advantageous than simply using explicit paths? I really don't know. The defaultStack thing to me is a bit simplistic, and causes me more problems than benefits. In general, I'm forced to ignore it, or do something like the above. But then, maybe I just don't understand how to make it work best for me. The problem comes from the fact that if I use my program one way, everything works fine, but if I use it a different way (make different selections in the using) all of the sudden it can't find things... which makes debugging more difficult as you have to recreate a random pattern.
Perhaps I'm more cautious about it than needed, and perhaps the pathing system works better than I give it credit for, or perhaps I haven't used it "right." But for whatever reason, I've run into issues which only using stupidly long and tedious paths to objects resolved the issue.
-- Troy RPSystems, Ltd. http://www.rpsystems.net
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
