I just released my virtual MIDI controller app Proxima Controller for macOS via the App Store. It’s something that I ported to OSX a while ago but never posted to the app store.

It lets you use your mouse, touchscreen, or keyboard keys to play a virtual MIDI controller that can be used to control external devices such as drum machines, synthesizers, or samplers.

You can get it here.

And if you want the Windows version you can get it here.

Over the years I’ve struggled mightily with OSX development. It’s just hard if you want to do things your way. It’s far easier if you use Apple’s choice of tools and languages.

Since most of what I’ve worked on for Apple computers has been apps ported from Windows or Linux, there really hasn’t been the option of starting with their way of doing things in mind at the beginning.

Last time I was working on building things for the App Store, I had eight apps I was trying to publish. I only ended up getting two released before I gave up in frustration. Those two were SpaceTheremin and MIDIPlayer.

Well, given my lack of enthusiasm, it’s no surprise that I let my developer subscription lapse. A lot of people wonder what happens when you let your subscription expire but then renew it later (around two years later in my case). Well, your apps disappear from the app store but stay installed wherever people already have them. And when you renew, they magically reappear like they never disappeared without needing to be reviewed again, and any apps in progress will be exactly as you left them.

That’s the case with SpaceTheremin and MIDIPlayer, which are now both available for macOS again.

Here’s SpaceTheremin.

Here’s MIDIPlayer.

I also have some things that have made it farther than before that you should expect to be released in the near future.

I have some apps that I’ve tried porting to OSX off an on over the years, but some of them have never been quite right.

They’re written with wxWidgets, which is a multiplatform application development toolkit. However, documentation and fine details for macOS specifics is generally lacking.

For instance, I had an ongoing problem with making the “Quit” function in a menu work in a single-dialog application based on the wxDialog class. I originally asked the question on the forums back in 2011:

I have a wxDialog-based application on OSX that shows a single modal dialog window.

My understanding is that a dialog-based app cannot have a menu bar. However, I do get the default system menu bar on the app.

The Cmd-Q option (Quit) shows up on the default system menu bar, but it is grayed out. How can I modify my app to bind to that Cmd-Q option so I can treat it the same as clicking the red button at the top right of my dialog (which exits the app)?

The original post is here.

The answer from Tierra about switching to a wxFrame instead of a wxDialog was a part of the puzzle (thank you!), but the quit item still didn’t work. Once I had a wxFrame I could then attach the default menu items (in the constructor where all the dialog controls are being created):

wxMenu* helpMenu = new wxMenu();
helpMenu->Append(wxID_HELP);
helpMenu->Append(wxID_ABOUT);
wxMenuBar* menuBar = new wxMenuBar();
menuBar->Append( helpMenu, "&Help" );
SetMenuBar(menuBar);

I also had to connect those buttons to my functions in the event table (my dialog class is called wxKeyboard):

EVT_MENU( wxID_EXIT, wxKeyboard::OnExit )
EVT_MENU( wxID_ABOUT, wxKeyboard::OnInfo )
EVT_MENU( wxID_HELP, wxKeyboard::OnHelp )

Once that was done, I had an about menu item, a help menu item, and the quit item magically appeared and worked as intended. In addition, the “About” menu entry appeared under the application menu and not the help menu, but I had to add it to a menu in order for it to show up.