Odd WebSDK 2.0 update of enabled

I’ve some odd behaviour going on when handling whether a control is made enabled or not under WebSDK, and I have no idea whether this is intended behaviour (and I therefore need to be reacting to something I don’t know about), or whether this is a bug.

Two buttons on WebPage: My own custom test button, and a Xojo button which just toggles the enabled status of my test button (literally x.enabled = not x.enabled) (i’ve got a Checkbox mirroring the Enabled state of the test button, to double-check visually that the status really is changing).

  1. All draw correctly when application started.
  2. Click Xojo button, test button is set to disabled.
  3. JS code gets a request to re-draw, this.enabled tested and the button drawn in a disabled state.
  4. Click the Xojo button, test button is set to enabled.
  5. NO request to the JS code to redraw - visual state remains disabled.
  6. Click the Xojo button, test button is set to disabled.
  7. JS code DOES get a request to re-draw, but of course the button is already drawn disabled.

It would seem that an event is only being fired in the JS code when the enabled state transitions from true > false but not when false > true.

I cant imagine that this is intended behaviour, but if it is, what am I meant to be watching for?

OK, no replies.

If anyone else gets this type of thing, the only solution I could find for this was to manually shadow the Enabled property in my control with a get/set, the more important of the two being the set:

WebUIControl(Self).enabled = value
Self.UpdateBrowser

So that it manually triggers a control update in the JS regardless of what enabled is set to. Interestingly enough, a true setting only requests the control to update once, so at least that’s being dealt with within the framework. Just would have been nice to get an update when setting to false as well.

Have you filed a bug report in Feedback about this?

Does Xojo have automated unit tests so we don’t need to file bug reports if basic functionality doesn’t work? Typescript only gets it so far… I understand there’s upfront cost but ensuring proper functionality is there and preventing regressions is important and seems key given the limited resources for manual testing Xojo has

3 Likes

Not yet, but I will be.

The original post was originally just to find out whether I was doing anything wrong here, and was listening on the wrong event. I’ve now tested all of the events that are being received, and the only one that would catch the changes is the deferred event - but that only seems to fire when clicking off the control, it’s not an immediately response.

1 Like