Control will not open if another application is using port 3000

[EverlastEngineering]

Mac [v1.0.364] I'm a software engineer and had left a local development server running from work, on port 3000. I tried Control for the first time today and just opened to a white screen, no messages or errors.

I used Debugtron to open Control and found it failed to open due to port 3000 being in use in index.js.

config.webPort = process.env.WEB_PORT || 3000;

Notice that it may use an environment variable of WEB_PORT but this will also not work, since the application doesn't open using that variable:

jogWindow.loadURL("http://localhost:3000/");

Some possible resolutions:

1. Use a higher, less often used port by default.
2. Use a try / catch and try a small array of ports.
3. Show an error message if there is a failure.
4. Use the config.webPort to listen to the right port.

Hope this helps. Looking forward to playing around with this and seeing what I can do with it! :)

[EverlastEngineering]

(The white screen was my development server sitting in a breakpoint, ironically!) :)

[petervanderwalt]

4. Use the config.webPort to listen to the right port.

That is the intended workaround for advanced users, if you have a moment - happy to accept a pull to fix the

jogWindow.loadURL("http://localhost:3000/");

[EverlastEngineering]

Sure thing!

[petervanderwalt]

• Show an error message if there is a failure.

and not urgent - but yes, currently errors are only logged when you run from cmd/terminal - been meaning (for years) to implement global catch and then display message using https://www.electronjs.org/docs/latest/api/dialog (no webserver/ui needed, so covers cases like port conflicts too - uses native dialogs - I expect it will popup over a white window / wrong page load too)

[EverlastEngineering]

PR made.

[petervanderwalt]

Ahh the little details always spoil the fun (:

The ports array works great but - as we use localstorage in the frontend, the url changes, and could lead to someone thinking all their macros are lost (localstorage for localhost:3000 vs localstorage for localhost:other

Of course extremely remote that someone will be running a conflicting app (2-3 reports in all these years) in the first place, but something to remember

Will tweak it a little before release - but thanks for the legwork!

[petervanderwalt]

also https://github.com/OpenBuilds/OpenBuilds-CONTROL/blob/ea19e64aab66d9913ebca278663f10d449865c9a/app/js/widget.js#L4-L14 would have to be modified to use the correct port

[petervanderwalt]

Reverted the Error message dialog for now (commented out in v1.0.367)

Couple customers had issue with the update - but I am swamped with 2 other projects so can't debug right now. Will revisit at some point.

I don't think you use indexOf in your code, so its more likely the new uncaughtException catching a previous error that was failing silently (but continuing) up to now. Hard part is I am unable to replicate, and of the 800+ updates till this morning, only two were affected.

[EverlastEngineering]

No problem, I'll give it a peek tonight.

[EverlastEngineering]

Yeah, that is just reporting an error. Let me see what I can do about making it able to progress past an unhandled exception.

[EverlastEngineering]

If the user affected clicked ok, the application would continue as normal. If the application closed, then the application would close without the error dialog as well. The error in the picture is a normal dialog showing the error that was trapped, not an error of the dialog system.

But first, while improving this error trapping, one time, I got an error in websockets.js on line 263:

if (data.response.indexOf('$') === 0) {

I've put some safer code there, checking for data.response && falling down to an if else and then else. I don't know what that does, so you should probably have a look. Alternatively, you could leave this change OUT and just implement the rest of this PR, maybe best, just to see if the affected users get this error or not.

In addition, I've added err.stack instead of err.message. It gives a lot more detail for you, AND a Suppress Errors button for that session so if a user has a sh&t ton of errors it will act like the commented out code.

FYI: This image is faked with an intentional error just to show the output.

Hope this helps, Jason

[EverlastEngineering]

Also, I added in the electron console logger for vscode to see the browser console logs in the node terminal console which I've found very handy. Lemme know if you want me to pull that or something out.

[EverlastEngineering]

Oh yeah, and you can set the error dialog to be suppressed from the get-go with an environment variable of SUPPRESS_ERRORS set to true if a user really has trouble but needs this build.

IMO, this kind of thing is all about getting the user to want to help you, hopefully this helps you get there.