message box covered with objects of some kind

[mcelvain]

Forgot to mention that, since beginning LiveCode, I’ve been using a back script.

Although this adds a level of complexity to message passing, it requires less memory; perhaps at the expense of the various Mac Os processing chips and perhaps motherboard.

Dunno; no expert.

One reason for this strategy is to support writing a conversion script for converting SuperTalk into LiveCode.

A reoccurring pattern leading to a “something” dialog involves an attempt to “save” an opened stack.

My hunch is that LiveCode isn’t passing a clear “save this document” path to the OS software and is getting an error message of some kind which it then passes — partly — to me.

Although the message box then shows up with a new such icon overlaying and obstructing its option menu input fields, I haven’t usually called it; it just shows up.

I have been using full pathnames in my coding lately in an attempt to prevent these “something” dialogs.

I think this may have been successful, but not sure.

Is there a LC “log” somewhere that I can extract and evaluate in order to confirm my hope that using full pathnames prevents these unwanted “something” dialogs which seem to leave icons on even an uncalled message box ?

[mcelvain]

QT movie example of the ‘something’ dialog (linked to my “unlisted” YouTube account).

In order not to violate posting rules here, you’ll have to assemble the following lines as URL:


https
://
youtu.
be
/
KdL1bV6bxFc

[mwieder]

OK - does your backscript have a closeStack handler? closeCard?
Are there unclosed "put" statements? i.e.

Code: Select all

put xyzzy

rather than

Code: Select all

put xyzzy into msg

?

Are you changing the defaultStack in the backscript?

[bobcole]

I found a reference to the "something" box in the LiveCode-dev mailing list.

Date: Wed, 25 Jan 2023 15:42:14 -0800
From: Mark Wieder <ahsoftware@sonic.net>
To: livecode-dev@lists.runrev.com
Subject: something
@LCMark:
Since the "something" modal dialog came up in today's zoom session,
here's the latest bug report. But I've seen this happen sporadically
over the last 20 years on all desktop platforms and never been able to
pin it down. Or in spite of grepping my way through the engine and IDE
code have I been able to figure out where this is coming from.
https://quality.livecode.com/show_bug.cgi?id=17715
Mark Wieder
ahsoftware@gmail.com

[mcelvain]

Thank-you and responding to mwieder:

Checked for unclosed ‘put’ statements in bg script; negative.

re: bg closeStack handlers:

I have removed my one “On Closestack” bg script handler, which saved, compacted, and resaved.

Could be that I ran a stack lacking a “closestack” handler, bg version was called by LC, and there was no obvious path to the object to be compacted and saved.

[ your ideas are much appreciated, as I’m still quite new to the LC platform.

You have me looking for unterminated messages, open loops and language that causes hanging between LC and the language under LC which translates it.]

What I am lacking is a full log of passed messages.

is there a log written by “message viewer?”

As a newbie, I need to diagram all this until I can visualize the architecture as well as you all obviously can.

[FourthWorld]

The Message Watcher is a bit limited, so I made 4W Flight Recorder, available from the Stacks section of LiveNet.

In the IDE see Development -> Plugins -> GoLiveNet

[mcelvain]

Your “Flight Recorder” is very cool, Richard.

Thank-you for the suggestion.

On looking under the hood in your stack, I see you make use of “front script” architecture.

Is it similar in function to SC’s “idle” function, which continuously iterates, looking for keystrokes or conditions you tell it to?

Anyhow, it looks like you conditionally transfer stored button scripts to a front script, based upon current name of a button which is then renamed.

I have found that SC “idle” scripts have to be used carefully, for obvious reasons.

Are there any learning resources for front-scripting you’d recommend ?

[FourthWorld]

On looking under the hood in your stack, I see you make use of “front script” architecture.

Is it similar in function to SC’s “idle” function, which continuously iterates, looking for keystrokes or conditions you tell it to?

IIRC frontScripts were first introduced to the xTalk word in SuperCard 2.5, later added to MetaCard which became LiveCode.

They allow the script of any object to be inserted in front of the message path. This of course means that if you use them you'll want to be sure to pass those messages, or have a very good reason not to.

But using frontScripts alone would be tedious with a general-purpose event logger like Flight Recorder, requiring that I wrote a logging instruction within in a very long list of all message handlers. And even then it would only be able to record system messages, and would have no means of logging custom handlers.

That's where the messageMessages global property comes in. It's rarely needed except with making diagnostic tools like this, but is a godsend when you do. When true, the messageMessages sends a messageHandled message for every event, handler, and function call, just before the receiving handler gets it. That's the heart of what Flight Recorder uses for logging.

And by putting the messageHandled message into a frontScript, FR will get the message before anything else, better ensuring that anything downstream may swallow the message in a way that would prevent FR from being able to log it.

FrontScripts are widely used and well documented. In the IDE's Dictionary look for the "frontScripts" function, and the "insert script" and "remove script" commands.

The messageMessages property doesn't appear in my copy of the Dictionary, but it's so specialized almost no one needs it. For that the scripts in FR illustrate usage well enough if you want to explore it.

I have found that SC “idle” scripts have to be used carefully, for obvious reasons.

There's a change you'll find in LC from SC: in LC the idle message is only sent when an idle handler is present. It's overhead seldom used, and the LC engine avoids it whenever it can.

In LC we more commonly use the send command where we used to use idle in HC and SC. The send command includes the ability to specify an interval for sending, so a message can keep sending a call to itself every few seconds, for example, or whatever interval is needed, with a lot more control than an always-running idle handler, and a bit leaner internal implementation.

This note from the Dictionary entry for idle reminds us:

Executing an idle handler slows down other LiveCode actions, so handle the idle message only in the rare cases where the send command cannot be used instead.

Note: If there is no idle handler anywhere in the message path, no idle message is sent.

For details on the send command, the Dictionary has good documentation on using its "...in <time>" option.

[stam]

Richard has long ago published an article on the message path which was instrumental helping me understand this:
https://fourthworld.com/embassy/article ... _path.html

This one figure says it all:

IMG_1805.gif (10.06 KiB) Viewed 12522 times

[mwieder]

Back to your original problem though...

If you launch with IDE without your backscript does the message box look ok?
If it still has the weird objects then my guess is that your backscript intercepted the save message, possibly by changing the default stack or possibly by making the message box the topstack, and then saved controls onto the message box instead of to the stack you intended.
And in that case you'd be well served by reinstalling LiveCode.

If the message box looks ok without your backscript then at least the weird objects aren't a permanent feature then the problem is probably isolated to your backscript and we can debug from there. Is the backscript something you can post here or is it more proprietary?

[mcelvain]

Thank-you for both the diagram and offer to examine my back script!

As soon as I render some of my variable names less ripe, I'll post it; perhaps later today.

One question on the flow chart:

I had assumed that the "LiveCode Engine" would be vertical, not horizontal, and interacting horizontally with all of the object layers and written code.

Maybe then a horizontal layer which interprets for OSx.

[FourthWorld]

Thank-you for both the diagram and offer to examine my back script!

As soon as I render some of my variable names less ripe, I'll post it; perhaps later today.

One question on the flow chart:

I had assumed that the "LiveCode Engine" would be vertical, not horizontal, and interacting horizontally with all of the object layers and written code.

Maybe then a horizontal layer which interprets for OSx.

In very broad terms, yes, everything within LC is managed by LC, and downstream from LC is the OS (which of course here includes Windows, Linux, iOS, and Android in addition to macOS).

The diagram shows the flow of messages among the objects we can script within LC. If nothing in any script handles a message, it eventually arrives unhandled to the engine which usually lets it die a natural death (nothing happens).

The diagram is almost identical to the one that was part of the SuperCard documentation since 1989, with extensions here for those things unique to LC. Does the SC User Guide no longer contain a diagram of the message path?

The last printed SC User Guide was v3.0, where the Message Hierarchy diagram is on page 454. Unfortunately, it's also incomplete (I'm off the hook there; while I wrote 1/3 of the SuperCard Language Guide I didn't write that part of the User Guide <g>): it's missing frontScrirpts and backScripts, which were introduced to the xTalk world in SuperCard 2.0 or 2.5, if memory serves.

[mcelvain]

[ will attach script as requested ]

[mwieder]

Whew! Well, I would have preferred it as an attachment, but... a couple of things from a quick overview (I take it --elvis is so you can say "find Elvis")

LiveCode doesn't accept the mac "≠" character as an operator, so you'll have to use "!=" or say "is not" or something similar.
...don't get me started on that one.

Is that name of that stack "Backgrounder" as in the preopenstack handler?
If so, you're invoking the preopenstack for every stack that doesn't have an explicit preopenstack handler, if that makes any sense.
Same with closestack, but it looks harmless.

I'll throw this script into a stack later on and see what happens.

[stam]

LiveCode doesn't accept the mac "≠" character as an operator, so you'll have to use "!=" or say "is not" or something similar.
...don't get me started on that one.

I thought the correct notation was to use <> or a not verbose structure.
Don’t think “!=“ is correct?