OutOfBounds with Events

Hello,

I wrote a custom web control (a grid similar to Einhugur’s data grid). I am implementing several JS events such as: blur/focus (for text fields in table cells), click/dblclick/mousedown/mouseup/mouseover/mouseout and pass them on via Xojo.triggerServer event.

While mouseover/mouseout events work without any issues, clicking on my control results in an OutOfBounds Exception:

[code]Unhandled OutOfBoundsException
Message:

Stack:
RaiseExceptionClass
RaiseOutOfBoundsException
rbframework.dylib$2451
REALbasic.MouseEvent.Location.Get%o<REALbasic.Point>%o<REALbasic.MouseEvent>i4
WebControl._ExecuteEvent%b%osA1v
WebControlWrapper._ExecuteEvent%b%osA1v
WebControl.!_ExecuteEvent%b%ssA1v
WebSession._HandleEvent%%oso<HTTPServer.HTTPRequestContext>
WebSession._HandleRequest%i4%oso<HTTPServer.HTTPRequestContext>
WebApplication.HandleHTTPRequest%%oo<HTTPServer.HTTPRequestContext>
HTTPServer.HTTPRequestThread.Event_Run%%o<HTTPServer.HTTPRequestThread>
rbframework.dylib$1267
_pthread_start[/code]

When testing my code in pure HTML/Js (separate file) everything works fine - no errors in the JS console. I just see that it triggers three events: mousedown, mouseup and click. Might this be the issue causing an OB-Exception in Xojo?
Additionally, the OB-Exception is only thrown in the compiled app. When debugging, the IDE gets the focus but no exception is being raised.

Edit: the ExecuteEvent is added to the control, however not implemented yet (just returning false. Changing that to true doesn’t help either.)

It’s likely that the mouse events are being captured by the framework, which means you’ll have to match our signature exactly. What happens if you change the name of the event you are sending in triggerevent and handle it yourself in ExecuteEvent?

I was just about to narrow it down to that when you replied. It’s exactly that - though just mouseup/down are affected. Changing the event name submitted to my control worked like a charm.

However - if you’re already capturing those events, why don’t you supply them to the WebCustomControl class? That way it’s doubling traffic to handle the exact same event twice…

The problem is that the mouse events are specific to each control. The fact that they are captured by the framework is an unfortunate side effect of the original design. When we designed the WebSDK, we decided it would be better to give developers the option to implement mouse events themselves, rather than locking them into something they can’t control.