How to debug script widget?

[stam]

Hi all,

I'm liking the script widget facility in v10 DP5, but am having some speed issues.
The widget has 2 graphics and 3 fields. It performs well; however on saving, closing and re-opening the stack, there is a non-trivial delay in the widget appearing on the card. If 3-4 copies of the widget this can be upward of 5 seconds, which really isn't great.
Modifying the code slightly to create and use a normal group performs ideally.

The widget was built based on the lesson https://lessons.livecode.com/m/98525/l/ ... ipt-widget
so there is a createVisualControls, layoutVisualControls and updateVisualControls handler etc. Code and external available at https://github.com/stam66/tristate

I can see no way to debug the actual widget running; using log as per lcb externals leads to an instant crash with LC exploding off the screen..., so it's impossible to see where the bottleneck is... and yeh put doesn't work either. Answer does work but is quite clumsy...

Also - is there way to see if a widget has been instantiated already without having to track a script local variable? Presumably when stack is closed the script local is deleted and the widget will have to keep creating it's elements every time the card is shown - unless I misunderstood or missed something important (both full possible!)

Any suggestions?

Many thanks
Stam

[LCMark]

@stam: I'll let Ali answer these question; however, I think the speed issue is probably for two reasons...

One is due to using `the mouse is up` in layoutVisualControls - this will cause a brief pause to check the event loop for mouse messages.

Then (subsequently) if the mouse is up (which it almost certainly will be on creating the controls) it calls layoutVisualControls which will then do blocking moves on controls which take 200ms.

[livecodeali]

Hi stam,

You should be able to debug the script widget in the normal way when developing it, with breakpoints. If this is not working then I'm not sure why, although if your widget identifier starts com.livecode. then you will need to put true into gRevDevelopment to get its breakpoints to trigger.

Another way to see if a script widget has been instantiated I guess would be to do the following (assuming the script widget has child controls)

Code: Select all

command createVisualControls
   if there is a control 1 of me then
      exit createVisualControls
   end if
   ...

[livecodeali]

I had not noticed that `put <string>` does not work from a script widget... that was certainly not intentional! I think the failure of log is to do with a pre-existing issue about calling handlers implemented outside the widget which we're hoping to resolve asap.

[stam]

Another way to see if a script widget has been instantiated I guess would be to do the following (assuming the script widget has child controls)

Code: Select all

command createVisualControls
   if there is a control 1 of me then
      exit createVisualControls
   end if
   ...

Thanks Ali, that may be the ticket - wasn't sure what syntax would be as usual 'group' syntax like graphic x of me doesn't work. I'm hoping I can bypass re-instatiation and hence delays on first draw, I guess I'll see soon

[stam]

I had not noticed that `put <string>` does not work from a script widget... that was certainly not intentional! I think the failure of log is to do with a pre-existing issue about calling handlers implemented outside the widget which we're hoping to resolve asap.

Hi Ali,
I posted this because I can't overcome a problem with my script widget:
While it performs perfectly as expected, when opening a stack with this script widget saved on a card, there is a palpable delay between the card showing and the widget actually appearing and this delay seems to increase linearly with the the number of widgets added to the card.

I've tried a number of things with the code including bypassing as much as possible during openControl, but this seems to have zero impact and similarly 'Lock Screen' has no impact either. Could this be an issue specific to graphics? (I'm sure this was an issue with LC 9.6.2 or 9.6.3 that was solved with Lock Screen - but not sure if that applies to script widgets?)

Many thanks for your help,
Stam

[bn]

I would like to chime in:

The slowdown when using Stam's tristate widget is so bad that it is almost prohibitive to use.

StartUp is slow (seconds) when one or more of the script widgets are on the first card. Navigation to a card with the widget on it is slowed down(second+)

This does not happen with the "Square" script widget nor with "Label field" but those are bare bone script widgets.

Either there is something specific to "tristate" widget or more complex script widgets are currently too slow. This is on an arm MacBook Pro running natively. The times would increase on slower hardware.

Stam's widget can be found here:

https://github.com/stam66/tristate/blob ... codescript

Kind regards
Bernd

[LCMark]

I've tried a number of things with the code including bypassing as much as possible during openControl, but this seems to have zero impact and similarly 'Lock Screen' has no impact either. Could this be an issue specific to graphics? (I'm sure this was an issue with LC 9.6.2 or 9.6.3 that was solved with Lock Screen - but not sure if that applies to script widgets?)

@stam: Did you try removing the line `if the mouse is up then updateIndicatorForValue` from `layoutVisualControls` - my reading of the code is that that will run whenever the control is opened and every time a property is set (assuming the mouse button is *not* down, which is the most common case).

[bn]

I think I found the reason for the slowness. It turns out it is specific to the triState widget.
The move of the indicator is done by an animation. (Move to loc in 200 milliseconds) and this was also happening on "openControl"

Blocking the animation with a conditional to exclude the opening of the control makes the widgets appear instantly.

https://github.com/stam66/tristate/issues/3

Thank for all the hints and the script widget.


Kind regards
Bernd

[stam]

I think I found the reason for the slowness. It turns out it is specific to the triState widget.
The move of the indicator is done by an animation. (Move to loc in 200 milliseconds) and this was also happening on "openControl"

Blocking the animation with a conditional to exclude the opening of the control makes the widgets appear instantly.

https://github.com/stam66/tristate/issues/3

Thank for all the hints and the script widget.


Kind regards
Bernd

Bernd, I can't thank you enough for you tireless help with this widget!

[stam]

I've incorporated Bernd's fix and works perfectly now!

As expected the issue was my code

Final version available here: https://github.com/stam66/tristate