LCDefaultCardPost
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
LCDefaultCardPost
Howdy... I'm playing with creating a new function in the API to post a message to the current default card so you don't need to retain an object. What I'm doing is overloading the engine interface for dispatching messages by assuming that if the object reference is nil then we are sending the message to the default card. It seemed silly to add another interface for such a minor difference. LCDefaultCardPost therefore calls LCObjectPostV with a nil LCObjectRef... seem reasonable? Do we need a Send version? and do we need a stack version?
Of course this does mean there won't be an error if someone tries to use LCObjectPost with a nil object reference... is that a big problem?
Of course this does mean there won't be an error if someone tries to use LCObjectPost with a nil object reference... is that a big problem?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
@monte: I don't think LCObjectPost should change (nor should the underlying engine API) - it expects a non-nil object parameter (as it posts a message to an object) and thus I think this should remain. I've no issue in principal to a utility function that posts to the default card (that gets the current card handle, then does an LCObjectPost) - although, if this is for 'notifications' (as discussed in a previous thread) then I think it should be LCNotificationPost (which can just be implemented in the externals support code for the moment).
The reason for wrapping the idea of notifications up in a different LC call is that at some point we could look at handling them in the engine with some sort of notification center idea - so any messages which are more application-wide (such as desktopChanged etc.) can be hooked into easily from different objects which are not in the main message path.
The reason for wrapping the idea of notifications up in a different LC call is that at some point we could look at handling them in the engine with some sort of notification center idea - so any messages which are more application-wide (such as desktopChanged etc.) can be hooked into easily from different objects which are not in the main message path.
Re: LCDefaultCardPost
Hmm... how does one get an object reference to the current card when you're not in handler context?
Yes, I was implementing it as a separate call but just passing a nil object reference on to the engine and on the engine side if it got nil it would dispatch to the current card. LCNotificationPost is fine. If there's a way to get the current card outside handler context then I'll do that... Possibly could have used that before had I known it
Yes, I was implementing it as a separate call but just passing a nil object reference on to the engine and on the engine side if it got nil it would dispatch to the current card. LCNotificationPost is fine. If there's a way to get the current card outside handler context then I'll do that... Possibly could have used that before had I known it
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
Just to clarify what I'm talking about I've pushed it so you can take a look:
https://github.com/montegoulding/liveco ... 1ae34b4184
https://github.com/montegoulding/liveco ... 1ae34b4184
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
That is the crux of the problem - (which I had forgotten about this morning) - one can't (reliably at least).Hmm... how does one get an object reference to the current card when you're not in handler context?
Unless a handler is in the process of executing there is (effectively) no meaningful defaultStack (thus no current card). The reason being that it is the act of executing a message send that defines the environment for execution - when you 'send' a message to another object, the defaultStack will be the target object's stack from the point of view of that message's handler, but when you return to the caller, it will be the defaultStack as it was before the message send. (Whilst the 'defaultStack' may appear global, it isn't really).
Now, taking the purpose of LCNotificationPost to be that you can post a notification at any time, from any thread, it could fire at any point of execution. Admittedly, the external support code does synchronize posting - but only as far as the next time the engine collects events - i.e. as a result of MCScreenDC::wait() whether it be called in dispatching (wait with messages) or non-dispatching mode. So, the resulting defaultStack you get will be whatever one happens to be in MCdefaultstackptr at the time your post event is collected, rather than one which is necessarily predictable.
Admittedly, the engine does do this for its notifications (desktopChanged comes to mind) - which is why they are best handled in a backscript - but, doing the same for your externals as it stands would potentially make your notifications 'less' reliable (assuming at the moment, you store an Object handle as the result of some command being executed in the external, to use at a later date to post - which at least makes the target predictable) - particularly if an app is composed of multiple mainstacks.
Clearly this does need a better in-engine mechanism... Perhaps something as simple as a global marking a specific stack as being the one to send notifications. Would that work for the notifications your externals generate?
(By the way, I do think this would be better implemented via a new notification_post API in the engine interface, rather than overloading object_dispatch - the operation is quite different).
Re: LCDefaultCardPost
Hmm... what about using the current card of the topstack? That should be relatively consistent.
OK, new api it is... or could we implement a function to get the current card of the topstack that's not context sensitive?
OK, new api it is... or could we implement a function to get the current card of the topstack that's not context sensitive?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
Hmmm - the topStack is definitely globally defined, true, but I think it suffers the same as just trying to use MCdefaultstackptr at any point as it will be whatever stack is on top at the time the notification is dispatched... It would still result in certain cases where the notification is delivered to somewhere not intended to handle it thus making it less reliable than explicitly holding a handle to where the scripter wants notifications to be delivered.
Re: LCDefaultCardPost
Hmm... well if we define a new global notificationStack/object then it would cause a problem whenever two bits of code wanted it referencing a different object. Perhaps it's simpler to just keep doing the retain an object reference thing...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
I think I've come up with an alternative for the use case I was going to use this on. I usually prefer using LCContextMe for callbacks but I'm implementing a user notification external and the default card would work. As the default card appears to be complicated I started thinking of ways to use LCContextMe. There's a userInfo dictionary that can be used to pass data to the delegate but it must be serialisable in a plist. So I thought I could use LCContextMe then get the long id and stuff it into the user info... Then use run on main thread so I can resolve the long id and send a message to it... sound workable?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: LCDefaultCardPost
Is that likely in a single app though? (Albeit it wouldn't work so well in the IDE). I guess what is really needed is the idea of an 'application' object (project?) - although I'm not sure how hard that would be to introduce at the moment.Hmm... well if we define a new global notificationStack/object then it would cause a problem whenever two bits of code wanted it referencing a different object. Perhaps it's simpler to just keep doing the retain an object reference thing...
Hmmm - you can't run on main thread from the system thread - you can only jump from main/script thread to system thread temporarily. How about the user of the external registers which object they want notifications to be sent to, then there's no need to serialize anything...Then use run on main thread so I can resolve the long id and send a message to it... sound workable?
Re: LCDefaultCardPost
Yeah... I might have to do that
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/