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 = new util.window();
var w = win.open(print_url);
w.go_print = 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.
--
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
| web: http://www.esilibrary.com
------=_Part_11691_1625161398.1290033081340
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
><span><meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dut=
f-8">That indicates it may be solved by removing the [randomstring].default=
profile in the C:\Documents and Settings\[username]\Application Data\OpenI=
LS\open_ils_staff_client\Profiles folder (in WinXP - in Windows Vista/7 thi=
s would be a slightly different directory path). By "solved" I mean t=
hat it may cause the problem to stop happening - if Jason or one of the oth=
er developers can ferret out the root cause of it happening in the first pl=
ace, that would be ideal, of course.</span><div><div><span id=3D"8784d773-b=
651-4753-b434-70638abac966"><br><span name=3D"x"></span>Chris Sharp<br>PINE=
S Program Manager<br>Georgia Public Library Service<br>1800 Century Place, =
Suite 150<br>Atlanta, Georgia 30345<br>(404) 235-7147<br>csharp at georgialibr=
aries.org<br>http://pines.georgialibraries.org/<span name=3D"x"></span><br>=
</span><br><hr id=3D"zwchr"><blockquote style=3D"border-left:2px solid rgb(=
16, 16, 255);margin-left:5px;padding-left:5px;"><b>From: </b>"Gordana Vitez=
" <gvitez at niagaracollege.ca><br><b>To: </b>"Evergreen Development Dis=
cussion List" <open-ils-dev at list.georgialibraries.org><br><b>Sent: </=
b>Wednesday, November 17, 2010 3:46:40 PM<br><b>Subject: </b>Re: [OPEN-ILS-=
DEV] 2-second go_print workaround did not work?<br><br>
<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=3D"2" face=3D"Calibri">Gordana Vitez</font></div>
<div><font size=3D"2" face=3D"Calibri">Library Services & Systems Coord=
inator<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 >&=
gt;><br>The interesting thing is that Evergreen will show this error mes=
sage under<br>one Windows user, but not any others. <br><br>Unfortunately, =
the computer having this issue on the circulation desk at one<br>of our bra=
nches 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>82=
3 Telfair Street<br>Augusta, GA 30901<br>Phone: (706) 821-2637<br>Cell: (70=
6) 627-5586<br><a href=3D"http://www.ecgrl.org/" target=3D"_blank">http://w=
ww.ecgrl.org/</a><br><br><br><br>-----Original Message-----<br>From: open-i=
ls-dev-bounces at list.georgialibraries.org<br>[mailto:open-ils-dev-bounces at li=
st.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><dudleyb_mail=
ing at ecgrl.org> wrote:<br>> One of our staff received this error messa=
ge 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 repr=
oduce it<br>consistently, then we may be in a position to experiment and fi=
x 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 o=
f<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>xu=
lrunner), and whether it happens on Mac or Linux in addition to<br>Windows.=
<br><br>From a development standpoint, the original idea behind printing wa=
s<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>poss=
ible, before closing itself and returning to the main application.<br>Exper=
iments using hidden iframes, etc. for the content did not prove<br>successf=
ul. The printing would also need the option of being silent<br>(not p=
rompting for which printer to use, etc.) and of remembering<br>settings ind=
ependently of the operating system settings, and of being<br>able to work i=
f spawned from modal pop-up windows.<br><br>To handle this I turned to XPCO=
M (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 le=
ad 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 cl=
ose the<br>window (the function itself having a reference to the window in =
a<br>closure).<br><br>Something like:<br><br>JSAN.use('util.window); var wi=
n =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.&=
nbsp; 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 func=
tion 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'r=
e able to reproduce this bug on demand (or at least fairly<br>often), espec=
ially in a non-production system that we can tweak<br>without affecting any=
one, then we can try out alternate<br>implementations (especially with mode=
rn xulrunners) to see if they fix<br>the problem.<br><br>-- <br>Jason Ether=
idge<br>| VP, Tactical Development<br>| Equinox Software, Inc. / Your Libra=
ry's Guide to Open Source<br>| phone: 1-877-OPEN-ILS (673-6457)<br>| =
email: jason at esilibrary.com<br>| web: <a href=3D"http://www.esi=
library.com" target=3D"_blank">http://www.esilibrary.com</a><br><br></div>
</blockquote><br></div></div></div></body></html>
------=_Part_11691_1625161398.1290033081340--
More information about the Open-ils-dev
mailing list