My customers are reporting crashes when printing under 64-bit windows. I’ve tracked the crashes down to assigning a saved setupstring to a printersetup. The string is being saved and loaded from the local disk, and the app crashes as soon as the string is reassigned to the printersetup. The app crashes with no exception thrown, thus it cannot be caught, and just displays the “has stopped working” message. I have tried encoding and decoding with base64 to no avail. This does not happen every time, but every case I’ve investigated so far involves HP printers. This is causing real friction with my users as I cannot provide a fix.
Does anyone have any experience with this? Is assigning setupstring not really supported in 64-bit? Is there some simple thing I’m missing here?
Hmmm, I’m not sure if they have multiple printers, but it’s possible. In any case, I’m not saving each printer separately. How can I know that they have chosen another printer? It doesn’t appear that the printer name is available from printersetup. Do I need to parse the setupstring?
If I display the setupstring in a MsgBox before assigning it to the printersetup, the app doesn’t crash! I see no reason why this would make a difference, but it does:
's = string read from disk
msgbox s
ps.setupstring = s
If I comment out the msgbox, the app crashes. I thought it might be a timing issue, but I tried displaying a different string in the msgbox, and the app started crashing again. What is it about a msgBox that can cause this? I looked at the string before and after and it seems unchanged - encoding is the same, length is the same. Weird.
This is so strange to me that I may post a new thread about it, but I’d like to know how I can mimic the crash-avoiding effect without the msgBox!
dim psString as String = EncodeBase64(PrinterSetupString) for storing
and
dim psString as String = DecodeBase64(loadedStringfromFile) for loading?
The Printersetupstring contains binayry characters and can contain control characters. So the setup string should be stored in binary format or saved in EncodeBase64 format as text. When EncodeBase64 is used for storing then the string has to be read and then converted with DecodeBase64.
So my question is: Do you have stored the Printer Setupstring in a text file before you opened this thread?
Thanks - yes - I have been doing exactly as you describe:
dim pss as String = EncodeBase64(ps.SetupString)
and
dim pss as String = DecodeBase64(loadedPSS)
Still crashes. I don’t think the issue is with saving and loading - I have compared the string before and after the save-load, byte-for-byte and they are exactly the same. I think the issue is with Xojo assigning a setupstring in 64-bit Windows systems with certain printers. Maybe it’s a printer-driver issue. I don’t know, but it cannot be trapped with exception handling, and I can’t solve this and my customers are angry.
I have run into similar crashes and it does appear to be printer driver related. The “cure” so far has been to dumb down the printer driver by adding another printer to the user’s machine pointing to the same physical printer but using an older but compatible driver. So far HP LaserJet 2100 has been a good choice. It even worked for a high-end Cannon multifuction printer. As long as it’s a PCL5 compatible machine, you can get away with this “hack”.
Don’t know if that’s an option for your users, of course.
If showing the string in a dialog fixes the issue, you might want to check the encoding of that string. It may be that the printer routine expects UTF8, but that it’s Nil when you retrieve it from disk.
Thanks for the suggestions. I will look into using a more generic PCL5 driver. Hopefully my customers will bear with me on this if it works.
As for the encoding, I tested this and the encoding does not change after display in the message box. I also tried converting the encoding. I tried many encodings - non work. I do know that there is binary data in the string, so I’m wondering if Xojo is even providing a valid setupstring from a 64-bit windows system.
[quote=106351:@Richard Nicolella]Thanks for the suggestions. I will look into using a more generic PCL5 driver. Hopefully my customers will bear with me on this if it works.
As for the encoding, I tested this and the encoding does not change after display in the message box. I also tried converting the encoding. I tried many encodings - non work. I do know that there is binary data in the string, so I’m wondering if Xojo is even providing a valid setupstring from a 64-bit windows system.[/quote]
Just a hunch, but what if the msgbox itself mitigates the problem and not the fact that you display the setting string ? What if instead of the settings you simply display ‘Click here to print’ ?
As I mentioned up-thread, I tried displaying a different string in the msgbox, but the app crashed again. Only when the actual setupstring is displayed does the crashes cease. Perplexing. I’d love to hear someone at Xojo chime in on this.
Very interesting! I have a very similar thing - we’re using a XOJO made app in our office (15 people) using Win 7, Win XP (some) and Macs. We have one main printer with 3 different paper trays with different papers in it for different docs we’re printing from the app (delivery notes, invoices, copies of … whatever). Thus the printerSetup-thing is extremely important because I don’t want the users to have to decide what doc to print in what tray.
It worked like a charm with our old HP 4050 series - and stopped working for the Win XP clients after updating to a HP 3015 with the universal printer driver. XP crashes, Win 7 doesn’t “remember” number of copies from the printerSetup string (it’s ALWAYS 1 in “copies” where it used to say 2 with the older driver when setup that way).
The XP crashes are also don’t show in the debugger - a “msvcr120.dll” crashes instead. I strongly believe that it crashes when I set the printersetup-string from the file (as described above).
I’ll try an older printer driver an see what happens. But this obviously seems to be a strange bug. Win 7 behaves a bit less drastical but it’s still annoying that it will never print 2 copies (except if you remember to manually put in 2 in the dialog window …) - my colleagues are a bit annoyed about the whole situation (and want the old printer back).
