BenKissBox

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++ ?

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.

access-to-carbon-and-win32-window-handle-from-max

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*.

 or similar to detect this and handle appropriately in your code.

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

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.

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 ?

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


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

Switching to Cocoa seems a logical step (and VSTGUI also switched to Cocoa, so I expect this to be transparent for me)

- 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)?

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 : 

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.

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.

I hope you will be at Expo'74, I would be happy to meet you and discuss with you

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

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...

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...

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

in ext_proto_win.h which works instantly. Now looking for a Mac complement..

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..

Many outdated threads here about this topic .

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?

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

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?


Access to Carbon and Win32 window handle from Max