I have something to add here. I've been going through my app, trying to work around the same issue (crash) when trying to put a string into a newly created printerSetup object, and I've tried everything I've seen in any of these threads and suggested workarounds.
(Allocating the printerSetup only once; putting a delay, between allocation and actually doing something with it; various pieces of code to compare the string inside the printerSetup after it's been put in there, to make sure it matches the source string, such as doing an md5 comparison). None of this -completely- solves the problem for all users. It can lessen the frequency, and sometimes a crash will happen only once on startup, but the issue of this happening still crops up too frequently. *** I'll share one additional thing I discovered last week which may also help or shed some light on this; I ran into this when I was debugging on an XP installation running in Korean. (As an aside, I have a completely built and debugged, shipping Mac/Win commercial application with all localizations prepared and imported using REALGlot 2.51. I continue to see sporadic posts either here or on comp.lang.basic.realbasic saying this is problematic, but I can assure you that I've been able to sequentially import French, German, Italian, Spanish, Japanese, Korean, S. Chinese and T. Chinese into a very verbose application this way, and it is a success) Running in Korean, doing an md5 comparison on the setupString outside the printerSetup, and then the internal contents, wasn't matching. I couldn't get the printerSetup to accept the string and so I was unable to properly change the Page Setup. I started looking at the encoding of both the external string and the printerSetup's setupString, and this is what I found. First of all, the string that I'm writing as binary into preferences and then reading back in again is correct, but has a nil encoding. (This is a copy of the string that comes back when the user does an initial page setup in my application. I write a binary copy into prefs so that I can restore it on the next launch). Simply assigning this to the printerSetup on an English or European XP system works without a hitch. (Or at least, as well as can be expected, meaning that in some situations, most notably with HP networked printers selected as the current printer, it can still crash sporadically or consistently after doing this). But on the Korean system, no. A first look in the debugger showed that the printerSetup.SetupString encoding was US.ASCII, which would seem to be the case on all systems running in different languages. So my first attempt at fixing this was to copy my pref string to another; set its encoding based on whatever printerSetup reported for its SetupString encoding; and to do this before the assignment. Voila, this worked. At least, until it didn't. More debugging, and then I discovered that -sometimes-, the encoding of the printerSetup.SetupString on the Korean system is also nil. So assigning my temp string's encoding based on this didn't change anything, so, the same problem: md5 comparison doesn't match, the printerSetup won't take the string from the outside. So, for the moment, I'm forcing the encoding of my temp string to Encodings.ASCII before assigning it into the printerSetup object, and this appears to work at all times. It's not clear to me yet whether this is a separate issue, or also related to some/all of the ongoing Windows printerSetup-related crashes. People (like me) who are suffering under this may want to try something like this to see if it makes any difference: Dim encodedString as string // Here we go. Dim t as TextEncoding t = Encodings.ASCII // Let's make a local copy of what the caller sends, too. encodedString = DefineEncoding(theStringBeingPassedToMyFunction, t) // And finally, assign it. myPrinterSetup.SetupString = encodedString *** Along with others on this list, I'm fully prepared to debug and help come up with a "real" fix for Windows printing issues as soon as possible. This is really something that needs to be completely addressed in RB2006 at this point. David Miller Senior Software Developer, Digital Color Solutions ColorVision > >================================================== > >Message: 11 >Subject: Re: Windows HP printing update? >From: Meyer Jim <[EMAIL PROTECTED]> >Date: Mon, 10 Apr 2006 14:48:37 -0400 > >Joe...... > >I specifically asked Aaron about working-around the problem with >declares and he told me to forget it...... It would be extremely >difficult to do. I would expect a plugin would be just as bad. The >better solution is to just fix the problem. > >I have been trying to get this problem fixed for almost 2 years and >it seems to me to be a very reasonable request..... especially from >a company that says "Cross-platform that really works." .... which >in this case does not. > >Jim > >On Apr 10, 2006, at 2:29 PM, realbasic-nug- >[EMAIL PROTECTED] wrote: > >> Message: 9 >> Subject: Re: Windows HP printing update? >> From: "Joseph J. Strout" <[EMAIL PROTECTED]> >> Date: Mon, 10 Apr 2006 11:37:37 -0600 >> >> At 1:13 PM -0400 4/10/06, GregO wrote: >> >>> I love programming in REALbasic, I love the flexibility it provides, >>> I love how I get a slew of new features every 3 months, and I love >>> that I can easily make a Mac,Win & Linux versions when most of our >>> customers only want Windoze. <COMPLAINT>But I HATE the fact that my >>> Windows customers think we're idiots because we can't print a simple >>> report without crashing our own application!!!!!!! Please don't make >>> me go back to Visual Basic just so I can print!</COMPLAINT> >> >> I'm not REAL Software, but perhaps it's worth pointing out that there >> are options besides getting RS to fix it, and abandoning RB >> altogether. If there's something in particular that doesn't work >> properly in RB, you can always do that part via declares or a >> plug-in, while doing the rest of the app with the built-in >> functionality. >> >> Best, >> - Joe >> >> -- >> >> Joseph J. Strout >> [EMAIL PROTECTED] > >================================================== _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
