AW: Problem with Studio 4.3.0.0 Windows 2003 Terminal Server an Print Spooler

[Michael Mantkowski]

Hmmm, I always assumed that it was my library causing crashes and delays
when picking up printer information.

I never suspected that Omnis itself was also doing some of this.

That might explain a few "unexplainable" problems over the years.

Michael

*********************************************************************
Michael Mantkowski
ClienTrax Software
1-800-416-2815
*********************************************************************

-----Original Message-----
From: omnisdev-en-bounces at lists.omnis-dev.com
[mailto:omnisdev-en-bounces at lists.omnis-dev.com] On Behalf Of Brian
O'Sullivan
Sent: Friday, January 08, 2010 10:56 AM
To: OmnisDev List - English
Subject: Re: AW: Problem with Studio 4.3.0.0 Windows 2003 Terminal Server an
Print Spooler

sethpaien wrote:
> Hi,
>
> For the Omnis telling you that the default printer has changed, you can
> change this behaviour using :
>
> Calculate $root.$prefs.$printernotify as kPrtNoteAuto (or kPrtNoteMsg or
> kPrtNoteNoMsg)
Unfortunately, though, this requires code to execute from a library. 
When opening Omnis (dev) without a library under TS, I often get 
prompted about the default printer changing, and sometimes our runtime 
users still get the prompt because there is sometimes a delay between 
the time that the Omnis.exe starts and the library finally loads. Never 
seen a delay as long as Rudolf describes, but have definitely seen 
similar scenarios on a smaller timescale.  I agree with Andy - would 
really like to know why Omnis.exe needs to gather printing-preference 
info as the executable starts up, and even more so would like to be able 
to tell it to defer that until the first time a user actually prints.
_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com