I assume it was trying to restore a connection to a network printer that they hadn’t had the credentials saved for. I’ll have a play around with this when I get a chance.
It’s just nuts that the app crashes cold, without even a chance to catch an exception. That’s what worries me a lot, though being able to tell users why there’s a problem is the most important thing.
Thanks for your help!
I do not think so. Unless I am wrong, those people cannot print anything. Their fault (probably) because they do not select a Printer before launching your application, but a solution exist.
Who said they must print something?
Actually, a huge part of my app is printing - reports, labels, wheels, all kinds of things. So I’d expect that 99.9% of my users would have a printer, but in the recent cases they evidently don’t. I’m just bummed that a Xojo app can totally crash when an app tries to get default printer info. If nothing else, I’d expect an exception to be raised that I can catch.
1 Like
That just means the OS crashes your app. You won’t be able to catch that from inside your Xojo app, as expected.
Try lo load all your UI before start doing initializations.
Printing in Xojo really sucks. In my last apps I had to use declares to get the printers info and sent the printers job directly. (winspool.drv)
Why not just use App.Mutex - and eliminate IPCSocket altogether. This seems like sending a snail mail vs sending an email 
If you need an example, I can post one later.
Thanks!
Windows Functionality Suite (by Aaron Ballman) uses an IPC socket on Windows when a second instance of the app is launched by double-clicking a document file, the second instance can send the file path to the first instance to open it, while the second instance closes.
If your app needs to send somenting from the openning instance to the first one it is ok the IPC socket. If not it is better to not use it.
I’ve been trying the Mutex and IPC socket route this week, and found it unreliable.
If the app terminates unexpectedly, I was told the undeleted ‘lock’ file would be cleared by Windows… this does not appear to happen on my machines, which means the next run of your app won’t start, as it thinks there is another one running already.
That leaves you having to come up with a way to force start, or delete an orphaned file.
With IPC Socket, you should not have the problem. Since the first launched app replies only if it is running, and unexpected quit would mean the first app simply won’t respond and you can safely go on running.
1 Like
That”s funny, I realized some days ago that I never printed anything (excepted to pdf) with this MacBook Pro M1 computer.
Worst, I have printer(s), but no ink because the cartridges are bad far before there is no Ink.
Back on the question: the application crash because there is no defined (default) printer (because they never set one because they never print anything with the App running computer).
This is a well know developer error to not initialize the “print process” to avoid this crash. Reference: “Apple France developer suppport, 1988”.
1 Like
Try this demo. I’ve had unreliable results with IPC on Windows also. The method attached has not failed me yet, and can be adapted for any number of purposes. For the attached demo, compile, then run an instance of the app. Try dropping a file on the EXE of the compiled application and the command line will be passed to the running application, not permitting another instance to start.
**also handles straggler files should the app crash for any reason, permitting a clean restart.
1 Like
Thank you, I will