I have an Electron app, running on Windows, it has a few controls on the main window and a cancel button. I notice when it is running I see two threads, I assume the main and renderer threads. When the cancel button is clicked the renderer sends an IPC message to the main thread and the main thread calls app.quit. Under these conditions the two threads end. If I right click on the icon in the Windows taskbar for the app and select "Close" the threads only end when the app is run under the VSCode debugger, when the app is run without the debugger and the same is done the two threads remain.
How can I debug this? Any suggestions as to why it is happening.
Under the debugger I see the close being caught in the main thread and app.quit is called.
UPDATE: Since the app used Electron 1.7.9 I have updated it to use 2.0.8 just in case this was an issue that had been addressed. However, with 2.0.8 the issue remains.
Sid
Thanks to some input from the Electron Slack community I have resolved this issue. My mistake was in the way I was calling the app.quit() method.
My code was handling the MainWindow on "close" event and executing the app.quit() method in that event handler.
The correct way to close the app is to handle the app "window-all-closed" event and execute the app.quit() method there.
Here is a gist of a skeleton main.js for an Electron app that was sent to me to help me resolve the issue.
https://gist.github.com/sidprice/612cb49cec923eeb94cfcddf1736c181
Sid
Related
I'm seeing a strange behavior with my simple NativeScript / Typescript app. In the app.ts i launch the application like so:
app.start({ moduleName: "pages/home/home-page" });
but debug break points in home-page.ts in the loaded and navigatingTo event handlers don't stop execution. however when in the app i click on the Home page link the events are fired and the break points are stopped. So it looks like the app.start call does not fire page lifecycle events at all.
Seems like a strange behavior. Any ides?
It appears that the application is being executed too fast and the debugger doesn't have time to attach. To fix this problem in the launch.json (debugger configuration in VSC) set
"stopOnEntry": true
This will stop the application on the first line and allow time for the debugger to attach.
I'm working on an NPAPI based plugin, and have been observing an issue when opening the context menu in Chrome, displaying an error message saying that the page is unresponsive after leaving it open for 30 seconds.
I've observed the same issue with Flash Player 10.3 (which uses NPAPI, 11.x versions uses PPAPI).
Also, this issue only happens with Chrome, and trying to open the context menu when we aren't in the mouse down event takes no action, and no menu gets visible.
Any thoughts?
Thanks,
Rodrigo.
This is simply a bug in Chrome's NPAPI plugin host on OS X.
The reason why this happens is that you must not ever block the main thread, and when you have the menu open you're blocking the main thread. Since the main thread is blocked, the plugin doesnt' communicate back to the browser process and the browser process detects it as being frozen.
The only solution I can imagine would be something that lets you do what you need on an alternate thread. Chrome will always display that notice if you block the main thread, no matter what you do.
I am trying to prevent the user from closing the window when they click on the close button. I would like to have the application dock to the system tray.
My first step is to recognize when the user attempts to close the window and prevent the default behavior on that event. I would expect this code to work, but it does not.
var appWindow = Titanium.UI.getCurrentWindow();
appWindow.addEventListener('app.exit', function(event){
event.preventDefault();
})
I tried using the exit event and the event constants themselves to no avail.
This wont work because all your doing when you call preventDefault is stopping the default behavior in the WebKit browser page, not the native application wrapper itself.
The close command is a native function call to the underlying wrapper, it just passes an event to the listener, it does not pass control.
Also, this sounds somewhat dangerous, not allowing a user to close an application seems problematic. Maybe instead you should register a background service to run instead?
one trick might be to open an 'invisible' window for the app, so even if the user closes the 'application' window, the app should still be running.
I am doing a REALBasic project. I want to make code run after the window has loaded automatically.
If I put the code in the Open event handler, the code runs when the window opens, but the window doesn't appear until the code has finished executing.
So I would like to have the Window open and be on the screen, and then the code run automatically without having to click anything.
Is this possible?
Thanks.
Place your code in a Timer with its Mode set to ModeSingle and a short Period (say 10 milliseconds). The Timer will fire once the GUI finishes loading.
Or you can put your code in a thread and start the thread in the Window.Open event. That way if the code takes a while your entire application doesn't 'freeze' on you.
More info on threads in Real Studio at http://docs.realsoftware.com/index.php/Thread
One word of caution though with Threads. Directly updating GUI controls can be a bad thing - especially with Cocoa built applications.
I'm debugging a Cocoa application that can act as a handler to a custom URL protocol. The application works fine when I click on a link after the application has launched, but something is causing the app to crash if it has not launched at the time the link is clicked.
Is there any way that I can start the app in the debugger and "fool" it into thinking that I had just clicked on a link?
You can do
gdb --wait myAppName
and then click on the link to launch your app. This will cause your app to break into the debugger very, very early, before main has started.
Could you attach to your process from XCode once the URL handler has been invoked? You could try putting a modal NSAlert in your URL handler code so that will pause it until you can attach to your process.