Access to Carbon and Win32 window handle from Max


    Aug 03 2011 | 6:51 am
    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

    • Aug 03 2011 | 11:08 am
      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
    • Aug 04 2011 | 4:54 am
      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
    • Aug 04 2011 | 3:31 pm
      Yes, with Max 6 we make the move from Carbon to Cocoa for the underlying OS support.
      Cheers, Tim
    • Aug 12 2011 | 2:27 pm
      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
    • Aug 12 2011 | 4:14 pm
      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
    • Aug 13 2011 | 8:09 am
      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
    • Mar 03 2012 | 3:35 pm
      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
    • Mar 05 2012 | 12:00 pm
      Great to hear! Thanks for the update!
      Tim
    • Sep 21 2020 | 11:51 am
      Hi, is this still the way to go in 2020 to get a native window handle / ref of the patcher that holds the external?
    • Sep 21 2020 | 1:47 pm
      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..
    • Sep 21 2020 | 9:18 pm
      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?