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

Michael Mantkowski michaelj at
Fri Jan 8 11:07:33 EST 2010

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 Mantkowski
ClienTrax Software

-----Original Message-----
From: omnisdev-en-bounces at
[mailto:omnisdev-en-bounces at] On Behalf Of Brian
Sent: Friday, January 08, 2010 10:56 AM
To: OmnisDev List - English
Subject: Re: AW: Problem with Studio 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

More information about the omnisdev-en mailing list