Web App Spinner Issues and Round Trips to the Server

@Greg O’Lone ,

Many of us in the WebTimer and WebThreads several forum threads are trying to:

  • Show a Spinner or a Progress Bar
  • Hide or Disable other Controls
  • Run our code
  • Show or Enable other Controls
  • Hide a Spinner or a Progress Bar

However, WebTimers and WebThreads don’t run the code in the same way as running the code normally.

Is there any way to make a call to update the UI during a round trip?

This would be ideal:

  • Show a Spinner or a Progress Bar
  • Hide or Disable other Controls
  • Update UI
  • Run our code
  • Show or Enable other Controls
  • Hide a Spinner or a Progress Bar

Use a timer. UI updates take place each time an event ends. That is the perfect control to do that.

I think I tried that, but will try again. I seem to recall the timer didn’t fire until the code finished running. I’ll report back.

I just tested. The Timer doesn’t run until after the round trip. So I see nothing happen for a bit of time, and the SpinnerTimer fires after the method finishes.

[code] SpinnerTimer.mode = Timer.ModeSingle // set to 10ms and calls SpinnerUpdate( “Show” )

// Loading a page to slow the method down.
dim theSocket as new HTTPSecureSocket
Call theSocket.Get ( “http://campsoftware.com”, 30 )
Call theSocket.Get ( “http://campsoftware.com”, 30 )
Call theSocket.Get ( “http://campsoftware.com”, 30 )
Call theSocket.Get ( “http://campsoftware.com”, 30 )
Call theSocket.Get ( “http://campsoftware.com”, 30 )

DetailSave
DetailLoadDo(nil)

SpinnerUpdate( “Hide” )[/code]

If you think about it, it is impossible for the UI to be updated during a round trip.

The code itself on the server is as fast as a Desktop app. But communicating with the browser takes sending the data, then wait until it gets there. On average, 100-200 ms. That is unavoidable.

But the round trip itself takes at most 400 ms on a slow network.

When you say “during the round trip”, I am not sure that is what you mean.

There is a way to have something move on the screen while a round trip occurs, though : JavaScript. And more to the point, in Xojo Web, WebAnimator.

Won’t all that be executed after the roundtrip occurs as well?

That is where scheduling is important.

But once again, I feel you may be confusing what a round trip is. Let us say I want to update the UI. Xojo sends the code to the browser, and when done the browser confirms. That takes at most half a second. Not dozens of seconds or minutes.

Let us say I plan on doing something lengthy. It should NEVER be in the same event. Tight loops are out of question because precisely they freeze the UI (and there is no round trip there).

If you use a timer loop to update a Weblistbox, for instance, you can push a progressBar or have a spinner without any issue, because there will be a succession of events, and not a single one that updates the UI at the end.

Hal,

In your event that responds to the user event from the browser (like a button action event):

  • show your activity indicator with a “progressWheel.show” or somesuch

  • trigger a web timer that calls your intended, slower, code in its action (with a period of ~ 250-500ms but you might want to experiment)

The server will send out your UI update to show the progressWheel, then the browser will call back after the timer expires and the timer’s action event will actually perform the desired function on the server and then respond with the data intended for the browser.

It’s a bit roundabout and takes some getting used to but it seems to work fairly well.

Thanks for that Steve. I tried using WebTimers t call my slow code which results in SessionsNotAvailableException even with setting the WebContext in the Timer. So then I moved to WebThreads which result in JavaScript Null errors.

The exact same code without WebTimers or WebThread works great.

That’s a great reason to use WebThreads. I’m all set up for that, but I’m getting reproduceable Javascript Null Errors due to the timing. Here’s the code with an updated version at the bottom of the thread:
https://forum.xojo.com/36201-webthread-webcontainer-embedwithin-javascript-null-is-not-an-ob

Is your timer a property of a persistent object in your app?

I think if you ensure that the timer doesn’t fall out of scope after you trigger it you should be fine - it’s not unlike the desktop app timer, where it has to be part of a window or attached to something else (like the app) so it remains in scope…

[quote=297770:@Steve Upton]Is your timer a property of a persistent object in your app?

I think if you ensure that the timer doesn’t fall out of scope after you trigger it you should be fine - it’s not unlike the desktop app timer, where it has to be part of a window or attached to something else (like the app) so it remains in scope…[/quote]

When I was using timers, they were part of the Window, but was getting SessionsNotAvailableExceptions. Here’s my sample project:
https://forum.xojo.com/36161-45693-web-app-sessionnotavailableexception-after-dimming-new-we