Help: Does anyone use legacy message box behavior?

[Monte Goulding]

> On 8 Feb 2017, at 11:02 am, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Monte Goulding wrote:
> 
> >> On 8 Feb 2017, at 3:04 am, Richard Gaskin wrote:
> >>
> >> My Message Box replacement sets the revMessageBox redirect to empty
> >> when it closes, and after doing so the LC IDE Message Box resumes
> >> normal behavior.
> >
> > Yes it does use it but it also (at least the single line msg box)
> > happens to conform to the old spec too (stack is named “Message
> > Box”). Also it sets it when loading the message box so that might
> > be fixing it for you.
> >>
> >> Is it necessary to remove the old behavior?
> >
> > Not overly so, however, every line removed is something we don’t
> > need to waste time maintaining. You might think we don’t need to
> > touch it but it has been touched recently because of a change in
> > the way we retain object references.
> 
> Now I'm curious: anything interesting there in terms of features, performance, or memory handling?

The main advantage is stability. You might remember that in one of the early 8 releases (not sure which one as it was just before I started) the memory management of objects changed so they would be released sooner if deleted within tight script loops instead of waiting for the next main loop to released them. It was a response to a bug where creating and deleting lots of objects in a loop bloated memory use I believe. Well deleting them earlier resulted in *lots* of instability where there were references to objects (say the internal defaultStack global for example) but the object had been deleted. Things like scripts still executing on objects that are meant to be deleted or setting the defaultStack to a stack that has just been deleted. Anyway in order to make it easier for us to resolve these issues Fraser wrote a class to use as an object handle whenever we want to keep a reference to an object. So now we can do stuff like t_stack.IsValid() before doing something with t_stack.

For example one crash that I just fixed is this one: https://github.com/livecode/livecode/pull/5143 <https://github.com/livecode/livecode/pull/5143>

In that crash we were getting the stack of an object when it is being sent a message then using it later but the particular crashing code was deleting the stack the target object was on in a frontScript which was executed between getting the reference to the stack and using it. So the change now uses an object handle so we can check it’s still valid before sending the message after the frontScripts are executed ;-)
> 
> 
> > BTW our internal discussions have led us to consider dropping the
> > message box redirect entirely and just sending msgChanged to the
> > defaultStack which is inline with other messages. The less special
> > cases in the way we do things the better. The IDE pubsub library
> > can dispatch ideMsgChanged to any subscribers and they can do what
> > they like. If it’s unhandled or passed to the engine then it can be
> > sent to the appropriate system logs (or stdout… not sure which just
> > yet and perhaps will depend on if its in no ui mode as there’s a
> > legacy there).
> 
> My first inclination would be as you'd anticipated, that it would be such a low priority as to be barely worth the net trade-off of trimming some code in one place while writing other code elsewhere.
> 
> But if we're at last in a place where the IDE spec we're working with will finally settle down, I'm okay with rewriting my stuff to work with it.
> 
> And best of all, since both the IDE code and our code will be coming from an engine-borne message (I like msgChanged), I have options for how I handle that, either through the IDE pubsub or in a well-managed frontscript as all my other tools tend to use (which is why they don't generally break with IDE changes <g>), and that freedom is as important to me as being able to rely on the message within a standalone when I need to do that too.
> 
> In short, go for it. :)

;-) OK

> 
> Thanks for running this by the community.

It’s worth remembering that almost all of what we do is run by the community because everyone is free to subscrib to our github feed and comment on our PRs.

Cheers

Monte