Access to Carbon and Win32 window handle from Max

BenKissBox

Hello all,
I am currently trying to create an external with a GUI. I want to use VSTGUI to manage the GUI (since this module already exists in VST, and I do not want to code the GUI fully once again)
I think that Max/MSP is able to deal with VSTGUI (since my plugin loads perfectly with vst~) but I can not find how to create the window needed by VSTGUI.
On Win32, VSTGUI requires a WINDOW handle. On Mac, it requires a Carbon window pointer. Basically, Max has to create the window, then it defers everything else to VSTGUI.

Does anybody know how to create a window (most precisely, get the window handle) from a Max external coded in C/C++ ?

Thanks by advance for your help

Benoit
Kiss-Box

Timothy Place

This is not supported, and it *will* change. You can send a message to a window object like this:

void *native_window_for_my_system = object_method(w, gensym("getsyswind");

In Max 5, on a Mac, this will return the carbon WindowRef. In Max 6, however, it will return an NSView*.

You'll need to use maxversion() or similar to detect this and handle appropriately in your code.

best,
Tim

BenKissBox

Hello Tim,
thanks for the reply, it will allow me to start my work.
From what I see, you switch to Cocoa window handling in Max 6. Am I right ?
Benoit

Timothy Place

Yes, with Max 6 we make the move from Carbon to Cocoa for the underlying OS support.

Cheers,
Tim

BenKissBox

Thanks for these informations, Tim
Switching to Cocoa seems a logical step (and VSTGUI also switched to Cocoa, so I expect this to be transparent for me)
However, I still have two questions :

- does this message applies to already created windows by Max (meaning that I have to create the window using the Max API, then get the handle or windowref)? My first idea was to create the window myself, thus I needed the handle of Max main window (thus my window appears as a "child")

- does this message work also on Windows system (getting then the window handle)?

Cheers

Benoit

Timothy Place

Yes, it sounds like your understanding is correct. You should create a new jwind object and then you can query it to get the platform-native representation.

And also you are correct about the method returning an HWND on Windows.

Cheers,
Tim

BenKissBox

Thanks a lot for these informations, Tim
I hope you will be at Expo'74, I would be happy to meet you and discuss with you

Benoit

BenKissBox

Hello Tim,
I just noticed that I forgot to keep you informed. Finally, I was able to create a GUI object from Max to host a VSTGUI based user interface, without needing Max to create the window. I made it work under Mac OS and Windows. Tested also under Max6...

Benoit

Timothy Place

Great to hear! Thanks for the update!

Tim

11OLSEN

Hi, is this still the way to go in 2020 to get a native window handle / ref of the patcher that holds the external?

11OLSEN

For Windows i found
HWND main_get_client(void);
HWND main_get_frame(void);
in ext_proto_win.h which works instantly. Now looking for a Mac complement..

11OLSEN

Many outdated threads here about this topic .
I managed to get this working on Mac:

NSView *cocoa_view = NULL;

t_object    *w_patcher;
t_object    *w_patcherview;
object_obex_lookup(x, _sym_pound_P, &w_patcher);
w_patcherview = object_attr_getobj(w_patcher, _sym_firstview);
object_method(w_patcherview, gensym("nativewindow"), (void**)&cocoa_view);

NSWindow *window = [cocoa_view window];// what i need 
WindowRef ref = [window windowRef]; // optionally

I guess the middle part can be used on Windows as well.
Are there any downsides using the functions in ext_proto_win.h and what were they made for?

And another question: do you think it's possible in the m4l context to traverse up to the Live application's window?