Forums > Dev

trying to create windows

March 10, 2009 | 9:52 am

Hi,

I am currently trying to create and open a window in a Max external. The externals I had written for Max 4.6 used lots of windows, and I want to re-write them for Max 5. There are other colleagues who had already complained about the fact the t_wind is no longer available im Max 5.

Now I am trying to use functions of the Carbon Window Manager to create and open a window.

First, I added Carbon.frameworks to the project (I am actually using the "minimum" project of the examples) and added

#include
#include "MacWindows.h"

at the top of the minimum.c file (just below #include "ext.h").

In the minimum structure I declared a Window Reference:

WindowRef *myWindow;

and I added a function to create the window:

void CreateWindows (t_minimum *x)
{
OSStatus err;
Rect bounds;

bounds.top = 50;
bounds.left = 50;
bounds.right = 550;
bounds.bottom = 550;

err = CreateNewWindow (1, 0, &bounds, x->myWindow);

if (err)
{
post ("can’t create window");
}
else
{
post ("new window created");
}
}

I called this function from the *minimum_new function.

In this function, the Window Manager Function "CreateNewWindow" should create the new window (the 1st parameter is the window class, the 2nd the window attributes, the 3rd the content bounds and the 4th the actual WindowRef). I pass the WindowRef x->myWindow from the minimum structure.

I used err to indicate whether the window could be created or not.

When I compile the project and open the external in Max5, the creation of the window fails ("can’t create window").

The strange thing is that I can create a window (and even open it) when I declare a local Window Ref inside this function:

void CreateWindows (t_minimum *x)
{
OSStatus err;
Rect bounds;
WindowRef *myWindow;

bounds.top = 50;
bounds.left = 50;
bounds.right = 550;
bounds.bottom = 550;

err = CreateNewWindow (1, 0, &bounds, myWindow);

if (err)
{
post ("can’t create window");
}
else
{
post ("new window created");
}

ShowWindow (*myWindow);

}

In this case, the external will create and open the window. Of course it doesn’t make sense like this, since this WindowRef is local and there is no way to access this window any more after it has been created and opened.

Why can’t this function create the window when I pass it the WindowRef from the minimum structure (x->myWindow), and why will it create a window when I declare the WindowRef inside this function?

I also tried to declare a global WindowRef at the top of the minimum.c file (which is no member of the minimum structure), but CreateNewWindow won’t create the window.

Has anybody got an idea why this is the case?


March 11, 2009 | 12:06 am

Have you tried using kDocumentWindowClass for the first argument
to CreateNewWindow()? That works for me. Also, I’ve never had
any problems storing WindowRef pointers anywhere.

Davis


March 11, 2009 | 8:57 am

thanks Davis, I have just tried it – unfortunately with the same (negative) result. It really shouldn’t matter where I store the Window Ref! Hm…… any idea?


March 11, 2009 | 1:14 pm

I attach the simlewindow.c file.

Maybe someone can try it and tell me why it doesen’t work


March 11, 2009 | 7:47 pm

I tried simplewindow.c with Max5 SDK, Mac OS 10.4.11, and
Xcode 2.5.

I commented out: #include "MacWindows.h"
That file gets included automatically when I add Carbon.framework
to the project.

I noticed that your t_simplewindow struct did not contain a WindowRef, but a pointer to one. You need an actual
WindowRef and you pass the address of it to CreateNewWindow().

ShowWindow() is called upon successful window creation. Oh, and I added some window attributes. For info on installing event handlers, try:

http://developer.apple.com/documentation/Carbon/Conceptual/Carbon_Event_Manager/Tasks/CarbonEventsTasks.html#//apple_ref/doc/uid/TP30000989-CH203-TPXREF105

Anyways, I attached an altered version of simplwindow.c.
I hope that gets you up an running.

Davis


March 11, 2009 | 8:27 pm

Hi Davis,

thanks a lot!!! It works now. That’s great!

I may come up with further questions some time later.

Rainer


March 17, 2009 | 9:25 am

Hi Davis,

thanks again for your help. I have started to study the Carbon Event Manager to include events to my external (I still work with the simplewindow object to study basic things).

I have defined Event Handlers for mouse and keyboard events and registered them with the window. Unfornutately these handlers seem to overwrite the standard event handler which had been installed with the window attributes in the function CreateNewWindow (…). So now I can’t drag the window with the mouse anymore.

I thought that specifyng event handlers will only overwrite the events for which the handler is isntalled (in this case: the mouse down, mouse up and mouse dragged events) and leave the other events to be processed by the standard event handler.

How could I fix this?

I enclose the simplewindow.c file again.

Thanks,

Rainer


March 17, 2009 | 9:10 pm

Your event handlers should return eventNotHandledErr if you want the default handlers to operate on the event. If you return anything other than eventNotHandledErr (like noErr), then event handling will stop for that event.

I just changed all the lines in your code that look like this:

return err;

to:

return eventNotHandledErr;

That way, whenever you return from a handler, the default window handlers get to operate on the event. I see some colorful squares and triangles and I am able to move/minimize/close the window. You should definitely prevent any window operations after the window is closed/destroyed. Or just don’t allow the user to destroy the window; instead let them hide/un-hide the window. Good luck Wink

Davis


March 17, 2009 | 10:35 pm

Hi Davis,

thanks very much for your kind help!!!

Rainer


March 18, 2009 | 12:30 pm

It would be useful to know how to do this via Juce/Cycling’s API, for cross platform stuff and since carbon is being deprecated soon. I hope it can be included in the API docs.

oli


March 18, 2009 | 10:39 pm

I thought that huge chunks of Carbon were being deprecated; not Carbon as a whole. Though, I wouldn’t mind if Apple killed Carbon as long as they provided us with a replacement that didn’t require Objective-C. As for cross-platform development, I’m thinking about trying wxWidgets or Juce. But, if what you’re trying to do isn’t directly related to the SDK, then the Cycling devs will most likely ignore your requests for help.


Viewing 11 posts - 1 through 11 (of 11 total)