No subject
Fri Apr 16 10:15:54 EDT 2010
to have a data-URL spawned window handle templating, rendering, and
printing of a receipt, hopefully while minimized and as quickly as
possible, before closing itself and returning to the main application.
Experiments using hidden iframes, etc. for the content did not prove
successful. The printing would also need the option of being silent
(not prompting for which printer to use, etc.) and of remembering
settings independently of the operating system settings, and of being
able to work if spawned from modal pop-up windows.
To handle this I turned to XPCOM (nsIWebBrowserPrint), though these
days we may want to experiment with window.print and the
print.always_print_silent Mozilla preference. At the time, including
the XPCOM directly in the print window would lead to crashes, so as a
workaround we began injecting it into the window as a callback
function, the same way we inject xulG into content windows elsewhere
in the client. The onload handler for the print window would call the
injected function, which would handle the printing and close the
window (the function itself having a reference to the window in a
closure).
Something like:
JSAN.use('util.window); var win =3D new util.window();
var w =3D win.open(print_url);
w.go_print =3D function () { xpcom_print(w); w.minimize(); w.close(); }
There's a bug where the go_print function is never seen by the onload
handler. A setTimeout was attempted to see if it was a race
condition, and thus the origin of the "2-second workaround", but it
never sees the function either. This kind of reminds me of the pain
we're seeing now with Dojo and Mozilla and premature onload events.
Hrmm.
If you're able to reproduce this bug on demand (or at least fairly
often), especially in a non-production system that we can tweak
without affecting anyone, then we can try out alternate
implementations (especially with modern xulrunners) to see if they fix
the problem.
--=20
Jason Etheridge
| VP, Tactical Development
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 1-877-OPEN-ILS (673-6457)
| email: jason at esilibrary.com=20
| web: http://www.esilibrary.com=20
--=__PartDFF27A20.0__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML
<HTML><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18939"></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Hi there,</DIV>
<DIV> </DIV>
<DIV>I'm afraid I have nothing to offer in the way of a resolution. =
However, I can report that we experience the same problem...under my =
windows login...so I'm no longer allowed to login at the circ desk.</DIV>
<DIV> </DIV>
<DIV>We are running 1.6.1.2 with Windows XP and it only happens to =
me.</DIV>
<DIV> </DIV>
<DIV>Thanks!</DIV>
<DIV>Gordana</DIV>
<DIV> </DIV>
<DIV>
<DIV><FONT size=3D2 face=3DCalibri>Gordana Vitez</FONT></DIV>
<DIV><FONT size=3D2 face=3DCalibri>Library Services & Systems =
Coordinator<BR>Niagara College Libraries<BR>Welland Campus<BR>300 Woodlawn =
Rd<BR>Welland Ontario<BR>L3C 7L3<BR>Phone: (905) 735 2211 ext 7404<BR>Fax: =
(905) 736 6021<BR>gvitez at niagaracollege.ca</FONT></DIV><BR><BR>>>>=
"J. Benjamin Dudley" <dudleyb_mailing at ecgrl.org> 17/11/2010 2:54 pm =
>>><BR>The interesting thing is that Evergreen will show this =
error message under<BR>one Windows user, but not any others. <BR><BR>Unfort=
unately, the computer having this issue on the circulation desk at =
one<BR>of our branches in another county. <BR><BR>I may be able to clone =
the PC so we don't have to take that one away from<BR>the desk.<BR><BR><BR>=
J. Benjamin Dudley<BR><BR>Systems Administrator<BR>East Central Georgia =
Regional Library<BR>823 Telfair Street<BR>Augusta, GA 30901<BR>Phone: =
(706) 821-2637<BR>Cell: (706) 627-5586<BR><A href=3D"http://www.ecgrl.org/"=
>http://www.ecgrl.org/</A><BR><BR><BR><BR>-----Original Message-----<BR>Fro=
m: open-ils-dev-bounces at list.georgialibraries.org<BR>[mailto:open-ils-dev-b=
ounces at list.georgialibraries.org] On Behalf Of Jason<BR>Etheridge<BR>Sent: =
Tuesday, November 16, 2010 10:54 AM<BR>To: Evergreen Development Discussion=
List<BR>Subject: Re: [OPEN-ILS-DEV] 2-second go_print workaround did not =
work?<BR><BR>On Tue, Nov 16, 2010 at 10:13 AM, J. Benjamin Dudley<BR><du=
dleyb_mailing at ecgrl.org> wrote:<BR>> One of our staff received this =
error message today while printing a<BR>receipt<BR>> (and all subsequent=
receipts) for a patron:<BR><BR>This has been a thorn in my side for a =
long time and I've never been<BR>able to reproduce it myself. If =
you're able to reproduce it<BR>consistently, then we may be in a position =
to experiment and fix it<BR>(in the case of PINES, please let your =
helpdesk know in addition to<BR>whatever you try here). One problem =
is that when the bug happens, a<BR>workaround is attempted, and the =
resulting print dialog forgets all of<BR>your configured printer settings =
(and should rely on the operating<BR>system level defaults). You're =
using EG 1.4? It'd be useful to know<BR>if other folks are seeing =
this with other versions of EG (and<BR>xulrunner), and whether it happens =
on Mac or Linux in addition to<BR>Windows.<BR><BR>From a development =
standpoint, the original idea behind printing was<BR>to have a data-URL =
spawned window handle templating, rendering, and<BR>printing of a receipt, =
hopefully while minimized and as quickly as<BR>possible, before closing =
itself and returning to the main application.<BR>Experiments using hidden =
iframes, etc. for the content did not prove<BR>successful. The =
printing would also need the option of being silent<BR>(not prompting for =
which printer to use, etc.) and of remembering<BR>settings independently =
of the operating system settings, and of being<BR>able to work if spawned =
from modal pop-up windows.<BR><BR>To handle this I turned to XPCOM =
(nsIWebBrowserPrint), though these<BR>days we may want to experiment with =
window.print and the<BR>print.always_print_silent Mozilla preference. =
At the time, including<BR>the XPCOM directly in the print window would =
lead to crashes, so as a<BR>workaround we began injecting it into the =
window as a callback<BR>function, the same way we inject xulG into content =
windows elsewhere<BR>in the client. The onload handler for the print =
window would call the<BR>injected function, which would handle the =
printing and close the<BR>window (the function itself having a reference =
to the window in a<BR>closure).<BR><BR>Something like:<BR><BR>JSAN.use('uti=
l.window); var win =3D new util.window();<BR>var w =3D win.open(print_url);=
<BR>w.go_print =3D function () { xpcom_print(w); w.minimize(); w.close(); =
}<BR><BR>There's a bug where the go_print function is never seen by the =
onload<BR>handler. A setTimeout was attempted to see if it was a =
race<BR>condition, and thus the origin of the "2-second workaround", but =
it<BR>never sees the function either. This kind of reminds me of the =
pain<BR>we're seeing now with Dojo and Mozilla and premature onload =
events.<BR>Hrmm.<BR><BR>If you're able to reproduce this bug on demand (or =
at least fairly<BR>often), especially in a non-production system that we =
can tweak<BR>without affecting anyone, then we can try out alternate<BR>imp=
lementations (especially with modern xulrunners) to see if they fix<BR>the =
problem.<BR><BR>-- <BR>Jason Etheridge<BR>| VP, Tactical Development<BR>| =
Equinox Software, Inc. / Your Library's Guide to Open Source<BR>| =
phone: 1-877-OPEN-ILS (673-6457)<BR>| email: jason at esilibrary.c=
om<BR>| web: <A href=3D"http://www.esilibrary.com">http://www.esilibr=
ary.com</A><BR><BR></DIV></BODY></HTML>
--=__PartDFF27A20.0__=--
More information about the Open-ils-dev
mailing list