Adding a Confirmation Screen before closing a Max Application


    Jun 03 2017 | 3:43 pm
    Hi all,
    I'm working on a Max patch that will eventually be an app.
    What I'm currently trying to determine is if it is possible to add some sort of "Confirmation Screen" that will appear when the user selects File->Close...as a way to make sure the app doesn't close if the user selected the wrong menu item.

    • Jun 03 2017 | 4:45 pm
      Hi Narner, Yes! You can do this, but the approach is a buit "hacky" as you have to edit the 'maxinterface.json' in your standalone (its in the ./resources/interfaces).
      This is what I have done: 1. In my patcher i have [receive my_quit] that when it receives somthing it opens the "are you sure" dialog etc... 2. In the maxinterfaces.json, an the "menus" section, I added an entry like so:
      {  
          "message" : "mycustomquit",  
          "label" : "Quit",  
          "navkey" : "x",  
          "target" : "my_quit",  
          "shortcut" : "Q" 
      }   
      There is a "quit" entry already, that max uses. You can just copy that and change the message and the target. The key to this whole thing, is that the "target" if set to somtheing other that the keywords that max uses, like in this case "my_quit", when this menu item is selected, it sends a bang to any [receive my_quit] in your patch.
      3. Also in the "menus", assuming you have a [menubar] in your patcher, find the "customfilemenu" entry. If you replace the "quit" with "mycustomquit", in the actual menubar the entry you see and click, will be yours and not the normal "quit".
      This should send a bang to the [receive my_quit], and from here on, you can do your thing! But know you are also responsible from closing max, which can be done with a " ;max quit " messabox.
      I have done this and works fine, but it is a good strat to also disable the "X" button on your standalone (form the [standalone], check the "Cant close top level patcher"), as there is no way (trhat i know of) to override its behaviour from max, so there will be no "are you sure" prompt, only if the user has to go through the menu.
      Hope this helps!
    • Jun 03 2017 | 6:42 pm
      if the main patcher window is in foreground, [closebang] might already do this?
    • Jun 04 2017 | 6:15 pm
      Hey Niklas, that makes sense - thanks a ton. By any chance would you mind sharing a zip of the max patch you used to make this? I've already got a lot of goofey stuff going on as far as custom menu bars / modified maxinterface.json file; would be helpful I think to see it in working action. Cheers!
    • Jun 05 2017 | 8:16 am
      I was looking for it to attach it to my first reply and for some dum reason I must have deleted it as I cant find it... I'll try to make an example within the day and post it.
      -N
    • Jun 05 2017 | 2:33 pm
      Oh awesome, thank you thank you!
    • Jun 05 2017 | 6:17 pm
      Hi Narner, I uploaded an example, both patchers and Win/Mac builds, here!
      Unfortunately the one thing that cannot be avoided ro disabled, is on Mac; the "apple" menu has a "Quit <app-name>" that cannot be either hidden or overriden. So in that case the standalone will just close. But the File->Close is totaly overriden as you'll see in the example. In both OS the "X" button of the window also cannot be overriden but it can be disabled/avoided from the [standalone] object. For Windows, the whole behaviour can pretty much be overriden, as both selecting File->Exit and using the Ctrl-Q shortcut will trigger the customclose, showing the "Are you sure" alert!
      The changes i've done in the maxinterface.json is adding the "supercustomquit" message, and just replacing with it the default "quit" in the "filemenu" and "customfilemenu".
      Anyway, let me know if there is any issue with the example!
      -N
    • Jun 05 2017 | 7:18 pm
      Hey, thanks a ton for this! I'm on a Mac and using Max7 - when I opened the patch, it looks like the Close button is just disabled for me:
      Sorry to bother!
    • Jun 05 2017 | 8:43 pm
      Well, when opened in Max, it should be disabled, as max reads and uses its own maxinterfaces.json to create the menus etc, and setting a patcher's "window flags noclose" (with [thispatcher]) will prevent it from being able to close like this. You could also edit that, but I wouldnt' recomend it...
      That is the tricky part as you can/should test the edited maxinterfaces.json only from a built standalone. So the edited file only affects the standalone.
      I included the file beside the patchers for convenience, so you wouldn't have to search for it in the standalones :)
      The standalones shoud work as described though.. ?
    • Jun 05 2017 | 8:48 pm
      AH! Ok, that makes more sense - cheers! Sadly though, when opening the standalone Max app, I got this error:
    • Jun 05 2017 | 9:30 pm
      Sorry about that, I checked it and worked ok on my mac before I send it. Anyway, I rebuilt it -> link
      If this also doesn't start, you could just open the "CustomQuit_Main.maxpat" in Max, build it as a standalone and replace the maxinterfaces.json that standalone has with the edited one. -N
    • Jun 06 2017 | 12:16 am
      custom quit app must quit now because it is not able to start.
    • Jun 08 2017 | 2:10 pm
      Awesome - thank you for your help, Nikolas! I'm going to try to write up a little tutorial about this in case others come across something similar :)
    • Mar 20 2020 | 10:44 am
      Is there any way to achieve the same with the application's close button?
    • Feb 22 2021 | 3:21 pm
      Bump. Any way to achieve the same with the application's close button?