How to see (Signal) start and end of a HAT-block polling cycle?

[CvanLeeuwenFt]

My idea is to use a HAT-block as notification for a change in a state of, for example, a actuator-object. Because of the nature of the HAT-block implementation, the change of states needs to be informed that it has been processed and set to false, otherwise the HAT-block will not see the next change.

However because there can exist more then 1 instance of this HAT-block, the HAT-block itself could not signal back that the change of state has been processed by all the instances.

How can I see that the processing of (this) HAT-block instances are going to start and that they are all processes by the polling mechanisme of Scratch? How can I, for example, hook up methodes to "before start of a polling HAT-blocks cycle" and "after end of a polling HAT-blocks cycle"? There can exist a relation with #101.

[ericrosenbaum]

There are two workarounds for this problem that I know of.

1) Edge-triggered hats trigger when the hat function changes from returning false to returning true. So if the hat function simply watches a state outside it, and does not modify it, it will always work as expected. If you can do it this way, it's the simplest.

2) If the hat function really has to modify some state variable, like resetting a flag, I've found that simply waiting a short interval (50 to 100 milliseconds, or well in excess of one frame at 30fps) before resetting the flag is enough to allow several hats that all check that state variable to trigger. It's sort of gross but it works. There's an example here: https://github.com/ericrosenbaum/spotify-extension/blob/gh-pages/extension.js#L523

[CvanLeeuwenFt]

ericrosenbaum Thanks for your advise. I already found out what you are mentioning under (1). Solution two will make my application to slow. I have to deal whit a fischertechnik interface, which is working at a cycle range of 15 ms. I wil try to avoid extra delays if possible. My background is C# and event driven programming. But with the HAT-blocks is rather difficult to create nice dynamic notifications. It must not to difficult to create two callbacks (events) inside Scratch to signal the start and end of the polling cycle.

[ericrosenbaum]

Yes, there are limitations in our system, and sometimes they require workarounds. We do not plan to make any changes to Scratchx. The Scratch 3.0 extension protocol is currently in development and it may provide support for event-driven hat blocks.