Help: Does anyone use legacy message box behavior?

Richard Gaskin ambassador at
Tue Feb 7 19:02:07 EST 2017

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?

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

Thanks for running this by the community.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list