LCDefaultCardPost

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

LCDefaultCardPost

Post by monte » Mon Nov 04, 2013 2:36 am

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?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: LCDefaultCardPost

Post by LCMark » Mon Nov 04, 2013 10:28 am

@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.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Mon Nov 04, 2013 12:04 pm

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 ;-)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Mon Nov 04, 2013 12:30 pm

Just to clarify what I'm talking about I've pushed it so you can take a look:
https://github.com/montegoulding/liveco ... 1ae34b4184
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: LCDefaultCardPost

Post by LCMark » Mon Nov 04, 2013 8:09 pm

Hmm... how does one get an object reference to the current card when you're not in handler context?
That is the crux of the problem - (which I had forgotten about this morning) - one can't (reliably at least).

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).

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Mon Nov 04, 2013 8:24 pm

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?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: LCDefaultCardPost

Post by LCMark » Mon Nov 04, 2013 9:19 pm

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.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Mon Nov 04, 2013 10:15 pm

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/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Tue Nov 05, 2013 8:02 am

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/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: LCDefaultCardPost

Post by LCMark » Tue Nov 05, 2013 11:00 am

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...
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.
Then use run on main thread so I can resolve the long id and send a message to it... sound workable?
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...

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: LCDefaultCardPost

Post by monte » Tue Nov 05, 2013 11:04 am

Yeah... I might have to do that
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Locked

Return to “Engine Contributors”