Strange Mess with a Printer Sub

Solo712

Registered User.
Local time
Today, 09:38
Joined
Oct 19, 2012
Messages
838
I have been using a printer-selecting listbox without an incident for a number of months now. It is for Access printouts of Excel spreadsheets. So far no problems. The two routines below register local and network printers and select active printer among them:

Code:
Public DefPrinter As String
Public Declare Function SetDefaultPrinter Lib "winspool.drv" _
Alias "SetDefaultPrinterA" (ByVal pszPrinter As String) As Long
 
Private Sub LoadPrintersListBox()
    Dim prtLoop             As Printer
    Dim strListRowSource    As String
    Dim DefPrinter As String
    Dim i As Integer
 
    For Each prtLoop In Application.Printers
        strListRowSource = strListRowSource + prtLoop.DeviceName + ";"
    Next prtLoop
 
    DefPrinter = Application.Printer.DeviceName
    lstPrinters.RowSource = strListRowSource
 
    i = lstPrinters.ListIndex
    lstPrinters.Selected(i) = True
End Sub
'
'
Private Sub lstPrinters_AfterUpdate()
  DefPrinter = lstPrinters
  SetDefaultPrinter DefPrinter
End Sub

I have run one of the modules today and the routine 'LoadPrintersListBox' caused Access to crash at the line For each prtLoop...... I have tested all the forms with this subroutine in and all crashed. Previously, no problem ever. Now the strangest thing of all. I have commented out the call line to the module everywhere, as I am doing some use case testing and ....wouldn't you guess ? The load call executes and fills up the box. Switching between printers works perfectly ! So, what is the problem ?

That's what I would like to know. I don't want to rely on miracles when delivering my programs. Does anyone have any idea what is going on ?

Actually, I have seen somethiong like this before: when I was rewriting misbehaving code, the deleted subs or functions were still present even though I deleted the source. Is there a way to clean up the code so there are no 'ghosts' short of discarding the form altogether ? Much obliged for any tips.

Best,
Jiri
 
I have been using a printer-selecting listbox without an incident for a number of months now. It is for Access printouts of Excel spreadsheets. So far no problems. The two routines below register local and network printers and select active printer among them:

Code:
Public DefPrinter As String
Public Declare Function SetDefaultPrinter Lib "winspool.drv" _
Alias "SetDefaultPrinterA" (ByVal pszPrinter As String) As Long
 
Private Sub LoadPrintersListBox()
    Dim prtLoop             As Printer
    Dim strListRowSource    As String
    Dim DefPrinter As String
    Dim i As Integer
 
    For Each prtLoop In Application.Printers
        strListRowSource = strListRowSource + prtLoop.DeviceName + ";"
    Next prtLoop
 
    DefPrinter = Application.Printer.DeviceName
    lstPrinters.RowSource = strListRowSource
 
    i = lstPrinters.ListIndex
    lstPrinters.Selected(i) = True
End Sub
'
'
Private Sub lstPrinters_AfterUpdate()
  DefPrinter = lstPrinters
  SetDefaultPrinter DefPrinter
End Sub

I have run one of the modules today and the routine 'LoadPrintersListBox' caused Access to crash at the line For each prtLoop...... I have tested all the forms with this subroutine in and all crashed. Previously, no problem ever. Now the strangest thing of all. I have commented out the call line to the module everywhere, as I am doing some use case testing and ....wouldn't you guess ? The load call executes and fills up the box. Switching between printers works perfectly ! So, what is the problem ?

That's what I would like to know. I don't want to rely on miracles when delivering my programs. Does anyone have any idea what is going on ?

Actually, I have seen somethiong like this before: when I was rewriting misbehaving code, the deleted subs or functions were still present even though I deleted the source. Is there a way to clean up the code so there are no 'ghosts' short of discarding the form altogether ? Much obliged for any tips.

Best,
Jiri

I have done some further testing and found out that any reference to application.printers, in code or in the immediate window crashes Access 2007. I have created a thread on the Access developpers' forum :
http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/fa015929-5221-41ee-afcc-5373b6f26c21

Pls, let me know if you have info on this. Thanks !

Best,
Jiri
 
I have done some further testing and found out that any reference to application.printers, in code or in the immediate window crashes Access 2007. I have created a thread on the Access developpers' forum :
http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/fa015929-5221-41ee-afcc-5373b6f26c21

Pls, let me know if you have info on this. Thanks !

Best,
Jiri

Both, mystery and problem solved. The mysterious appearance of the printer list happened because the existing Rowsource was being saved. How silly of me not realizing this. (I was thrown by the listbox value not showing during debug tracing in the onLoad event. It appeared first in onCurrent).

As the crashes were happening on tested code which runs well on other machines, and also whenever I touched "application.printers", I started to look at the printer drivers. I found the culprit. Sure enough, it was "PrintBoss 50" printer driver for cheque Micr printing which caused the trouble. Removing it from the list of printers restored the functionality of the Application property.

Ah well, learned something new. Didn't know much about printer drivers messing up Access. Hope this is useful info.

Best,
Jiri
 

Users who are viewing this thread

Back
Top Bottom