Link to home
Start Free TrialLog in
Avatar of TinLemon
TinLemon

asked on

Run-time '53' error when using Common Dialog open function....

What I am doing is opening the Common Dialog "Open File.." (Commondialog1.showopen) so I can select a file for import.  This works PERFECT on my computer, so I created the setup file using the Package and Development Wizard for someone else to install the program on their computer.  They run the program and all is well until they want to import a file (ie. this procedure is initated), then it pops up the "Run-time '53' error: file not found" .  It doesn't even open the dialog box.  I have the opening directory set to "C:\", so I know it's not trying to look into a non-existant directory.  

Currently I use this to open my dialog box:
With CommonDialog1
        FilterHolder = "ESLS-E.CSV|ESLS-E.CSV|Emergency Locator Data File(*.csv)|*.csv|All Files(*.*)|*.*"
        .Filter = FilterHolder
        .FilterIndex = 1
        .InitDir = "C:\"
        .ShowOpen
        filename = .FileTitle  'for my use later in the program
        pathname = .filename   'for my use later in the program

End With


I also searched on the microsoft website and found a more code driven procedure which also works perfectly on my computer, but fails on my co-workers computer.  It accomplishes the same task, but in code looks like this:

Option Explicit
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias _
         "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long

Private Type OPENFILENAME
  lStructSize As Long
  hwndOwner As Long
  hInstance As Long
  lpstrFilter As String
  lpstrCustomFilter As String
  nMaxCustFilter As Long
  nFilterIndex As Long
  lpstrFile As String
  nMaxFile As Long
  lpstrFileTitle As String
  nMaxFileTitle As Long
  lpstrInitialDir As String
  lpstrTitle As String
  flags As Long
  nFileOffset As Integer
  nFileExtension As Integer
  lpstrDefExt As String
  lCustData As Long
  lpfnHook As Long
  lpTemplateName As String

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This part is placed within a command, such as a button click.

         Dim OpenFile As OPENFILENAME
         Dim lReturn As Long
         Dim sFilter As String
         OpenFile.lStructSize = Len(OpenFile)
         OpenFile.hwndOwner = UpdateData.hWnd
         OpenFile.hInstance = App.hInstance
         sFilter = "ESLS-E.CSV" & Chr(0) & "ESLS-E.CSV" & Chr(0)
         OpenFile.lpstrFilter = sFilter
         OpenFile.nFilterIndex = 1
         OpenFile.lpstrFile = String(257, 0)
         OpenFile.nMaxFile = Len(OpenFile.lpstrFile) - 1
         OpenFile.lpstrFileTitle = OpenFile.lpstrFile
         OpenFile.nMaxFileTitle = OpenFile.nMaxFile
         OpenFile.lpstrInitialDir = "C:\"
         OpenFile.lpstrTitle = "Update Files"
         OpenFile.flags = 0
         lReturn = GetOpenFileName(OpenFile)
         If lReturn = 0 Then
            MsgBox "Update Cancelled"
         Else
            filename = StripNulls(OpenFile.lpstrFileTitle)
            pathname = StripNulls(OpenFile.lpstrFile)
            frmBusy.Show
            ImportData
         End If

Function StripNulls(OriginalStr As String) As String
   If (InStr(OriginalStr, Chr(0)) > 0) Then
       OriginalStr = Left(OriginalStr, InStr(OriginalStr, Chr(0)) - 1)
   End If
   StripNulls = OriginalStr
End Function



If I can get either set of code to work, I will be in good shape.  Thanks for your help!

(PS-I'd offer more points, but this is all I have!)
Avatar of P1
P1
Flag of United States of America image

May I suggest that the file error may not be related to the control, but to another piece of code in your program.

Insert some error control code into the program to get a better understanding of what is coded.  ( Preferred )

Or simple stick some MsgBox statements to help narrow down the search.  ( Quick and Dirty )

Regards,  P1
Avatar of supunr
supunr

OK, make sure that the commondialog control has been correctly copied to the users computer (i.e. include the comdlg32.ocx (v6.0.84.13)).  That could be one reason why it is failing.  Also, update your code below to handle cancel press.

With CommonDialog1
       FilterHolder = "ESLS-E.CSV|ESLS-E.CSV|Emergency Locator Data File(*.csv)|*.csv|All Files(*.*)|*.*"
       .Filter = FilterHolder
       .FilterIndex = 1
       .InitDir = "C:\"
       .CancelErr= true
       On error resume next
       .ShowOpen
       if (Err.Number = cdlCancel) then
           exit sub ' cancel button is pressed
       elseif (Err.number <> 0) then
           msgbox "Err occured!" & vbcrlf & err.number & ": " & err.description
           exit sub
       end if
       filename = .FileTitle  'for my use later in the program
       pathname = .filename   'for my use later in the program

End With


' Good Luck!
Avatar of TinLemon

ASKER

Supunr, I have come across this article already but it didn't really help me resolve the issue.  I checked the files on both computers and they are located in the same directory on each.  My understanding is that the benefit of using the common dialog is that the .ocx file resides on every windows based machine already, so it doesn't require the file.  In any case, the setup file installs it if needed.

Regarding versions of this file, I haven't checked, BUT.. they are company computers that are imaged all the same.  It is my belief before checking that they should have the same version of the .dll file.
Has a client install been performed on the target machine?
Or are just copying the executable around?

Regards,  P1
The setup.exe procedure has been run on both my computer, and the other users PC.  The program works fine on mine, and not on the other still.

Time to pin down the error to the exact spot!  Add line numbers to key lines for quicker analysis.
Here is some error control code,  P1

Global Const EC_On = True     'Permits interactive IDE debugging.  True = Error Control 'ON' for app.  False = Local error handling for debugging.

'Insert @ Start of Sub or Function
If EC_On Then On Error GoTo My_Sub_Error_Routine

'Your Code.


'Insert above End Sub / Function
Exit Sub    'Change to 'Exit Function' for Functions.
My_Sub_Error_Routine:

'Yes, I used line numbers to speed up error detection.
    MsgBox "  Description = " & Err.Description & vbCrLf & " Error Number = " & Str(Err.Number) & vbCrLf & "       Source = " & Err.Source & vbCrLf & "          DLL = " & Str(Err.LastDllError) & vbCrLf & "          Erl = " & Str(Erl) & vbCrLf & "Additional Information", vbCritical

A few questions before I put this code in:

1) will it work if the program is run from a compiled state?  The error is on the other persons computer, so I have to send an .exe to them each time.

2) You mentioned that this finds errors by line #.  Is there a way to show line numbers so once I do find the line this error is on, I can go to it faster than if I were to just count the lines by hand.

3)  Should this code go into every Sub or Function in question?

Thanks.
Answers:
1) Yes. Yes, you must update the exe on the client machine after recompiling.  I use a network based updating module for this, but that is another topic.

2) Because this is a left 'as is' feature from the older VB's, you will need to number VB code by hand.  I have not the time to write an add-in for this yet.

3) At this point, No.  Just the functions and Subs doing file handling.  I work on a large VB ERP system.  So I have this in just about all my code.  For rapid deployment of updates from Error discovery.

Just remember, these are recommendations, you as the person in charge must evaluate if they are going to be meaningful to your situation.

Behind the advice is a programming methodolgy for developing High Class Apps with easy to use VB RAD techniques.

Regards,  P1
Ok... I just resolved the issue.  I was stepping through the working code line by line when I saw the problem.  It was not the Open Dialog box that was the problem, it was in fact this stupid .mov file (file flying from one folder to another) that was being referenced incorrectly.  I commented that piece of the code out and it worked perfectly on the other users computer.

How do we score this now?
Well ....

I was the one to first suggest that it was NOT the control, but other related code.

Experience, it's a 20/20 hind sight tool.

Regards,  P1
ASKER CERTIFIED SOLUTION
Avatar of modulo
modulo

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
P1... please check this post for your points:

https://www.experts-exchange.com/questions/20570436/Points-for-P1.html