HTMLViewer - long time to get TitleChanged event

  1. 4 months ago

    Tim S

    Oct 11 Canterbury, UK

    I've been doing some timings of how long it takes between issuing:

    myHTMLViewer.ExecuteJavaScript ("getTitle();")

    and getting the subsequent TitleChanged event. The javascript function getTitle() is very short:

    function  gettitle ()
         {
         titleCount++;
         document.title = "myEventMarker:GetTitle:" + titleCount + ":" + titlestuff;
         }

    where titlestuff is a 100 byte string (the prefixed stuff is to distinguish between wanted/unwanted events and the various wanted ones).

    Now, under macOS, the time in question is a couple of milliseconds at worst. However, under Win7 in a virtual machine (VirtualBox under macOS), using the IE11 renderer, this time consistently shoots up to 110 msec, there or thereabouts. Similar code has been tried by someone with a real Win10 machine, he reports similar timings.

    I'm now working on porting an app to Windows. Historically I've used the StatusChanged event to pass data from an HTMLViewer back to Xojo, but this may cease working at any time. The problem with using the TitleChanged event is the data length limitation of some 200 bytes (under the IE11 renderer). If I have a few k of text to recover from the HTMLViewer, that could take some seconds which will not work well with the rest of the app.

    Is there a reason for this long lag with the HTMLViewer/TitleChanged under Windows? Any way I can mitigate it or use an alternative strategy?

  2. Tim S

    Oct 19 Canterbury, UK

    Just submitted Feedback Case #53769 about this.

  3. 6 weeks ago

    Michael D

    Jan 3 Pre-Release Testers, Xojo Pro

    Tim, are you testing in 32 or 64 bit builds?

    I'm running into something which may or may not be related: on Window builds, it seems that I'm losing titleChanged events - my Javascript can set the title several different times, but it seems like only some of the changes are triggering the titleChanged event inside Xojo. On mac builds I have no problem.

  4. Tim S

    Jan 4 Canterbury, UK

    Errr, looks like 64 bit. Seems like Xojo are still thinking about the slowness of these under Windows.

    Meanwhile I took up a suggestion of Julian Samphire (sp?), who mentioned websockets. So now I have incorporated a websocket server in my app and will in general terms avoid statusChanged or titleChanged when communicating to/from an HTMLViewer.

  5. Michael D

    Jan 4 Pre-Release Testers, Xojo Pro

    I've been testing another way in which you set window.location via javascript, which then triggers the CancelLoad event in the HTMLViewer - this seems to be working better for me (x64 Windows build, HTMLViewer native).

    Tim, have you tried that method out for speed?

  6. Tim S

    Jan 4 Canterbury, UK

    @Michael D I've been testing another way in which you set window.location via javascript, which then triggers the CancelLoad event in the HTMLViewer - this seems to be working better for me (x64 Windows build, HTMLViewer native).

    Tim, have you tried that method out for speed?

    Errr, sorry, which one? websocket or window.location?

or Sign Up to reply!