Some oddities with WebControlWrapper.

I have developed a custom control that attach some data to HTML events (touchstart, mousedown…) and then send this data to the WebApp.
The events are linked to the control with Xojo.addListener() and sent using Xojo.triggerServerEvent().
Events received from the custom control get translated in custom application events with RaiseEvent().
I’m using this control embedded in pages at design time and as part of WebContainers dinamically created/embedded/destroyed at runtime.
All it’s working very fine.

In some cases, when the control it embedded in a container, I’m receiving events from the browser to the control also after the Close() event gets handled.
In this cases the control code it is in the ExecuteEvent() and when the RaiseEvent() method is called I’m getting a NilObjectException.
Inspecting “self” with the debugger I see that the Name property is blank.

This cases are frequent when using the application from a mobile device (a phone) and it seems very related to the browser type.
The symptom seems a some sort of “out of sync” or “not in order” flow of events between the application and the browser.

I don’t know if I’m doing something wrong and in this case I don’t know what to look for.
At the moment I have found a solution with a boolean that keeps track of the Close() event and prevents any further handling of what gets received from the browser.

There is some explanation about this strange behavior?

Best regards.

When you close the control do you remove the handlers ?
AddHandler should always have a matching RemoveHandler

Thank you Norman, I’ll investigate on this.


You could wrap your event calls in Try-Catch constructs so that this doesn’t happen anyway.

There is an unhandled condition in my application.

The events generated from the custom control are not received/processed by the application in the same order they are generated.
This behavior it is caused by the way the communication takes place between the browser and the application.
To remedy this when events are received they are put in a queue for the right order of delivery to the application.

The error was caused by calling control’s Close() method in a event handler while the queue was not empty.

I apologize for the noise.
Thank you again for your help.

For what it’s worth, we also do this on WebCanvas. Because we use a diff algorithm to make updates faster, things must be executed in the right order. For that, if we get out of sync (instruction 6 arrives before 5), we trigger a full refresh and start over at zero.