Strange RuntimeException

Hey guys,

I’m getting a runtime exception in the Xojo framework code. My app had been running fine until I copied some objects from another app and did some updates to some classes and stuff. Now I get this and can’t figure out what is causing it. I know it’s the Xojo Framework as I have no method named “CreateControls” and when the exception breaks execution in the debugger, no code is shown. Just a blank debug window.

How can I fix this? Xojo code “shouldn’t” have unhandled exceptions in it…

RuntimeException
XojoFramework$7154
RuntimeAddEventHandler
DeBrickWindow.DeBrickWindow._CreateControls0%%o<DeBrickWindow.DeBrickWindow>
DeBrickWindow.DeBrickWindow.CreateControls%%o<DeBrickWindow.DeBrickWindow>
XojoFramework$4674
CreateStandAloneWindow
RuntimeCreateWindow
Window.__Init%%o<Window>
XojoFramework$9864
XojoFramework$9864
RuntimeNewObject
DeBrickWindow.DeBrickWindow%o<DeBrickWindow.DeBrickWindow>%
_MakeDefaultView
_LateStartup
XojoFramework$7165
Delegate.Invoke%%p
REALbasic._CallFunctionWithExceptionHandling%o<Object>%pp
XojoFramework$7155
XojoFramework$1266
XojoFramework$1215
__57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_2
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__
___CFXRegistrationPost_block_invoke
_CFXRegistrationPost
___CFXNotificationPost_block_invoke
-[_CFXNotificationRegistrar find:object:observer:enumerator:]
_CFXNotificationPost
-[NSNotificationCenter postNotificationName:object:userInfo:]
-[NSApplication _postDidFinishNotification]
-[NSApplication _sendFinishLaunchingNotification]
_DPSNextEvent
-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
XojoFramework$1274
XojoFramework$1275
Delegate.Invoke%%
Application._CallFunctionWithExceptionHandling%%o<Application>p
XojoFramework$9784
XojoFramework$1274
-[NSApplication run]
XojoFramework$9786
RuntimeRun
REALbasic._RuntimeRun
_Main
main
start

Yeah, I’m hoping someone from Xojo can chime in. The project had been working just fine but I wanted to bring in an updated version of an object from another app. Once I got all the compile errors fixed, now I get this!

Unfortunately, clearing caches did not work.

Looks like I’m going to have to open a private case and also rely on my backup copy…

Grrr…

Try comparing your backup with the “bad” project with my Arbed tool. That might show the difference better.

Yeah, that’s a good idea. I’ll have to do that. Still wish someone from Xojo would chime in…

there

OK, Norman!

Feedback case filed, but I was not able to mark it as for Me and Xojo Only. Feedback kept telling me that cases for release versions may only be marked public or private. That’s what I was trying to do but it wouldn’t let me! So no project attached. If you guys can make it private, I’ll attach the project.

This is kind of interesting because everything occurs at app start up so its not really obvious BUT this isn’t a framework bug

But whats occurring is there is a class instance on a window that has an event handler implemented.
And the constructor of that class also sets up a handler for this same event using addhandler.
A window basically sets up its controls by running code like
a) dim c as new
b) c.setproperties
c) addhandler c.event, addressof method

So when the app starts you get

  1. App creates new default window
  2. when the default window is created a new instance of the class is created calling its constructor (see (a) above)
  3. the constructor adds a handler for the event
  4. now the set up tries to add the event handler (see © above) and you get an exception

Essentially it has two handlers for the same event without having removed one

I attached a much smaller sample to 43553

I get it and all but shouldn’t it throw a more descriptive exception like “trying to handle and event that was already handled” or something like that? The fact that Xojo throws an exception that gives me no information and no code makes debugging it quite difficult. I knew it was something with the event handlers based on the stack trace and I was slowing going through trying to figure out where it was at. But Xojo didn’t make it easy and so I had to do this…

It was certainly one of those things that was so obvious it was staring me in the face yet I couldn’t see it. But not having any spot in the debugger showing me where the error was and nothing but a stack trace referencing framework code I don’t have access to made it really difficult…

Thanks for the help too.

Yeah, so it’s a problem sharing the object between two different applications. In one, I don’t have an instance of the object added to the window - I create them all dynamically so I have to handle all my events using AddHandler calls. In the second app (the one that had the problem), I have an instance of the object on the window and so can implement events right in the object itself.

I think I see where my confusion came in…

In the base class, I implement the “ParametersLoaded” event and implement it with the AddHandler and method. I then have an event definition implemented in the class which is raised in the method. Then I can implement the event in any SUBCLASS. But in this case, I’m not creating a subclass - I’m instantiating the base class directly on the window, so when the constructor is called - it’s trying to construct two event handlers for the same event…

In the example I posted which quite literally does the exact same thing if you add App.unhandled exception & look at the error message it says “Attempting to add a handler for an event that was already handled.”

Your app does as well
You just dont use it in your App.Unhandled exception logging
I just stuck a break point in there to figure out WHAT the error was initially
Then I had to see what was causing it which took me a lot longer to find because it is so early in the app startup

Well don’t I feel silly… :\

It is a curious situation and took me a while to figure out

I’m just glad I could find it, point out the issue to you so you can deal with it rather than have to bug Joe with a framework bug :stuck_out_tongue:

So…

Is there a way to determine if the event is already implemented in the window via code? I’d like to use the same base object without having to comment and uncomment code…I could create a subclass and implement it but then it just makes things messier…

Yes you could try adding the handler & see if it fails in a try catch
BUT that wont help here as the one in your constructor will ALWAYS succeed. It gets done first - see my previous post about the order of creation)
In this case the code adding the second handler is NOT your constructor - its the construction of the window and setting up the event handler you implemented on the instance on the window

So you might say “well that should not cause an error”.
But quite literally this shouldn’t run - certainly not work
If we dont add that handler then we appear to “not implement code as you wrote it” - that event handler would not exist.

It would be nice if we had a way to say “Hey you have this weird set up so we’re not going to compile” but that would require code flow analysis to achieve as it may be that we NEVER run some code and … yeah it gets messy really fast and impossible to know for sure.

But - that your error handler wasn’t using the exception error message might have mislead you
That certainly started me wondering hence why I stuck a break point in there & finally went “AHA !!!”
Then the hunt could really start and it was just a matter of searching for every Addhandler in the constructor to see what was up

OK. Makes sense. I’m not sure why I’m not including the exception’s message in my exception handler. That would have helped. Would have had me scratching my head for a long time for sure as I looked at this over and over and was like, “yeah - I’ve implemented the event in the control. Where’s the duplication…”

And based on your explanation, I understand why you guys couldn’t catch this. And I understand why it doesn’t work too. Makes complete sense.

So it would be nice if introspection could identify all the implemented events. Then you could check what’s implemented but perhaps that wouldn’t make any difference either - as the object is built first in the constructor, then like you say the window. So you guys would have to be the one checking for every event like this which is necessary for 99.999 percent of the cases…

So it truly looks like if I want a “universal” code object, that I should never implement that object on a window, but instead create a subclass and implement the subclass…