Yesterday I struggled for almost an hour with a very strange problem (Button(s) NOT triggered), when I want to pick a text file via Activity Starter (from eg. /storage/emulated/0/) and then read it with the File component.
The problem also occurs when the Activity Starter blocks are disabled. Only when these are deleted AND the screen is reloaded, it works again. Otherwise something has to be changed in the text field of the label so that the button is triggered.
The attached short video shows the behavior the fastest. This only happens with Companion, not with the APK. In Kodular, the problem does not occur.
The duplicate (but disabled) Click events for Button1 and Button2 look problematic.
I wonder how they ever got in there.
I read in one of the AI2 internals docs that events are queued so they donāt
interfere with one another. Are they queued by block ID or by event name?
Maybe the execution requests are being sent to the wrong (disabled)
event blocks?
Alright. I understand why this is happening and, unfortunately, itās my fault.
Until recently, disabling event blocks was problematic because they didnāt emit any code but the previously defined event handler hung around (see PU thread about incremental code updates). I wrote a change that causes disabled blocks to emit a call that deletes an existing registered event handler. Code generation also mainly follows a top-down left-right ordering over blocks (first global, then procedures, then events). This means that your program outputs code for Button1.Click and Button2.Click, and then the disabled versions of those event handlers emit code to unregister them. If you move the disabled event handlers above the enabled ones and reload the project youāll see that the buttons work fine because now the unregister calls are emitted before the register calls.
Weāll need to think about what to do here. On the one hand, Iām surprised that the error mechanism was made robust enough to not raise an error because of the clashing event handlers and I would have expected the duplicate event handlers to be marked as errors. On the other hand, the behavior does make sense and my code to emit the unregister instruction needs to be made more robust to detect this scenario. I think the latter is more appropriate but Iām curious to hear what others think.
I agree and it was unexpected for me that this was possible. However, I donāt know how pervasive this is and I decided it didnāt make sense to enforce that rule because it might break existing projects where this has been done by suddenly making errors out of things that werenāt.
Since this is not the case with the compiled app (APK), this is probably not a problem for existing apps. However, if you want to change something on an app and first disable the old version (some blocks) and then rebuild these, many, like me, will surely be confused when testing this new version with Companion.
(In my experience, many do.)
If this should not be possible with Companion, the user / developer should also be notified by an error / warning message.
This is the first time I have ever seen this, so it does not look like it's worth rocking the boat.
Bury it in the To Do list, and remember it for the next person to get this.
The user level fix is to add a hidden 1x1px disabled button/whatever and reassign the disabled event to the hidden dummy component, to avoid interference, but keep the code in reserve.