ExecuteJavascript ignored

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?

How can you “step into” it?

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…

[code]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[/code]

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.

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.

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.

You said…

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.

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 :wink: In which case the above will not be helpful at all :wink:

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.