LCContext stuff & handler context
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
LCContext stuff & handler context
I'm looking at both sides of the LCContext stuff (engine & lcidl) and I can understand why some of it must be handler context... LCContextMe/Target... local properties and variables but there are some things that could be called at any time as far as I can see like LCContextDefaultCard/Stack... what am I not getting?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCContext stuff & handler context
The things that are specified as being 'handler-context' are ones which aren't guaranteed to be (well) defined outside of execution of a handler - whilst 'the defaultStack' is a global variable inside the engine, it is only really accessed as a result of script being executed as it is the result of script action that causes it to be set.
To give an example... It is possible to get an external to run code in 'dispatch context'. This context occurs (say) when a handler calls 'wait' and events are processed. Now, at this point the 'defaultStack' could be anything relevant to the handler calling 'wait' and not something you could take as being 'what the user intends' from the point of view of your external. i.e. If you want to use defaultStack outside of a handler, then save the object-pointer and use that in your callback that occurs in dispatch-context, that way you know you are using the stack that is relevant to the use of your external handler (because the scripter will have called your handler at a point where defaultStack is appropriate for that use).
[ Note, that beyond dispatch-context - i.e. native context - you could be on a different thread and that means the engine could be doing anything to its globals. ]
By the way, you have just highlighted something else - LCObjectResolve should really be LCContextResolveObject() as it relies on context to determine the object. I'll have to ponder what to do there.
To give an example... It is possible to get an external to run code in 'dispatch context'. This context occurs (say) when a handler calls 'wait' and events are processed. Now, at this point the 'defaultStack' could be anything relevant to the handler calling 'wait' and not something you could take as being 'what the user intends' from the point of view of your external. i.e. If you want to use defaultStack outside of a handler, then save the object-pointer and use that in your callback that occurs in dispatch-context, that way you know you are using the stack that is relevant to the use of your external handler (because the scripter will have called your handler at a point where defaultStack is appropriate for that use).
[ Note, that beyond dispatch-context - i.e. native context - you could be on a different thread and that means the engine could be doing anything to its globals. ]
By the way, you have just highlighted something else - LCObjectResolve should really be LCContextResolveObject() as it relies on context to determine the object. I'll have to ponder what to do there.
Re: LCContext stuff & handler context
Hmm... what about something like the topStack? I usually use LCContextMe but for something like mergNotify it really would be best to send the message to the current card of the topStack or something like that..
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCContext stuff & handler context
I guess what we are talking about here is 'global notifications' - events that aren't really targetted at a given object, but the app as a whole. The engine does cop-out a bit here at present, sending such things to 'this card of the defaultStack' which I've never been happy with, but without the notion of a 'root' application object it's pretty much the best thing that can be done.
Now, if we had a concept of a 'root' application object, then things like shutdown/startup/desktopChanged and all messages of that ilk would get sent there as it would then be up to the application script to propagate the messages as needed to the appropriate place. However as we don't have that yet...
How about a new LC API for notifications of this kind - maybe LCNotificationPost(). This would be a bit like LCObjectPost() except that the engine would determine the appropriate place to send the notification (using its current logic at the moment, but in the future using the idea of 'root' object, when the engine gets that). [ LCNotificationPost() could be something done in any context - as the engine would be able to synchronize / schedule and deliver it when it was most appropriate ].
Now, if we had a concept of a 'root' application object, then things like shutdown/startup/desktopChanged and all messages of that ilk would get sent there as it would then be up to the application script to propagate the messages as needed to the appropriate place. However as we don't have that yet...
How about a new LC API for notifications of this kind - maybe LCNotificationPost(). This would be a bit like LCObjectPost() except that the engine would determine the appropriate place to send the notification (using its current logic at the moment, but in the future using the idea of 'root' object, when the engine gets that). [ LCNotificationPost() could be something done in any context - as the engine would be able to synchronize / schedule and deliver it when it was most appropriate ].
Re: LCContext stuff & handler context
That would be perfect
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/