trying to create windows

Mar 10, 2009 at 9:52am

trying to create windows

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?

#42760
Mar 11, 2009 at 12:06am

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

#153075
Mar 11, 2009 at 8:57am

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?

#153076
Mar 11, 2009 at 1:14pm

I attach the simlewindow.c file.

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

#153077
Mar 11, 2009 at 7:47pm

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

#153078
Mar 11, 2009 at 8:27pm

Hi Davis,

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

I may come up with further questions some time later.

Rainer

#153079
Mar 17, 2009 at 9:25am

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

#153080
Mar 17, 2009 at 9:10pm

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

#153081
Mar 17, 2009 at 10:35pm

Hi Davis,

thanks very much for your kind help!!!

Rainer

#153082
Mar 18, 2009 at 12:30pm

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

#153083
Mar 18, 2009 at 10:39pm

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.

#153084

You must be logged in to reply to this topic.