Stupid question on the use-list

[dunbarx]

On a card with a field 1 and a button, this in the btn script:

Code: Select all

on mouseUp
   put "start"into fld 1
   wait 5 seconds
   put "stop" into fld 1
end mouseUp

Works just fine. Why wouldn't it? But now try substituting the message box for fld 1. The "start" never appears. There were reasons mentioned for this, and I am not at all sure about them

So the question is: "Why does it not work the same with the message box?" And I know the message box is a mysterious entity.

Craig

[FourthWorld]

The Message Box contents are driven by messages. This was added several versions ago to facilitate alternative message box UIs and debugging tools.

Being message-driven, it will show updates at idle.

You can allow messages to be sent in the middle of other processing by adding the "with messages" clause to the wait statement.

[dunbarx]

Richard.

The Message Box contents are driven by messages

What isn't? The handler sees msg as a container, no? Just like that field. What happens to the instruction to place a string into message that does not happen when placing that string into a field? How does msg "block" (ignore?) the instruction in the handler after it has already executed?

Or does the handler "know" that the destination of that line of code is special, in that it is the message box, and therefore acts differently? Does it know this early enough not to properly complete that line of code for the same reason? Does msg not accept it for some reason?

I have no sense of the distinction.

Craig

[FourthWorld]

Richard.

The Message Box contents are driven by messages

What isn't?

Commands and functions.

What happens when you add the "with messages" clause to the wait statement?

[dunbarx]

Richard.

I know that waiting with messages allows the message box to receive the string "start".

My question is why doesn't a field need that, or rather, why does message absolutely need it?

What is the difference, apart from the message box being a separate stack? Before you answer, know that if the target field was in fact on a separate stack, the handler works perfectly normally; it does not need to wait with messages. It can just wait.

So it is not that the loading of the string is not local. It is the message box itself that is the outlier case. I am just wondering what the distinction is.

Craig

[FourthWorld]

My question is why doesn't a field need that, or rather, why does message absolutely need it?

Message Box contents are not handled via the same mechanisms as other means of putting contents into fields.

The Message Box contents are driven by messages. This was added several versions ago to facilitate alternative message box UIs and debugging tools.

In this new arrangement, Message Box contents are updated in response to a msgChanged message. This change was documented in the v9.0 Release Notes (dp5 and later) for developers who had been using the older revMessageBoxRedirect global property (which AFAIK was only the IDE team and myself):

The way the message box functions has been refactored:
- the IDE only global property revMessageBoxRedirect has been removed
- the IDE only global property revMessageBoxLastObject has been removed
- the legacy message box behavior setting the text of the first field of a stack named Message Box has been removed
- the msgChanged message is now sent to the object that changed the message
- IDE plugin developers should subscribe to ideMsgChanged for custom message boxdevelopment.
- If the msgChanged message is not handled the content of the message box will be logged to the system log unless the engine is running in no ui (command line) mode which will write thecontent to STDOUT.revvideograbberend-of

Here's the msgChanged handler used in LC's IDE (see the revIDEMessageHandlerLibrary" frontScript):

Code: Select all

on msgChanged pHandler, pLine
   local tTarget
   put the long id of the target into tTarget
   
   local tParams
   put tTarget into tParams[1]
   put pHandler into tParams[2]
   put pLine into tParams[3]
   put msg into tParams[4]
   send "ideMessageSendWithParameters" &&  "ideMsgChanged, tTarget, tParams" to stack "revIDELibrary" in 0 milliseconds
   pass msgChanged
end msgChanged

Their use of "send...in <time>" accounts for the seeming anomaly.

[dunbarx]

Richard.

OK, I even understand that. No wonder the message box is peculiar.

Thanks.

Craig