David.......
I share your frustration on this issue..... At this point there is
no known work-around for 5.5.5..... and several of us have tried
everything we can think of.
The problem still occurs under 2006r1..... but I am not sure if it
is less frequent or not...... I have tried to change my code to
"reuse" the same setup string instead of creating a new instance each
time I print but have run into another problem implementing it (see
"sinfamxk").
Jim
On Mar 22, 2006, at 11:18 AM, realbasic-nug-
[EMAIL PROTECTED] wrote:
Subject: The continuing Windows printerSetup-related crashing woes
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 22 Mar 2006 01:18:28 -0500
Please see my recently added comments to hagzejij.
I'm running into the same problems others have mentioned with crashing
in Windows on using printerSetup, using a commercially shipping app
built
on RB 5.5.5; I've tried all of the workarounds that have been
mentioned
on these lists; and in the worst cases, none of these help.
I am:
- Creating only one fPrinterSetup for the application, and using it
during
the entire app session.
- There's nothing wrong with the printer string that I'm pulling out
of fPrinterSetup; saving as binary data into preferences; and later
putting
back into fPrinterSetup the next time the app is launched.
- For most Windows users, it doesn't crash
- For a few (seems to be most, if not all, people with HP
printers); it
crashes an first access (validation check) of fPrinterSetup while the
app is launching. In the worst case, it crashes nearly every time
someone
launches.
- Putting a delay of a few seconds between creating fPrinterSetup and
accessing it doesn't help.
- Putting in an md5 check of the string being set vs. the internal
string
in fPrinterSetup, after being set, doesn't help because it crashes
before/while
fPrinterSetup is being accessed. (I can tell where it crashes on a
customer's
system due to log file reporting).
- Repeatedly setting the string in a loop doesn't help because it
crashes
in the first loop iteration.
There are no problems in the OSX build; this only happens in the
Windows
build.
I seem to remember seeing a mention in one of the lists about there
being
a fix for a memory leak of a DC (device context), presumably in an
earlier
build of RB2006 early in January, which presumably makes RB2006
more stable
(even if not yet perfect, as the bug reports continue to indicate).
Is there any possibility of making the same fix to RB 5.5.5, if
this will
make Windows printerSetup issues more stable with apps built that way?
--
David Miller
Senior Software Developer, Digital Color Solutions
ColorVision
_______________________________________________
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>
