OpenGLComponent troubles


#1

First I just want to say thanks for all your work on this library. I tried wx, qt, fltk and had trouble getting them to even compile on my computer (I’m running OSX 10.6), where as I downloaded JUCE and boom! worked first time. :slight_smile:

Basically, all I’m trying to do is start up a window containing an OpenGLComponent that I can draw to and grab mouse and keyboard events from, nothing complex at all.

The first problem, is that if I call setUsingNativeTitleBar(true), then i get an ‘invalid drawable’ message that appears to be being generated from inside NSWindow makeKeyAndOrderFront:. If I omit the native title bar call, everything continues happily and I can make open GL calls with no problems.

The second problem seems related, but when I run the application, it doesn’t appear as the front or active window, rather it appears behind whatever I ran the program from (terminal, finder, xcode, whatever). In addition, it never seems to gain keyboard focus, it receives mouse events without issue, but keyPressed() never gets triggered.

Strangely, when I run the Hello World demo app by linking against the libraries built with the supplied xcode project, rather than using the amalgamated files, I get the same focus and keyboard issues. Is it possible that the amalgamated version differs from the non-amalgamated version?

This is the relevant code, hopefully there is something obvious I have missed (I am running JUCE v1.51.16):


	void juce_application::initialise(const String& commandLine)
	{		
		//create the main window and open gl context
		String title = getApplicationName() + " - " + getApplicationVersion();
		m_main_window = new main_window(title, 640, 480);
		m_main_window->setVisible(true);
	}

	main_window::main_window(const String& name, int width, int height) :
		DocumentWindow(name, Colours::whitesmoke, allButtons, true)
	{	
		//setUsingNativeTitleBar(true);
		setWantsKeyboardFocus(true);
		centreWithSize(width, height);
		
		setContentComponent(new main_component(width, height), true, true);
	}

	main_component::main_component(int width, int height)
	{	
		setSize(width, height);
	}

Any help would be much appreciated.


#2

You code looks ok to me…

I tried running the openGL page in the juce demo, with the native title bar enabled, and that works ok… I did see the ‘invalid drawable’ warning, but that just looks like internal Apple noises to me, as it didn’t seem to affect the result. Maybe you could send me something I can quickly build and run that replicates the problem?

The code is the same, but of course if you build with different project settings, e.g. the version of the OSX SDK, etc, then obviously that could make a difference.


#3

I’ve attached a sample app that replicates the above behaviour with all the rest of my code stripped out of it. I didn’t include the libjucedebug.a file since its 81mb and I figure you will be able to generate it given the version number in my first post. Also, you’ll obviously need to change the library header path to match your set-up.

Thanks again.


#4

Thanks - interesting stuff.

Seems that due to internal Apple wierdness, the GL view sometimes can’t get fully initialised until it’s actually being rendered. There’s a simple fix, which I’ll check in soon, but basically it’s just adding a tweak to this method in juce_mac_OpenGLComponent.mm:

[code] bool makeActive() const throw()
{
jassert (renderContext != 0);

    if ([renderContext view] != view)
        [renderContext setView: view];

[/code]


#5

I’ve grabbed the latest version of Juce via git (v1.52.51), which has the change you listed above, but the test app is still showing the same problems. No keyboard events, no mouse move events (although it gets one when I click) and no focus when created.

It no longer gives an invalid drawable message, but if I set the window to use the native title bar, the repaint() in the timerCallback I added to the openGL component, never actually triggers a renderOpenGL() call. Stepping through it seems to be sending the repaint back up the hierarchy through to the DocumentWindow though. I’m going to keep digging around, see what I can find. I’ve attached a slightly updated version of the source and project I am using.

Thanks again for all your help.


#6

There’s no sense in using setWantsKeyboardFocus on your DocumentWindow - that’s just the frame around the edge. Try calling it on your actual content component instead.