Is this a bug? Window Opening not firing Open Event

Yes it is. It took me a while to figure out what change I had made and when it stopped working. The result was the least expected

No kidding. I would not have expected that one. Report that sucker quickly! Maybe it can get into R2.1.

It’s a joke, right ?

It’s only a joke if it’s not reported.

You are right. But I doubt it will be fixed for 2.1 :wink:

https://xojo.com/issue/34665
34665 - Window open event blocked by FontCount

Thank you Eli for synthesizing it to one line.

There was a similar issue during early Cocoa builds - if you checked your Console.Log you could see the error message(s) being thrown by the Cocoa framework. Is anything showing up there?

Thank you Michael. There are indeed messages happening in the Console :

7/30/14 11:45:57.403 AM openeventblocked.debug[1531]: ComboBox Open event fired // My own system.debuglog 7/30/14 11:45:57.417 AM openeventblocked.debug[1531]: *** -[__NSArrayI objectAtIndex:]: index 507 beyond bounds [0 .. 506] 7/30/14 11:45:57.419 AM openeventblocked.debug[1531]: ( 0 CoreFoundation 0x99e79471 __raiseError + 193 1 libobjc.A.dylib 0x98e09091 objc_exception_throw + 162 2 CoreFoundation 0x99d4ffbc -[__NSArrayI objectAtIndex:] + 204 3 XojoFramework 0x001b1eaa ExecuteAppleScript + 35274 4 openeventblocked.debug 0x00113eb5 REALbasic.Font%s%i4 + 59 5 openeventblocked.debug 0x0014d2d1 Window1.Window1.ComboBox1_Open%%o<Window1.Window1>o<ComboBox> + 227 6 openeventblocked.debug 0x0014e847 Delegate.IM_Invoke%%o<ComboBox> + 110 7 openeventblocked.debug 0x0014e888 AddHandler.Stub.2%% + 51 8 XojoFramework 0x002cdf3a FireWindowOpenEvents + 186 9 openeventblocked.debug 0x000115dd Window.Constructor%%o<Window> + 64 10 openeventblocked.debug 0x0014e6c3 Window1.Window1%o<Window1.Window1>% + 210 11 openeventblocked.debug 0x000027c3 _MakeDefaultView + 52 12 openeventblocked.debug 0x00002916 _LateStartup + 36 13 openeventblocked.debug 0x00149958 Delegate.Invoke%%p + 48 14 openeventblocked.debug 0x001144c9 REALbasic._CallFunctionWithExceptionHandling%o<Object>%pp + 211 15 XojoFramework 0x001ce0b6 ExecuteAppleScript + 150486 16 XojoFramework 0x001ccbb3 ExecuteAppleScript + 145107 17 Foundation 0x9ab91732 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke + 49 18 CoreFoundation 0x99e425a4 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20 19 CoreFoundation 0x99d2404b _CFXNotificationPost + 3435 20 Foundation 0x9ab8021f -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 21 AppKit 0x990b5575 -[NSApplication _postDidFinishNotification] + 367 22 AppKit 0x990b5215 -[NSApplication _sendFinishLaunchingNotification] + 239 23 AppKit 0x990ad26f _DPSNextEvent + 1384 24 AppKit 0x990ac870 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 25 XojoFramework 0x001ce831 ExecuteAppleScript + 152401 26 XojoFramework 0x001ce898 ExecuteAppleScript + 152504 27 openeventblocked.debug 0x00002b82 Delegate.Invoke%% + 34 28 openeventblocked.debug 0x00075eac Application._CallFunctionWithExceptionHandling%%o<Application>p + 248 29 XojoFramework 0x002c1911 enableMenuItems + 1873 30 XojoFramework 0x001ce7c0 ExecuteAppleScript + 152288 31 AppKit 0x9909f15c -[NSApplication run] + 727 32 XojoFramework 0x002c1997 enableMenuItems + 2007 33 XojoFramework 0x002c0021 RuntimeRun + 49 34 openeventblocked.debug 0x00114a4a REALbasic._RuntimeRun + 34 35 openeventblocked.debug 0x00002a6e _Main + 257 36 openeventblocked.debug 0x0000250c % main + 36 37 openeventblocked.debug 0x00150f0d _start + 116 38 openeventblocked.debug 0x00150e63 start + 43 )

Yup, that looks similar to (but different from) the one I saw before. Nasty bug, isn’t it? Since your code just stops running in that thread without any indication. Very difficult to debug. Hopefully your log will help Xojo folks fix it. Good sleuthing!

2014r2 doesn’t raise an exception
Nor does 2014r1.1, 2014r1 , 2013r4.1, 2013r3.3, 2013r2, 2013r1 or 2012r2.1
This one has been around for some time :slight_smile:
But it looks like Joe found it already

[quote=116052:@Michel Bujardet]You are right. But I doubt it will be fixed for 2.1 :wink:

https://xojo.com/issue/34665
34665 - Window open event blocked by FontCount

Thank you Eli for synthesizing it to one line.[/quote]
Thanks for reporting it Michel. I’ve not been at my desk all day so not had chance.

It does raise an OutOfBoundsException on OS X.

I just tried in in 2.1 b7 and b8 and it did not here with the sample we created
Just ran right through
The sample is really simple

  • New desktop app
  • Add a combobox to the layout
  • In the comboxbox open event put

// This should raise an exception, but it never fires dim f as string = font(fontcount + 1) break

  • In the Window open event put

// I don't get here msgbox "fired"

  • Run

As stated Joe’s already fixed this for a later release

[quote=116115:@Norman Palardy]I just tried in in 2.1 b7 and b8 and it did not here with the sample we created
Just ran right through
The sample is really simple

  • New desktop app
  • Add a combobox to the layout
  • In the comboxbox open event put

// This should raise an exception, but it never fires dim f as string = font(fontcount + 1) break

  • In the Window open event put

// I don't get here msgbox "fired"

  • Run

As stated Joe’s already fixed this for a later release[/quote]

The sample I attached to the bug report is the same, but in 2014R2.1B7 I do get the same error in the console.

Never mind ; if Joe has fixed it already that is good news :slight_smile:

[quote=116119:@Michel Bujardet]The sample I attached to the bug report is the same, but in 2014R2.1B7 I do get the same error in the console.

Never mind ; if Joe has fixed it already that is good news :)[/quote]

Yes I see the error listed in the console but the app does NOT get an Out Of Bounds & thats the bug
THat exception has the effect of stopping the open events from running

And Joes fixed it :slight_smile:

A nice clean simple example thats this reproducible helped a lot

Joe has fixed it. Amen

I had a problem like this when I added a Constructor method to a window. The Open did not fire. I removed the Constructor method, and it fired.

If your constructor doesnt call Super.Constructor then you can have this issue

Yes, and if you make this mistake, it’s really hard to figure out. Though the documentation is very clear on the need to do it, but if you fail, the errors are not intuitive. I wonder if the compiler could even refuse to compile such code?

This probably hits the Turing halting problem though: there’s ultimately no way for a compiler to know if a given method will, or will not be called.

But its NOT always an error so refusing to compile it when you might legitimately NOT need to call it would be bad

Most time adding a constructor adds the call to Super.Constructor