Mapping handler dependencies

[mwieder]

In any case it potentially causes some faults in the way the handler relations are defined, that I find hard to get around.

Yeah, that was my take as well. I messed around a bit with setProps having a leading "S" and then removing it before adding to the syntax list, but it seemed like a lot of work for very little return. I think what I'd be interested in regarding getProp/setProp handlers in the flowchart is the setProp end of things, i.e., what handlers make a change to the script environment. Similar to the way I can put a log statement into a setProp handler during debugging to determine where the property change is coming from. I'm happy enough with the flowchart the way it is.

[jacque]

I'm not sure it's worth it to accommodate my monster scripts. I tried a somewhat smaller one which did work but it was still too small to read comfortably. I don't know if it's possible but it would be nice to have a larger font in a scrollable window.

Why a monster script? I have two projects that each work with multiple content stacks. The stacks in each case require the same scripts but the visual content in each is different. The script I tested with is a backscript that runs all the various mainstacks.

[SWEdeAndy]

I'm not sure it's worth it to accommodate my monster scripts.

It's very easy to add char max as a setting, so I'll do that and we shall henceforth fear no one's monster scripts.

I tried a somewhat smaller one which did work but it was still too small to read comfortably. I don't know if it's possible but it would be nice to have a larger font in a scrollable window.

As it turns out, it is indeed possible and easy too. Soon we shall not only unfear monster scripts, we'll welcome them!

[jacque]

I'm not sure it's worth it to accommodate my monster scripts.

It's very easy to add char max as a setting, so I'll do that and we shall henceforth fear no one's monster scripts.

I tried a somewhat smaller one which did work but it was still too small to read comfortably. I don't know if it's possible but it would be nice to have a larger font in a scrollable window.

As it turns out, it is indeed possible and easy too. Soon we shall not only unfear monster scripts, we'll welcome them!

In that case, I officially declare you a hero.

[SWEdeAndy]

In that case, I officially declare you a hero.

Hopefully this version will merit such an honorary title then!

https://github.com/wheninspace/WIS_Scri ... ses/latest

v1.1.1 (20 Aug 2023)
- Enhancement: Flowchart width limitation can now be turned off, to display the flowchart at actual size, instead of shrinking big charts to an unreadable size
- Enhancement: Commands, functions and get/setProp nodes now have different colours to make them easier to distinguish between. Possibility for user selected colours will be implemented in a coming version.
- Enhancement: In general settings it is now possible to increase the char maximum of the flowchart syntax text, to enable display of very large flowcharts. Only change this value if you get a "Maximum text size exceeded" error message in the flowchart.
- Other minor fixes

You can just open the old stack in order to be prompted to download the new version. After (manually) replacing the old stack with the new one, I hope your user data will have been restored (if the lson file is in the same folder). Please let me know if that worked as intended.

[bn]

Hi Andreas,

Thank you for the new version.
I downloaded version 1.1.1 and installed it in the same folder as I have 1.1.0.
Starting 1.1.1 worked ok but the flowchart was all text.

I then closed LC and remove the old files in the folder and restarted WIS_ScriptDependencies and then the flowchart worked.
I is nice that it is not squeezed to fit the fixed screen but has the scrollable feature that one can actually read the labels.

This is on a Mac using LC 9.6.10 RC1

Again thank you for this fabulous tool.

Kind regards
Bernd

[SWEdeAndy]

I downloaded version 1.1.1 and installed it in the same folder as I have 1.1.0.
Starting 1.1.1 worked ok but the flowchart was all text.

I then closed LC and remove the old files in the folder and restarted WIS_ScriptDependencies and then the flowchart worked.

Hmm, well I don't know what might have happened there. I tried to reproduce it, but I didn't get any similar error. Let's hope it was just some temporary glitch.
Thanks for your feedback, Bernd!

In the next version I'm implementing a decent solution for excluding commented-out handler names. Currently they still count as a relation, which is wrong of course.

[paul@researchware.com]

In that case, I officially declare you a hero.

Hopefully this version will merit such an honorary title then!

https://github.com/wheninspace/WIS_Scri ... ses/latest

v1.1.1 (20 Aug 2023)
- Enhancement: In general settings it is now possible to increase the char maximum of the flowchart syntax text, to enable display of very large flowcharts. Only change this value if you get a "Maximum text size exceeded" error message in the flowchart.

For my app, I had to increase this from 50,000 to 500,000 to get the flowchart. The chart eventually displayed, but I can not figure out how to zoom in on the chart? If there ANY way to display the chart larger and/or zoom in on parts?

Just the top of the chart shown below:

[SWEdeAndy]

For my app, I had to increase this from 50,000 to 500,000 to get the flowchart. The chart eventually displayed, but I can not figure out how to zoom in on the chart? If there ANY way to display the chart larger and/or zoom in on parts?

Wow, that's a big one! What's the handler count on that one?
Now, if you haven't already, try unticking this box:

limitWidth.png (13.33 KiB) Viewed 104034 times

Not limiting the width lets it take the space it needs, with 'normal sized' nodes and text, with scrollbars.

[paul@researchware.com]

For my app, I had to increase this from 50,000 to 500,000 to get the flowchart. The chart eventually displayed, but I can not figure out how to zoom in on the chart? If there ANY way to display the chart larger and/or zoom in on parts?

Wow, that's a big one! What's the handler count on that one?
Now, if you haven't already, try unticking this box:
limitWidth.png

Not limiting the width lets it take the space it needs, with 'normal sized' nodes and text, with scrollbars.

Duh, it was straring me right in the face. I should have seen the checkbox. Thank you. That worked perfectly. There are about 2000 handlers in the multistack application. There are probably some number of unused handlers or ones that are redundant and can be consolidated. That's one reason I was exploring your excellent tool - to identify those routines for future trimming.

[jacque]

Way more better. I used a somewhat smaller, but complex, stack with only 107 unique handler names. The chart is quite readable without the limited width. Then I put the window into fullscreen view and it was lovely. I still have trouble tracking all the lines and arrows but I think that's my own fault. At least I can see them now. Nice.

[SWEdeAndy]

Great! Thanks Paul and Jacque for the feedback!

A small update is now available:

v1.1.2 (22 Aug 2023)
- Fixed bug: Commented-out handlers are now skipped when mapping relations
- Fixed bug: Sometimes when upgrading from an earlier version, the user setting for char maximum of the flowchart syntax text could be empty, causing the flowchart to display only text
- Enhancement: If a handler has more than one ”handler host”, i.e. resides in more than one script, the number of occurrences is shown in its flowchart node

I could test implementing the possibility to click on a node (MacOS only then, though), and have the arrows to and from it get another colour, to somehow highlight them. I was even toying with the idea of having all arrows take the colour of their destination node (command/function etc), but that might get a bit overwhelming perhaps, and not so useful. I think the highlighting idea is better. But I have other interesting ideas too, so we'll see what comes out first...

[jacque]

I agree coloring all the arrows might be overwhelming. Would it be possible to select a node and color the lines that connect to it? Sometimes my script has so many lines it is hard to trace them. I'm not sure what's possible but that would be a handy addition.

[bn]

A small update is now available:

v1.1.2 (22 Aug 2023)
- Fixed bug: Commented-out handlers are now skipped when mapping relations

Hi Andy,

thank you for the update. I noticed though that "Start Mapping..." is considerable slower due to "StripOutComments".

I tried this

Code: Select all

function stripOutComments pScript
   local tLineCount, tCollect
   
   split pScript by cr
   repeat for each element aLine in pScript
      put token 1 to -1 of aLine & cr after tCollect
   end repeat
   delete char -1 of tCollect
   
   return tCollect

for one of my projects it reduced mapping time from 21 seconds to under 7 seconds.

Use at your own risk... But seems to work.

However there still might be block comments (/*....*/) that span multiple lines. Just saying...

Kind regards
Bernd

[bn]

Hi Andy,

This version cuts the time from 21 seconds to under 1 second

Code: Select all

function stripOutComments pScript
   local tLineCount, tCollect
   
   repeat for each line aLine in tCollect
      put token 1 to -1 of aLine & cr after tCollect
   end repeat
   delete char -1 of tCollect
   return tCollect

I was thinking too complicated.

Kind regards
Bernd