Feedback Case #47610 - Graphics.NextPage results in the application hanging in Threads in MacOS 64-bit.
When building for macOS 64-bit, using Graphics.NextPage in a Thread will cause the built application to freeze. The application becomes non-responsive and the macOS Dock shows that the Application is Not Responding. It behaves similar to what happens when a built app is in a infinite tight loop.
I included a simple sample project showing the issue with the feedback case.
This works as I would expect when building for 32-bit.
Sure, but your app still needs to be responsive. Imagine the worst case and someone trying to print 10,000 pages by accident. The UI would be unresponsive because it takes a while to send that much data to the print spooler and the only way to kill the print would be to kill the app and then cancel the print queue. All doable, but printing from a thread doesn’t seem all that unreasonable.
You are correct. Most users would act this way. But the best way would be to Pause the Spooler and Cancel the Print Job once the App finished sending the Data to the Spooler.
But i do not want to hijack the Thread. @Joe Ranieri already said it’s a bug and we have a Feedback Case. Thank you @Bob Keeney
As @Bob Keeney already indicated, I am printing from within a thread to keep the application UI responsive. For this particular application, each page is generated in a thread to a “description” format (an intermediary step that describes the page layout) and then cached. A separate thread watches the cache and, when a new cached page descriptor is available, it takes that description and generates the actual drawing commands to the printer to print the page. If I didn’t have this threaded, the application would be completely unresponsive for long periods of time (print jobs can be 100s of pages long). Plus, there is a progress window that is displayed that shows progress of generating the cache as well as actual pages being sent to the printer. Generating the cache tends to be faster than spooling the pages to the printer, so this is the the best way I could come up with to ensure that printing started right away but didn’t also lock up the UI.
Just a thought; if you’re rasterizing to a intermediary format, couldn’t you then send that to a helper application, which then prints in the background, keeping your main application free of the actual printing?
I suppose I could, but I have next to no experience with that sort of setup. I wouldn’t know where to begin. And, I can’t help but think (at least to my inexperienced brain) that this would be added complexity. Maybe I’m wrong there and this would be a simpler solution?
Of course, you can wait the next 2-3 years (just kidding) until the bug is fixed.
Welcome to the new world of helper apps. Of course, this is added complexity. But sometimes it’s the only solution. You mainly need 2 things:
The 2 apps need to communicate. IPC, TCP, even AppleScript. For one app of mine a simple AppleEvent does the job. For another I use xml with TCP. For yet another I will be using a combination of TCP and shared memory (MBS plugin!).
You need to manage your build process. The second app needs to be in a special place in the main app. You need to sign the helper, too, of course. It’s now even possible to build both apps at once.
In the simplest form, you write out your immediately data to a single file, then you call your helper application passing it that file, it opens, reads the file, processes and print it, then quits.
Obviously there’s a bit more fleshing out you need to do, but in principle it’s not scarily complicated.[quote=324413:@Beatrix Willius]The 2 apps need to communicate. IPC, TCP, even AppleScript. For one app of mine a simple AppleEvent does the job. For another I use xml with TCP. For yet another I will be using a combination of TCP and shared memory (MBS plugin!).[/quote]
You can also use ICP sockets to communicate.
For Scott’s project, I only see the need for one way communication, unless I’m mistaken so he could save some effort here.
Ten months later and this is still a problem. I’m, frankly, surprised that this is still the case. Looking in Feedback and it looks like my original bug report was verified on April 4th, 2017. But we’re now on Xojo 2017r3 and this exact same behavior is still occurring. Am I the only one that is seeing this? Am I the only one printing from a thread?
I haven’t been beating the drum about this over the last several months because my focuses have been elsewhere, but with Apple’s 64-bit deadline fast approaching, my focus has returned to updating this application to 64-bit and I need to find a solution to this. Unfortunately, a helper application is not an ideal solution in this case and adds what I say as needless complexity for this particular application.
Develop the “unnecessary complex” feature of a helper app
Pray to Chtuluh (spelling?)
Use a different method of printing where you don’t use Graphics.next page. For instance I have html which I convert to pdf
Be a dead fish in the water when 10.14 comes around
Helper apps aren’t that complicated. I’m not working on my third one. You need to study the IPC example, which is one method. Then you need to define your communication. Debugging is annoying, but I simply start both apps in the debugger.
It’s not that I don’t understand the point you all are making about a helper app. Granted, I haven’t gone down that route and would need to research to understand how to make it work, but I’m sure it could be done and, perhaps, it is easy to do.
My point is, I shouldn’t have to. It does add unnecessary complexity to my application. I have a solution right now that works perfectly when compiled for 32-bit. This application is a very simple application. But, printing occurs within a loop and it is of key importance that the UI remains responsive during printing. I can put in the work to learn and implement a helper app to handle printing (and I probably will go ahead and learn because I can see situations where it would be beneficial). But, for this application, it adds complexitycomplexity I see as unnecessary because it’s already working, except for having to compile for 64-bit reveals an issue that Xojo has already verified is a bug.
I’m not saying that Xojo needs to drop everything and immediately rectify my situation. And, heck, it’s entirely possible this is not a simple fix and would require some sort of large-scale refactoring and that’s why it’s not yet been addressed. I’m just saying that I’m surprised no-one else is running into this. Does everyone else handle any and all printing via a helper application? Is that really the one true way of doing this?
You are arguing in circles. Sure, you shouldn’t have to add the complexity. Sure, it may be an easy fix for Xojo. Do you need a 64bit app or can you wait until Xojo fixes this? That is the question you have to answer.
At the moment I’m having a go again at my helper app for getting AppleScript data out of mail. If Apple would fix the speed issue I also wouldn’t have to fiddle around with this. I don’t understand why AppleScript is so slow for High Sierra. But very likely they will fix this way after Xojo fixes your bug.
