ExecuteJavascript ignored

  1. 3 months ago

    Michael G

    Mar 6 Pre-Release Testers, Xojo Pro
    Edited 3 months ago

    Strangely, in using ExecuteJavascript("JS command"), in some parts of my code it is executed perfectly (i.e. I can step into it and it causes the command to be run). In other parts of my code, the *exact same* command, inserted as a testcase, is simply ignored - i.e. I cannot step into it and it is simply skipped over, and no command is executed.

    More detail: Both calls to ExecuteJavascript are within the same method, but under different sets of timer settings; the working example is being executed under a synchronous mode, while the non-working example only uses a timer to communicate with the web view. Xojo 2007 r1 for backwards compatibility, iOS target.

    Ideas as to why this might happen?

  2. Tim S

    Mar 6 Canterbury, UK

    How can you "step into" it?

  3. Michael G

    Mar 6 Pre-Release Testers, Xojo Pro
    Edited 3 months ago

    Should have mentioned ExecuteJavascript is a method that calls a mobile extension that emulates the ExecuteJavascript for Web applications, for cross-platform compatibility purposes.

    Clear as mud, right?

    So, my ExecuteJavascript is actually a method that is being skipped over in some cases and not in others from within the same method. I'm trying to figure out why..

    method blah(Message as text)
        // process the Message
        select case xxx
          case 01
            // set up some timers
            ExecuteJavascript(cmd01)    // this is executed and results are updated in the web view on iOS
            ExecuteJavascript(cmd02)    // this is also executed and results are updated in the web view on iOS
          case 02
            // set up other timers
            ExecuteJavascript(cmd02)    // this is passed over, no results - SAME cmd02 as above
          case 03
            ...
          end case

    The reason I mention the timers is that seems to be the only significant change between the 2 cases; the rest is simply command generation.

  4. Greg O

    Mar 6 Xojo Inc

    If you’re using a Timer as opposed to a WebTimer, that could be the cause as the Action event fires on the main thread.

  5. Michael G

    Mar 7 Pre-Release Testers, Xojo Pro
    Edited 3 months ago

    Whether the timers fire on the server or client side, how do/es that affect execution of a method that does not depend on a timer? Deep inside the nested methods, the communication to the web view is triggered by a timer, but this doesn't even get into the first call to ExecuteJavascript, but merely skips it in the case 02 example above.

    Just for grins, I inserted the exact same call into case 01, ExecuteJavascript(cmd02), where it ran perfectly.

    Also, I meant Xojo version 2007 r2.1, not r1 above.

  6. Greg O

    Mar 7 Xojo Inc

    You said...

    ...while the non-working example only uses a timer to communicate with the web view

  7. Greg O

    Mar 7 Xojo Inc

    Before we get too much further... what kind of project is this? I assumed it was a web project since you were referring to ExecuteJavascript and Web Views, but your comment about 2007r2.1 makes that not possible.

  8. James S

    Mar 10 Pre-Release Testers, Xojo Pro

    if Greg is right about the timer vs webTimer, and it certainly sounds to me like that is likely the case not withstanding the Xojo version or if it’s a web project or not, I can say for sure that you need to get the proper session context setup for the control.

    The web framework is a little unpredictable about what things it will do and which things it won’t from an event that shows up in the main thread like a timer. For example there is no problem setting the text of a label control from the main thread. The label control seems to know what pipe it needs to send the change down. However other things like setting the content of an html frame absolutely have to have their session object set in order to have the data go there. I don’t know if executeJavascript is one of those things that absolutely requires it or not but I’ll bet it is. I just always get the session object for the control now everywhere an event comes in the main thread and things work fine.

    I just put something like this somewhere before accessing the controls properties:

    Dim Context As New WebSessionContext( app.SessionForControl( Me))

    assuming that Me is the control you’re talking to, otherwise put the control reference there.

    This is somewhat voodoo in my mind as you don’t have to actually do anything with the context object once you fetch it, the act of having one in scope is enough to make it work. There are examples of that in the web documentation as well I believe.

    Or... perhaps you are talking about something totally different ;) In which case the above will not be helpful at all ;)

  9. Greg O

    Mar 10 Xojo Inc

    The web framework is a little unpredictable about what things it will do and which things it won’t from an event that shows up in the main thread like a timer. For example there is no problem setting the text of a label control from the main thread. The label control seems to know what pipe it needs to send the change down. However other things like setting the content of an html frame absolutely have to have their session object set in order to have the data go there. I don’t know if executeJavascript is one of those things that absolutely requires it or not but I’ll bet it is.

    It’s never safe to set text in a control from the main thread. It may seem to work in debug mode, but that’s only because you have only one session. When live, it’ll be sent to whichever session currently has an event in progress.

or Sign Up to reply!