I’m currently wrapping a jQuery based UI library. I forward the UI library specific events to WebControlWrapper’s ExecuteEvent, which in turn then raises the event in my WebControlWrapper subclass. This all works fine.
Now in some of the events the user of the WebControlWrapper subclass should be able to cancel the jQuery standard event handling (with event.preventDefault). Since the WebSDK is asynchronous, one cannot define the event with a Boolean return value as in a Desktop class.
What is the best approach to this? I thought of the following, but maybe there is an easier solution:
In a JavaScript event:
... function(event) {
add event.clone to queue
event.preventDefault
Xojo.triggerServerEvent
}
The Xojo event:
Function SomeEvent() As Boolean
In the WebControlWrapper’s ExecuteEvent method:
If RaiseEvent SomeEvent Then
ExecuteJavaScript( execute the JavaScript queue )
End
I’m not sure what exactly you’re trying to do for what reason but I Wrapped JQueryUI and JQuery if you want to check it out. You can use it or borrow implementation concepts from it if you want. It’s not 100% complete but its mostly there.
I should have explained it better. Here is another example:
Desktop: Event KeyDown(key As String) As Boolean <— Returning True cancels the standard behavior of the Xojo framework
WebApp: Event KeyPressed(details As Realbasic.KeyEvent) <— No return value, no cancelling of standard behavior possible
I understand why there is such a difference, especially for a KeyPress event firing all the time.
But what if in one specific case you need to be able to cancel the standard behavior - how would one approach that?
If you need to cancel an event, you’ll need to make that decision in your JavaScript code. Values returned from the server are executed after the key event has completed on the browser in a completely separate event.
But if there is a specific case where it is necessary, what would the best approach be in a WebControlWrapper subclass?
As I wrote, I’m thinking of queuing the event in JS, calling triggerServerEvent, then sending a cancel or execute command back to the client with ExecuteJavascript to either clear or execute the queue of delayed events on the client side. Does that make sense or is there a better approach?
Sometimes if I’m queueing up really long script or loop I put in points to check for breaking.
As the script runs or loops it will stop at any of the breakpoints if the stop variable is set to true.
Your execute javascript would then simply set this variable to true to stop it.
Just keep in mind that there are certain actions which require that it be in the same event as the user input event. Things like showing a new window. Otherwise, what you suggest should work just fine.