Quantcast

Help: Does anyone use legacy message box behavior?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
Hi Folks

I’m in the midst of making the message box redirect work in all engines (https://github.com/livecode/livecode/pull/5156 <https://github.com/livecode/livecode/pull/5156>) and it would seem that there’s a legacy message box behavior that could be removed from the engine. It’s not used by the IDE. The behavior is if no message box redirect is set then it looks for a stack named “Message Box”, sets the text of the first field then raises the stack. As this is only an IDE thing I strongly suspect we are ok to remove the code but while I’m waiting for the team to wake up in Scotland I thought I’d check here!

It would be easy to work around even if you have been depending on it because it’s just setting the property and then handling msgChanged to put msg where ever you want.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
On 02/06/2017 07:28 PM, Monte Goulding via use-livecode wrote:

> I’m in the midst of making the message box redirect work in all engines (https://github.com/livecode/livecode/pull/5156 <https://github.com/livecode/livecode/pull/5156>) and it would seem that there’s a legacy message box behavior that could be removed from the engine. It’s not used by the IDE. The behavior is if no message box redirect is set then it looks for a stack named “Message Box”, sets the text of the first field then raises the stack. As this is only an IDE thing I strongly suspect we are ok to remove the code but while I’m waiting for the team to wake up in Scotland I thought I’d check here!
>
> It would be easy to work around even if you have been depending on it because it’s just setting the property and then handling msgChanged to put msg where ever you want.

Go for it. Would be nice to have redirect work any/every/where.

--
  Mark Wieder
  [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
In reply to this post by Dan Friedman via use-livecode
On 2/6/17 9:28 PM, Monte Goulding via use-livecode wrote:

> Hi Folks
>
> I’m in the midst of making the message box redirect work in all
> engines (https://github.com/livecode/livecode/pull/5156
> <https://github.com/livecode/livecode/pull/5156>) and it would seem
> that there’s a legacy message box behavior that could be removed from
> the engine. It’s not used by the IDE. The behavior is if no message
> box redirect is set then it looks for a stack named “Message Box”,
> sets the text of the first field then raises the stack. As this is
> only an IDE thing I strongly suspect we are ok to remove the code but
> while I’m waiting for the team to wake up in Scotland I thought I’d
> check here!
>
> It would be easy to work around even if you have been depending on it
> because it’s just setting the property and then handling msgChanged
> to put msg where ever you want.

Do whatever it takes, I've been waiting for this for years. I could
really use it right now. Debugging standalones is an exercise in
frustration.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
Forgive my stupidity, but how would you use this feature, specifically in debugging a standalone, and what’s wrong with it now?

TIA

Graham

> On 7 Feb 2017, at 07:16, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> On 2/6/17 9:28 PM, Monte Goulding via use-livecode wrote:
>> Hi Folks
>>
>> I’m in the midst of making the message box redirect work in all
>> engines (https://github.com/livecode/livecode/pull/5156
>> <https://github.com/livecode/livecode/pull/5156>) and it would seem
>> that there’s a legacy message box behavior that could be removed from
>> the engine. It’s not used by the IDE. The behavior is if no message
>> box redirect is set then it looks for a stack named “Message Box”,
>> sets the text of the first field then raises the stack. As this is
>> only an IDE thing I strongly suspect we are ok to remove the code but
>> while I’m waiting for the team to wake up in Scotland I thought I’d
>> check here!
>>
>> It would be easy to work around even if you have been depending on it
>> because it’s just setting the property and then handling msgChanged
>> to put msg where ever you want.
>
> Do whatever it takes, I've been waiting for this for years. I could really use it right now. Debugging standalones is an exercise in frustration.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
In reply to this post by Dan Friedman via use-livecode
what the heck is that?

Bob S


On Feb 6, 2017, at 19:28 , Monte Goulding via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

message box redirect

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
In reply to this post by Dan Friedman via use-livecode
Monte Goulding wrote:

 > I’m in the midst of making the message box redirect work in all
 > engines (https://github.com/livecode/livecode/pull/5156
 > <https://github.com/livecode/livecode/pull/5156>) and it would seem
 > that there’s a legacy message box behavior that could be removed from
 > the engine. It’s not used by the IDE. The behavior is if no message
 > box redirect is set then it looks for a stack named “Message Box”,
 > sets the text of the first field then raises the stack. As this is
 > only an IDE thing I strongly suspect we are ok to remove the code
 > but while I’m waiting for the team to wake up in Scotland I thought
 > I’d check here!
 >
 > It would be easy to work around even if you have been depending on it
 > because it’s just setting the property and then handling msgChanged
 > to put msg where ever you want.

IIRC what you describe is the original engine behavior which drove the
MC IDE.  I believe that was also used by early versions of the LC IDE.

The revMessageBoxRedirect global property was a solution added to
satisfy a request I had for being able to use the MC IDE as a plugin
within LC.  If the LC IDE now also uses that property itself that would
seem a cleaner implementation.

Removing the engine behavior you describe will break the MC IDE, but
given how few people use it these days I don't think that should be a
reason to clutter the code base.  Those interested could easily add the
one line of code needed to use revMessageBoxRedirect instead.

Personally, I don't use anything dependent on the older behavior, but I
do use revMessageBoxRedirect very extensively; among other things I've
been using a custom Terminal-like Message Box replacement for years.

Being able to use my custom Message Box in a standalone would be a
godsend.  If removing the old behavior makes a cleaner way to do that I
say go for it.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
In reply to this post by Dan Friedman via use-livecode
Graham Samuel wrote:

 > ...how would you use this feature, specifically in debugging a
 > standalone, and what’s wrong with it now?

The revMessageBox redirect allows you to use any field to display data
that would otherwise go to LC's Message Box; that is, any "put" without
a specified destination.

When combined with an input field for triggering commands and querying
functions and properties, you can effectively make a satisfyingly
full-featured Message Box replacement.

This allows you to query information at runtime in a standalone.

When these fields are part of a separate window they can be useful in
desktop apps, but they can also be contained within a group, which could
be shown and hidden as needed, for debugging in mobile apps as well.

I had thought revMessageBoxRedirect was already part of the standalone
engine, but apparently not.  Making it available to standalones opens up
very flexible options for poking around in a LC app.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
In reply to this post by Dan Friedman via use-livecode
I sent this a while ago, and oddly enough another message I'd sent lae
came in but this one did not.

After thinking about this some more, I wonder:  are you sure the LC IDE
doesn't rely on this?

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.

I don't mind modifying mine if needed, but since an empty revMessageBox
redirect allows the LC IDE to resume use of its own Message Box, and
since the LC IDE's Message Box stack is still named "Message Box", it
would seem the engine behavior you describe is still in use.

Please let me know if I misunderstand.  But FWIW one nice thing about
that behavior is that it keeps things simple, allowing a useful default
in the IDE even if the revMessageBoxRedirect is set to not restored to a
valid field reference.

Is it necessary to remove the old behavior?

- rg


-------- Forwarded Message --------
Subject: Re: Help: Does anyone use legacy message box behavior?
Date: Tue, 7 Feb 2017 07:37:30 -0800
From: Richard Gaskin <[hidden email]>
To: [hidden email]

Monte Goulding wrote:

> I’m in the midst of making the message box redirect work in all
> engines (https://github.com/livecode/livecode/pull/5156
> <https://github.com/livecode/livecode/pull/5156>) and it would seem
> that there’s a legacy message box behavior that could be removed from
> the engine. It’s not used by the IDE. The behavior is if no message
> box redirect is set then it looks for a stack named “Message Box”,
> sets the text of the first field then raises the stack. As this is
> only an IDE thing I strongly suspect we are ok to remove the code
> but while I’m waiting for the team to wake up in Scotland I thought
> I’d check here!
>
> It would be easy to work around even if you have been depending on it
> because it’s just setting the property and then handling msgChanged
> to put msg where ever you want.

IIRC what you describe is the original engine behavior which drove the
MC IDE.  I believe that was also used by early versions of the LC IDE.

The revMessageBoxRedirect global property was a solution added to
satisfy a request I had for being able to use the MC IDE as a plugin
within LC.  If the LC IDE now also uses that property itself that would
seem a cleaner implementation.

Removing the engine behavior you describe will break the MC IDE, but
given how few people use it these days I don't think that should be a
reason to clutter the code base.  Those interested could easily add the
one line of code needed to use revMessageBoxRedirect instead.

Personally, I don't use anything dependent on the older behavior, but I
do use revMessageBoxRedirect very extensively; among other things I've
been using a custom Terminal-like Message Box replacement for years.

Being able to use my custom Message Box in a standalone would be a
godsend.  If removing the old behavior makes a cleaner way to do that I
say go for it.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode

> On 8 Feb 2017, at 3:04 am, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> I sent this a while ago, and oddly enough another message I'd sent lae came in but this one did not.
>
> After thinking about this some more, I wonder:  are you sure the LC IDE doesn't rely on this?
>
> 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.

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

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode

> On 8 Feb 2017, at 11:02 am, Richard Gaskin via use-livecode <[hidden email]> 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
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Help: Does anyone use legacy message box behavior?

Dan Friedman via use-livecode
Monte Goulding wrote:

 >> On 8 Feb 2017, at 11:02 am, Richard Gaskin wrote:
 >>
 >> Monte Goulding wrote:
 >> > ...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.

That's a feature.  And a good one.  In my community meeting with Peter
last week he outlined some of the effort going into v9 stability
improvements, and I was quite impressed.

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

Sounds like a very good change.  Thanks for that background.  Even
though I almost never write in C anymore, that under-the-hood stuff is
very helpful for understanding how the engine works.



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

An excellent reminder.  The Github tools have made the process
wonderfully visible.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...