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|Eme rgency 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.lpstrF ileTitle)
pathname = StripNulls(OpenFile.lpstrF ile)
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!)
Currently I use this to open my dialog box:
With CommonDialog1
FilterHolder = "ESLS-E.CSV|ESLS-E.CSV|Eme
.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.lpstrF
pathname = StripNulls(OpenFile.lpstrF
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!)
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|Eme rgency 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!
With CommonDialog1
FilterHolder = "ESLS-E.CSV|ESLS-E.CSV|Eme
.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!
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.
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
Or are just copying the executable around?
Regards, P1
ASKER
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
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
ASKER
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.
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
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
ASKER
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?
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
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
P1... please check this post for your points:
https://www.experts-exchange.com/questions/20570436/Points-for-P1.html
https://www.experts-exchange.com/questions/20570436/Points-for-P1.html
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