Erlang wxWidgets app - Closing the beam.smp file once app finished - macos

got a weird question which I haven't been able to find an answer to online so I'm trying my luck here.
I have a normal erlang application using wxWidgets, once I try to shut down my application I get the event that the wxServer has indeed entered the event which is connected to the window closing, I get a message that it is in the process of exiting, and my window does indeed close, but as shown in the picture below, the beam.smp on my toolbar doesn't close at all, I have to manually force the closing of the beam.smp file which sends a SIGTERM to the erlang terminal which also shuts down my erlang VM (which I have to reboot it later).
long story short, what am I missing on my close window event so that everything shuts down nicely without it crashing my erlang VM? I was able to read that wxWidgets behaves differently on macOS but I haven't been able to find how to correctly close the application.
handle_event(#wx{event = #wxClose{}},State = #state{frame = Frame,panel = Panel}) ->
io:format("Exiting~n"),
wxFrame:close(Frame),
wxFrame:destroy(Frame),
wx:destroy(),
{stop,normal,State};

You can close the emulator from code with init:stop/0,1
Also, if your application is started as permanent, it should suffice with terminating that application. Check the behaviour in erlang:application

Related

applicationShouldTerminate: not called when system restarts

I have to run some code when the app is about to terminate. applicationShouldTerminate: runs when quit is selected from the menu or when I press Cmd Q but not when I restart the mac.
Is there a way to force applicationShouldTerminate when a user tries to restart the mac? Or is it another function being called in this scenario?
Your app might have Sudden Termination enabled.
macOS 10.6 and later includes a mechanism that allows the system to log out or shut down more quickly by, whenever possible, killing applications instead of requesting that they quit themselves.
...
Debugging tip
You can determine the value of the sudden termination using the following LLDB command.
print (long)[[NSClassFromString(#"NSProcessInfo") processInfo] _suddenTerminationDisablingCount]

OSX running app acts differently from running on terminal

I have written an app for OSX (Sierra) in Go (lang) with the GUI powered by the Golang QT binding therecipe/qt. When I build the app and run it from the command prompt with command open $(pwd)/myapp.app I get a terminal output while its running, and everything works fine.
When I double click on the app in finder to run it, I obviously don't have access to the console to see debugging, but in parts of the app that work fine in the GUI when I run from console (clicking on things, etc), it crashes the app when run by clicking on it.
I realise people don't know what the app is, and without seeing where in the app it crashes, they can't help me. What I am after is some ideas about debugging it, for instance:
Outputting logs to a text file and tailing the text file to watch as it is written to
Connecting a debugger to the application by the process, perhaps I can discover where it crashes. This doesn't sound straight forward
Is there a way to attach to a console of an application run like this to see what it is outputting?
Any ideas appreciated.
Thanks

Trigger "application quit unexpectedly" popup when OS X deamon crashes

I'm working on a new OS-X Daemon process (run from launchd) and would like to get popup window every time it crashes with all relevant information (pid, path to crash file, etc...). This will sure help my debugging effort in this early stage of the development.
Basically, i want to have the same behavior as a UI application. For example :
I've made some research and found out about the CrashReporter, but i don't know how to register my app to this service. But it seem like there's no way to trigger popup windows from this service, since crashes are system level events and apps have zero interaction with those.
Maybe there's a way to do so by setting up some parameters in app bundle or via Info.plist ?
EDIT: looking at the crash report manual, it looks like the unexpected dialog works only on GUI user mode, and not on daemon that runs from launchd. perhaps i'm missing something ?
In addition, if the program that crashed is running as a logged in GUI user, CrashReporter will present the user with a dialog asking them whether they want to submit a bug report to Apple (see Figure 1). If the user clicks the Report button, CrashReporter displays another dialog that shows the details of the report (see Figure 2) and allows them to comment it before submission.
I've read that Developer option enable in addition to application crashes, crashes are also displayed for background and system processes. but unfortunately i doesn't work for me.
thanks
Seems like the problem occurs since my background process runs under root privilege, and root privilage process (not just daemons) cannot initiate any UI widget on the screen.
I guess that the only way to deal with it, is by catching the signal that trigger the crash, and send details for a proxy process that run on non-root mode and can initiate the UI dialog box with crash details.
I would be happy to hear for better proposals.
Since CrashReporterPrefs, which allowed you to enable this behavior for daemons, no longer comes with developer tools, you can change the behavior to show the dialog for daemons by running this command in the Terminal:
defaults write com.apple.CrashReporter DialogType Developer

Forgotten where I left an automatic shutdown script on Mac OSX

I let me Parallels Desktop running Windows XP to start automatically during mac log-in. And to start Windows upon launch to let my dad use his WinXP by just pressing the power button, bypassing the Mac login window and desktop completely. When he shuts down Windows, Parallels closes.
I seem to remember I have a trigger to shut down mac as soon as Parallels closes. But I don't remember where... I have an AppleScript that tells Finder to shut down. I understand that. But now the problem is Mac shuts down AS SOON AS it boots up every time! I can't figure out what's triggering the shutdown... And I've run out of places to look.
It seems like a normal shut down rather than a fatal error. Seems like someone has chosen the 'Shut Down' command as soon as Mac starts up. So could mac gurus suggest places I should look -- what might have triggered this -- I'm pretty sure it's Parallels-related. Maybe there is something in the Package Contents linked to the shutdown script??
You added the Applescript (that shut down the mac) to login items

How to shutdown local tomcat server when closing browser window?

I hava a web app running on a local tomcat server.
When the user starts the app (via desktop shortcut) the server starts and the app is opened in a browser window.
But when the user just clicks on the close button to stop the application the server is still running in the background - that's annoying.
I tried to utilize the "unonload" and "onbeforeunload" events from javascript but unfortunately these events are also fired on some other requests in the app.
So I can't use them, except I do a lot of refactoring.
Does anyone have an idea for a possible solution?
Btw, what I find interesting is the behaviour of Visual Studio when debugging a web application. When I close the browser window Visual Studio also gets a trigger to stop debug mode. So it seems it somehow notices the close event of the browser window, which would be exactly what I need. But I don't know how they do it...
Can you wrap the starting of Tomcat and launching your app in a batch file or shell script? (Not sure what your target OS is...)
The script/batch file would start Tomcat and then launch your application. When the user exits your application, the script/batch file would then shut down Tomcat.
You can setup a short session timeout, and use a HttpSessionListener. On sessionDestroyed(..) you can stop tomcat (using catalina.bat for example) .
Otherwise you can try to detect browser close, and send a shutdown message to the server using ajax (before the browser is closed).

Resources