WebButton Event Issues

  1. 3 weeks ago

    Cameron D

    Feb 5 Colorado

    Hello,
    I'm running into an issue trying to add different states to a WebButton object, (Hover/Up/Down) using different styles.

    I have added the following Event Handlers to my WebButton object, which was dragged onto the layout from the library.
    Action

    Initiates action to move to the next page

    MouseDown

    me.Style = button_medium_down

    MouseEnter

    me.Style = button_medium_hover

    MouseExit

    Me.Style = button_medium_up

    MouseUp

    Me.Style = button_medium_up

    When the next page is loaded, and the previous one closed, I get the following errors in the browser console:
    1. This occurs whenever I move the mouse cursor on the web page

    framework.js:3495 Uncaught TypeError: Cannot read property 'children' of null
        at button.field (framework.js:3495)
        at button.controlObject (framework.js:3499)
        at HTMLDocument.Xojo.input.move (framework.js:1645)

    2. This occurs whenever the mouse cursor exits a WebControl on the page, regardless of whether or not there is a handler for that control.

    Uncaught TypeError: Cannot read property 'children' of null
        at button.field (framework.js:3495)
        at button.controlObject (framework.js:3499)
        at HTMLDivElement.Xojo.input.exit (framework.js:1740)

    Additionally, MouseEnter and MouseExit Event Handlers for other WebButton controls do not fire.
    These errors are not consistent. Occasionally, it seems to work as intended. I've tried running using both 2018R3 and 2018R4 and I've used Chrome, Firefox and Opera, all to no avail. No error is shown on the WebPage, and the Xojo debugger shows no related errors or warnings.

    Thanks in advance

    Yeah, don’t use mouse events to set styles. If you look at the style definitions, there are four states. Normal, hover, pressed and visited. Put everything into a single style and apply it once.

  2. Greg O

    Feb 5 Xojo Inc Answer
    Edited 3 weeks ago

    Yeah, don’t use mouse events to set styles. If you look at the style definitions, there are four states. Normal, hover, pressed and visited. Put everything into a single style and apply it once.

  3. Tobias B

    Feb 6 Pre-Release Testers, Xojo Pro Bern, Switzerland

    sure, using the Mouse events, esp. for setting styles is not a good practice in web projects as these are asynchronous, there is latency and a better way is available. However - to my understanding this (and other legitimate actions using Xojo code) should not cause JavaScript errors in the client side framework. I've come across similar situations myself and have the impression there are quite some try/catch blocks missing in the JS-Framework to ignore errors in case the object that shall be manipulated is not / no longer available.

  4. 2 weeks ago

    Greg O

    Feb 6 Xojo Inc

    To fix this, you’ll have to make it so that once the user clicks the button and the action is taken to redirect away from the page, your mouse exit/enter/hover events are ignored. Basically your code is sending commands to controls that are being torn down.

    If you were doing this in a desktop project it would be like changing the Enabled state of a control after calling Window.Close. There’s a good chance that the control doesn’t exist any more and you’ll get a NilObjectException.

  5. Greg O

    Feb 6 Xojo Inc
    Edited 2 weeks ago

    @Tobias B However - to my understanding this (and other legitimate actions using Xojo code) should not cause JavaScript errors in the client side framework. I've come across similar situations myself and have the impression there are quite some try/catch blocks missing in the JS-Framework to ignore errors in case the object that shall be manipulated is not / no longer available.

    If we were translating your xojo code to JavaScript, I might agree with you, but the number of try/catch blocks we would have to add to protect against code that can happen in any order and at any time would seriously slow code execution and responsiveness in the old framework, and refactoring the existing framework is impractical for a from-scratch framework that was started nearly 10 years ago.

    FWIW, we are tackling issues like this in the new web framework, specifically to make it less likely for your day-to-day code to result in JavaScript errors.

  6. Tobias B

    Feb 6 Pre-Release Testers, Xojo Pro Bern, Switzerland

    @Greg OLone FWIW, we are tackling issues like this in the new web framework, specifically to make it less likely for your day-to-day code to result in JavaScript errors.

    Great to hear the new web framework will be designed to be more robust against such problems!

or Sign Up to reply!