Mac OSX applications fail when setting up GLControl
Posted Friday, 6 November, 2009 - 17:09 by VeliV| Project: | The Open Toolkit library |
| Version: | 1.0-beta-1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
The line 4th line on the following code causes a crash on Mac OSX
using System; using System.Windows.Forms; public class HelloWorld : Form { OpenTK.GLControl glControl = new OpenTK.GLControl(); static public void Main() { Application.Run(new HelloWorld()); } public HelloWorld() { Text = "Hello World"; } }
Here is the output:
System.InvalidCastException: Cannot cast from source type to destination type. at OpenTK.Platform.MacOS.AglContext..ctor (OpenTK.Graphics.GraphicsMode mode, IWindowInfo window, IGraphicsContext shareContext) [0x00000] at OpenTK.Platform.MacOS.MacOSFactory.CreateGLContext (OpenTK.Graphics.GraphicsMode mode, IWindowInfo window, IGraphicsContext shareContext, Boolean directRendering, Int32 major, Int32 minor, GraphicsContextFlags flags) [0x00000] at OpenTK.Graphics.GraphicsContext..ctor (OpenTK.Graphics.GraphicsMode mode, IWindowInfo window, Int32 major, Int32 minor, GraphicsContextFlags flags) [0x00000] at OpenTK.CarbonGLControl.CreateContext (Int32 major, Int32 minor, GraphicsContextFlags flags) [0x00000] at OpenTK.GLControl.OnHandleCreated (System.EventArgs e) [0x00000] at System.Windows.Forms.Control.WmCreate (System.Windows.Forms.Message& m) [0x00000] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5759 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x001e4] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5397 at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ScrollableControl.cs:807 at System.Windows.Forms.ContainerControl.WndProc (System.Windows.Forms.Message& m) [0x0003d] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:642 at System.Windows.Forms.UserControl.WndProc (System.Windows.Forms.Message& m) [0x00037] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/UserControl.cs:150 at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:234 at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:215 at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00085] in /private/tmp/monobuild/build/BUILD/mono-2.4.2.3/mcs/class/Managed.Windows.Forms/System.Windows.Forms/NativeWindow.cs:242
Using Mac OSX Snow Leopard, latest mono and revision 2465 from the SVN.
Comments
#1
Thanks.
Please double check that the OpenTK version number reads 0.9.9-4, not 0.9.9-3 (I get bitten by this very often, sometimes the IDE doesn't actually replace the reference).
It would also help to run the test case with a debug version of OpenTK.dll (I've posted some instructions here).
#2
Yah, the ref wasnt updated but now it is. Here is the new output:
#3
Thanks, this is interesting. It seems that the platform detection code has gone awry and it's trying to use X11 instead of Carbon/Quartz. Do you have an X server installed, by any chance?
Edit: I have modified the platform factory to prefer the native implementation over the X based driver when both are detected. Can you please update to rev. 2466 and try again?
#4
Hmm. dunno what you mean :) I don't think I have X Server installed, if it didn't come with the OS. Do you have a link to X Server site so I can check and perhaps install it?
#5
Apple has some documentation here. Mac OS X comes with an X server by default, by you have to install it manually.
Two possibilities
Since 0.9.9-3 QuickStart worked, this is a bug that was introduced between 0.9.9-3 and 0.9.9-4 (I did touch the platform detection code, which means I probably broke it). Still, it would be helpful if you could check whether SVN rev. 2466 starts up correctly.
#6
Nah, dont have X server installed.
SVN up, compile, and re run. Here is the output
SOmething seems to have changed ;)
#7
Another careless bug introduced today - the primary DisplayDevice was not set under some circumstances. Can you please test rev. 2467?
(Fixing bugs, one issue at a time!)
#8
Success, at least partly.
This script now runs:
But, this doesn't :P
Seems to crash at Controls.Add(glControl); . Here is the output:
Fun fun. BTW, I need to go now, but I am usually on the IRC as well if you'd find that faster palce to test stuff.
#9
Thanks, this was the same issue as above, just in a different place (OpenTK.GLControl.dll). Fixed in rev. 2468.
It seems that the MacOS port has bitrotted more than I thought. We may have to do some debugging sessions like this to get it back to speed. :)
#10
I was looking into this.. Mac OS Leopard and beyond have X11 installed by default, and the static constructor starts off by trying to detect X11, which succeeds on Mac OS, and then it detects the Kernel and ends up with both runningOnX11 and runningOnMacOS true. Then later when the factory is instantiated, we have if (windows) else if (X11) {} else if (MacOS) which will instantiate the X11 factory and try to go from there. I was messing around with detecting the kernel first then checking for X11 if runningOnMacOS is false, but there seems to be more to the issue than that.
PS. I just bought Snow Leopard last night.. I can't believe it was only $29. Now I am getting my mac up to date.