Mapping handler dependencies

[SWEdeAndy]

I’m working on a somewhat complex project where several stacks have handlers that call handlers in library stacks which in turn may call other handlers in themselves or other library stacks etc. Nothing unusual with that.

But I am now thinking of developing some small tool to be able to map the interdependencies of these stacks and their handlers, to make sure I don’t change or move or rename handlers in a way that will disrupt the ”chain of command”.

It would go through all scripts and build a list of handler names, looking something like this maybe (the dots are meant to be indents):

Stack X, card 1, btn 1:
mouseUp
...getFunction1
......getFunction2

Stack X, card 1
openCard
...doSomeHandler
......getFunction2
...doOtherHandler
......getFunction1
.........getFunction2

And so on, to show how the handlers are linked to each other. Maybe with clickable references to the script where each handler resides and the line number, or something.

Now, my question is: Has anyone already done something like this, that you could share?
So I don’t spend time reinventing (all of) the wheel?
Searching the forum or the net has not turned up anything useful.

[bn]

Hi Andy,

I made a stub of a stack that reports the message path of a control and collects the handlers from those "upper" handlers. Including behaviors and stacksInUse.

It checks button "b1" on the mainstack and button "b1" of a substack. It reports the messagePath and all available handlers (using revAvailableHandlers)

Maybe you know all that or it could be a start to what you are doing.

I am not aware of a tool that does what you have in mind but the Script Editor has a feature to find handlers when you right-click on a handler name. Much of that logic seems to apply to your task.

Kind regards
Bernd

[SWEdeAndy]

Thanks a lot Bernd, that will definitely be helpful as a starting point!
I was not aware of the revAvailableHandlers function. It's not in the dictionary, so I would hardly have found it on my own, and it delivers a lot of what I need, so it's perfect!

Indeed, right-clicking a handler name in the SE can give you an option to find the handler, but it only works half of the time or so, in my experience. If a handler "lives" more than a step away in the message path from the calling object's script, the option is usually dimmed and can't be used. And sometimes it's dimmed even if the handler is further down in the same script window - it seems a somewhat unreliable search function...

Anyway, picking apart the Script Editor scripts may be a good idea, to see if there's more stuff there I could use.

What I will build is also something that goes the other way, and answers the question "How many, and which, handlers are calling this handler, all across the project?"

If I get around to creating anything useful, I'll share it here, for sure.

[dunbarx]

I was not aware of the revAvailableHandlers function.

It is like the "messageMessages".

It has been mentioned before, the desire to find a list of all these undocumented words.

I want to read about the "findAllBugs" function.

Craig

[SWEdeAndy]

Holy crap! Try:

Code: Select all

put the effective revAvailableHandlers of [object]

With this incantation, you open a portal deep into the LC dark magic realm...

[bobcole]

What do the code mean??

...
M revUnloadLibrary 14 20
F ArrayToJSON 114 125
...

F, M, and the numbers.
Bob

[bn]

Hi Bob,

What do the code mean??

the first letter/letters are the type of handler, then the handler name, third the start line, fourth the end line in the script

Kind regards
Bernd

[SWEdeAndy]

What do the code mean??
...
F, M, and the numbers.

F = function
M = command/on... (No idea why it's M. I would prefer C for command, and O for on - but both go by M, unfortunately)
S = setProp
G = getProp

First number = line the handler begins on
Last number = line the handler ends on

[bn]

Anyway, picking apart the Script Editor scripts may be a good idea, to see if there's more stuff there I could use.
What I will build is also something that goes the other way, and answers the question "How many, and which, handlers are calling this handler, all across the project?"

Hi Andy,

Anyway, picking apart the Script Editor scripts may be a good idea, to see if there's more stuff there I could use.

if you want to poke around in the IDE then this little stack I wrote might help a bit.

https://github.com/macMikey/LC-HACK/blo ... 3.livecode

You type in a relevant handler/other word and it finds the occurences of the search term in the roughly 200 scriptified (xxx.livecodescript) files of the IDE. Since most logic of the IDE is scriptified you have a good chance of finding stuff.


Actually the find function of the IDE (in Edit Menu at the bottom "Find and Replace") does a pretty good job of finding arbitrary stuff in scripts of stacks. Maybe you could take some ideas from that.

Kind regards
Bernd

[mwieder]

I think the M for commands is for Metacard, for reasons of historical nostalgia <g>.
Also the revAvailableHandlers() result can have a "P" prefix for private handlers.

[SWEdeAndy]

if you want to poke around in the IDE then this little stack I wrote might help a bit.

Thanks Bernd, that looks very useful!

[jacque]

First number = line the handler begins on
Last number = line the handler ends on

My understanding is that the last number is the character count on the line where the error occurred. But when I looked it up in the dictionary for LC 10 there was no mention of it. Did something change?

[SWEdeAndy]

My understanding is that the last number is the character count on the line where the error occurred. But when I looked it up in the dictionary for LC 10 there was no mention of it. Did something change?

Well, this relates to the output from revAvailableHandlers. It's not error codes.

[jacque]

My understanding is that the last number is the character count on the line where the error occurred. But when I looked it up in the dictionary for LC 10 there was no mention of it. Did something change?

Well, this relates to the output from revAvailableHandlers. It's not error codes.

Right, got it. My bad.

[SWEdeAndy]

*A month later, Andreas emerges bleary-eyed from his coding den*
”Eureka!”, he exclaims.

So, I've created a tool that does what I had in mind. Whether it’s just a cute solution looking for a problem, or something that some of you also might actually find useful, remains to be seen…

As with every project, at least I learned a few new things on how stuff in LiveCode works.

The stack layout and it’s tool tips should be reasonably intuitive to get you started, but here’s a short instruction:

1. Open the stack, preferably on a ”larger-than-laptop” screen (Edit: the stack is 1000x800 px, so fits most laptops, but can be resized up). I’ve made it as small as possible at the moment, but it displays too much information to be practical on a small screen (in my opinion).

2. Add stacks that you wish to analyse. First add them to the list, then select the lines in the list to be included in the current analysis run. This makes it easy to play around with various stack combinations.

3. Click the "Start mapping and analysis" button and watch the magic!
The process takes less than a second normally, or maybe a few with many/large stacks.

4. Play around with the resulting tree views and lists, exploring the extents and interrelations of your flora of handlers. It’s fascinating, really!

Let me know what you think, and if this is worth developing further in any way.

Edit: Latest version is now here: https://github.com/wheninspace/WIS_ScriptDepedencies

(Compatibility note: The stack uses no fancy extras, only standard controls and widgets. But it uses the ”filter…where” form, which according to the docs only works from LC v9.5 and up.)