Dynamically Setting the Destination Printer, Not Default
Ryan Ross
I would like to programmatically change the current destination printer, not
necessarily the default printer. I can use:
dw_control.object.datawindow.printer
..to tell me what the current destination printer for any given datawindow, but
this property is not changeable.
My requirement is to NOT use PrintSetup() to bring up a dialogue for the user to
select a printer -- and since I already have a list of connected printers in a
string array, I *should* be able to somehow specify the current destination
myself.
Any ideas? Thanks.
Ryan
Sam Tai
Ryan,
I have a similar requirement, but I have not found a way around setting the
default printer. So in my case, I set the default printer, print, set the
default printer, print, etc.
You can always capture the original default printer and set it back after your
done printing so it at least "looks like" you've only changed the destination.
HTH,
Sam Tai
On Thu, 24 Jun 1999 13:53:34 -0400,
in powersoft.public.powerbuilder.datawindow
Ryan Ross <rross...@REMOVEstellar.bc.caREMOVE> wrote:
>I would like to programmatically change the current destination printer, not
>necessarily the default printer. I can use:
>
>dw_control.object.datawindow.printer
>
>...to tell me what the current destination printer for any given datawindow,
Ben McBride
Check out PowerPrinter from www.digitalw.com. It has all the necessary features to
solve your problem. HTH.
Ben McBride
Ryan Ross
Thanks for the reply.
My situation is that I am allowing the user to queue up any number of reports --
via multithreading -- setting parameters in advance (retrieval arguments AND
print parameters) for some complex reports that may take hours to run. I cannot
have the datastore or datawindow takings it sweet time retrieving and THEN ask
the user what they want to do with it, so I am determining the print details in
advance and storing them specific to each report.
What I am concerned about is when two reports become ready to print at the same
time (or close enough) and the registry gets set for one, read for another, and
the report gets sent off to the wrong printer. This may be costly to say the
least.
Here's my idea:
I am thinking that the datawindow or datastore takes its .Printer property at
the moment of construction. If I set the default printer in the Registry and
then immediately construct my datawindow/datastore, it might pick up the
printer. Since I know which printer I want it to be, I could put it in a loop,
constructing and destructing until it takes the right printer (just in case some
other datawindow/datastore has set its printer in the default in the meantime.)
I'd have to test this empirically, of course.
If it turns out I cannot specify different printers for different
datawindows/datastores in advance, I'm going to be very disappointed.
On Thu, 24 Jun 1999 14:30:38 -0400,
in powersoft.public.powerbuilder.datawindow
Sam Tai <sam...@cotelligent.com> wrote:
>Ryan,
>
>I have a similar requirement, but I have not found a way around setting the
>default printer. So in my case, I set the default printer, print, set the
>default printer, print, etc.
>
>You can always capture the original default printer and set it back after your
>done printing so it at least "looks like" you've only changed the destination.
>
>HTH,
>Sam Tai
>
>On Thu, 24 Jun 1999 13:53:34 -0400,
> in powersoft.public.powerbuilder.datawindow
>Ryan Ross <rross...@REMOVEstellar.bc.caREMOVE> wrote:
>>I would like to programmatically change the current destination printer, not
>>necessarily the default printer. I can use:
>>
>>dw_control.object.datawindow.printer
>>
>>...to tell me what the current destination printer for any given datawindow,
Sam Tai
Ryan,
I'm doing the same thing, but I only spawn one additional thread for ALL the
printing. Since the second thread is processing asynchronously (via POSTing),
it won't contend for the default printer at the same time. Are you spawning an
additional thread for EACH report that gets queued? If so, I'm not sure what to
do about that. Regardless, I think you shouldn't set the default printer until
you're ready to print (and not in the Constructor event). Maybe this will
minimize contention for the default printer by multiple printjobs.
Sam
On Thu, 24 Jun 1999 15:02:57 -0400,
Ryan Ross
Here's what I have found.
If I launch PowerBuilder, then run my application and do a
Describe("datawindow.printer") I get the Windows default printer name back from
the datawindow. Exactly as I see it in the Registry. No problem. Everything
is as expected.
If I then do a PrintSetup() to select a different printer, all the datawindows
in the application will respond with that printer's name using the Describe.
Still everything is as expected...almost.
I am running a Registry monitor concurrently, at NO TIME does it write this
newly selected printer's name back to the Registry. So, this setting is
application-wide. Almost.
If I close my application (returning to PowerBuilder) and then re-run the
application, this non-default printer is still current. Still nothing has been
written to the Registry or any .INI files anywhere. Trust me. The Registry
still shows the default Windows printer.
In other words, after a PrintSetup() has been done ONCE, there is no way to
programmatically control the destination printer. Setting the Registry is
useless until PowerBuilder and the application are both closed and re-opened.
If the PowerBuilder IDE is left open between runs of the application, the
application-default printer is still valid.
So my question is:
WHERE is the APPLICATION-DEFAULT PRINTER info stored? If PrintSetup() can get
in there and show and change the current App-Default Printer, how can that be
done in script WITHOUT user intervention?
There is ONE small comfort:
If PrintSetup() is NEVER run, PowerBuilder will continue to hit the Registry
every time the datawindow is told to print, or is asked what its destination
printer is.
My problem is that I am running a PFC application and there are numerous places
where PrintSetup() might get triggered. Once that happens, my script is no
longer able to steer print jobs to different destinations.
Urggghh.
Ryan
On Thu, 24 Jun 1999 17:08:30 -0400,
Sam Tai
Ryan,
I'm not seeing this. I ran my application, do a PrintSetup(), print some stuff,
and then execute the stuff in the second thread. The second thread changes the
default printer via the Registry and prints stuff. All this worked fine for me.
I should note that I'm using PB 6.5, EBF Build 570 on NT4 (SP 4).
BTW, what's the "Registry monitor"?
Good luck,
Sam
On Thu, 24 Jun 1999 18:21:37 -0400,
Robert A. Chauvin
printsetup is called, the registryset commands no longer have any effect. This is,
I believe, a bug, or at least a big hole in the design.
I also agree that there should be a better way of controlling the destination
printer/bin...
I haven't found third party dll's to be of much use (ie, PowerPrinter).