Member Avatar for RonR

I am using the code below to open the printer selection screen. when using it an a network

I have to unload my program after making a selection and then restart my program for the printer selection change to take effect.

any ideas on why this is happening? it used to work fine until an IT guy made some changes in the network some time back.


CommonDialog1.ShowPrinter

  • 3 Contributors
  • 9 Replies
  • 248 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by steve585

Dani AI

Generated

Short version: the Visual Basic runtime keeps a program-level Printer reference that does not automatically switch when the user changes the system default at runtime. The OS default can change from the dialog, but the app will keep using the Printer object it already has until you explicitly rebind it. That behavior explains why sees the new choice only after restarting the program.

A practical fix is to detect the system default after the dialog returns and then select the matching entry from VB's Printers collection. One reliable way is to query the Windows printer list (for example, via WMI to find the printer with Default = True), then loop the Printers collection and set the program Printer to the device whose name matches. Example pattern (VB6-style pseudocode):

' Query Win32_Printer for Default = True, get the name
' Loop Printers collection and Set Printer = Printers(i) when DeviceName matches

Troubleshooting steps to narrow things down: (1) After the dialog, open Devices and Printers in Windows to confirm the OS default actually changed immediately. If Windows itself did not change the default, the issue may be a server-side policy or login script that forces defaults. (2) If Windows shows the new default but your app still uses the old one, the app-level rebind above will solve it. (3) If this only appeared after the network/IT changes, ask IT whether printer mapping or group policy enforces defaults at logon — those can override user changes or only apply on sign-on.

Note on print-job calls: as observed, commands that finish or cancel a print job affect job lifecycle but do not refresh which printer the app will use next. As already checked, having a default printer present is required, but you still must reselect it in your VB runtime when the user changes it at runtime.

Recommended Answers

All 9 Replies

Member Avatar for debasisdas

Do u have any difault printer on the pc.
You better consult the person who made the changes.

Member Avatar for RonR

yes, there is a default printer.

before we complain to the IT guy I was just checking to see if anybody had any ideas.

Member Avatar for steve585

do you have this line in your code

Printer.KillDoc

Member Avatar for RonR

I was not aware that I had to use KillDoc in relation to the showprinter.

would I need that command before or after the printer dialog is on the screen?

Member Avatar for steve585

This is how I work:

CommonDialog1.ShowPrinter
Printer.Print Tab(10); "Something"
Printer.KillDoc

Member Avatar for RonR

when printing is finished, I use


Printer.enddoc

Member Avatar for steve585

I didn't use enddoc so far.
Does it work to you killdoc?

Member Avatar for RonR

KillDoc is to stop a printing in progress, Enddoc is when you have finished sending all data to the printer, it resets the printer and gets it ready for teh next printing session.

Member Avatar for steve585

ok

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.