Time and again have I explained that Xojo is event driven, and trying to make synchronous an asynchronous event is futile. Well. Never say never. I may have to eat my hat.
I am trying to improve the WebListBox using JavaScript to get certain values.
For instance the actual size in pixels of a column (not the unusable ‘*’). I would like to have a neat method called ColumnWidth(columnnumber) as Integer. The way it works is I get that value in JavaScript, then use Xojo.TriggerServerEvent to get that value in the WebSDK control’s ExecuteEvent. The same process could be done with HashTagChanged as well. In both cases, the value returns from another place in the program than the ColumnWidth method which initiated the request.
I have tried a horrid tight loop to monitor the event and its return value with App.DoEvents (before you scream, this is a web app which is intrinsically a Console app so it should be OK). Problem is the event is frozen until the end of the method.
Maybe it is not possible at all. But if there were a way, that would certainly be very nice.
In your ColumnWidth method, could you pass along a “return key” (probably a hash string) to the ExecuteJavaScript, then ColumnWidth periodically checks a session variable (maybe dictionary with return keys as keys) for a returned value.
In the mean time your TriggerServerEvent passes along the return key along with the column width in its payload for the server side event to set the session var with.
Would that work?
Oh, and of course something cleans up those dictionary values either after use or after a timeout if their key has a leading date/time component or similar.
So here’s the problem… When your Xojo code executes in response to an event from the browser, nothing is sent to the browser until the event chain has finished. The only thing you get with this is an endless loop that will lock up the session, waiting for a response that will never come.
IMHO, I think that this issue should be tackled at some point in the future by Xojo (note that I think this feature should be for WebControlWrapper only).
There are cases where it is almost impossible to find a solution when doing things asynchronously. I worked about five weeks full time on wrapping w2ui and in the end I stopped this project because of this very issue and went back to my old self-devloped PHP framework for my w2ui web applications.
[quote=230776:@Eli Ott]IMHO, that this issue should be tackled at some point in the future by Xojo (note that I think this feature should be for WebControlWrapper only).
There are cases where it is almost impossible to find a solution when doing things asynchronously. I worked about five weeks full time on wrapping w2ui and in the end I stopped this project because of this very issue and went back to my old self-devloped PHP framework for my w2ui web applications.[/quote]
At the moment, I shadow what I can so instead of going real time, I simply interrogate the shadowing property.
From what Greg just posted, it seems as they have not really solved it for themselves.
[quote=230776:@Eli Ott]IMHO, I think that this issue should be tackled at some point in the future by Xojo (note that I think this feature should be for WebControlWrapper only).
There are cases where it is almost impossible to find a solution when doing things asynchronously. I worked about five weeks full time on wrapping w2ui and in the end I stopped this project because of this very issue and went back to my old self-devloped PHP framework for my w2ui web applications.[/quote]
There’s nothing to solve. Your Xojo code is compiled code which runs from beginning to end. Even if we did have the ability to send commands directly to the browser after every line of code, it’s still asynchronous and the response comes from the browser sometime in the future. This is just the way th internet works.
[quote=231005:@Eli Ott]I understand that. Synchronous write/read works with TCPSockets. Why not with web sockets. Something along this:
[code]Me.SynchronousExecuteJavaScript( someCode )
Do Until Me.someFlagSignallingTheResultHasArrived
Me.Poll()
Loop
… = Me.ReadResult()[/code][/quote]
That is basically what I tried. ExecuteEvent was delayed until the end of the method, so the doUntil could have run forever if I had not placed a timeout.
I also thought about doing the JavaScript and WebSDK control in a thread, but since the WebSDK basically executes in the main thread, no luck there either.
As Greg says, this is the way the Internet works. I finally released getTextWidth and getTextHeight in RubberViewsWE in asynchronous form yesterday. I know it will take users getting used to that way of launching a request and get the result later, but better have the feature like it is than give up on it.
This has nothing, absolutely nothing to do with how the internet works. It’s a feature missing in the Xojo web framework. I can understand if Xojo doesn’t want to tackle this they’re free to do what they want. I just expressed my opinion that I think for wrapping Javascript control libraries this is a must.