Mapping handler dependencies
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Mapping handler dependencies
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.
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.
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 4027
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Mapping handler dependencies
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
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
- Attachments
-
- getHandlers.livecode.zip
- (2.3 KiB) Downloaded 106 times
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
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.
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.
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 9752
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Mapping handler dependencies
It is like the "messageMessages".I was not aware of the revAvailableHandlers function.
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
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
Holy crap! Try:
With this incantation, you open a portal deep into the LC dark magic realm...
Code: Select all
put the effective revAvailableHandlers of [object]
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 137
- Joined: Tue Feb 23, 2010 10:53 pm
- Location: Saint Louis, Missouri USA
Re: Mapping handler dependencies
What do the code mean??
Bob
F, M, and the numbers....
M revUnloadLibrary 14 20
F ArrayToJSON 114 125
...
Bob
-
- VIP Livecode Opensource Backer
- Posts: 4027
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Mapping handler dependencies
Hi Bob,
Kind regards
Bernd
the first letter/letters are the type of handler, then the handler name, third the start line, fourth the end line in the scriptWhat do the code mean??
Kind regards
Bernd
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
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
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 4027
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Mapping handler dependencies
Hi Andy,SWEdeAndy wrote: ↑Tue Feb 07, 2023 10:04 pmAnyway, 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 you want to poke around in the IDE then this little stack I wrote might help a bit.Anyway, picking apart the Script Editor scripts may be a good idea, to see if there's more stuff there I could use.
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
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Mapping handler dependencies
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.
Also the revAvailableHandlers() result can have a "P" prefix for private handlers.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
Thanks Bernd, that looks very useful!
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 7258
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Mapping handler dependencies
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?
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
Well, this relates to the output from revAvailableHandlers. It's not error codes.
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
-
- VIP Livecode Opensource Backer
- Posts: 7258
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Mapping handler dependencies
Right, got it. My bad.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 265
- Joined: Sat Aug 16, 2008 9:48 am
- Location: Stockholm, Sweden
- Contact:
Re: Mapping handler dependencies
*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.)
”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.)
Last edited by SWEdeAndy on Thu Mar 16, 2023 10:27 pm, edited 4 times in total.
Andreas Bergendal
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en
Independent app and system developer
Free LC dev tools: https://github.com/wheninspace
WhenInSpace: https://wheninspace.se/en