error '438' Object doesn't support this property or method when deploy access applicatioon on client machine

Hi,

I have developed an access application. This application consists of form, queries, table, modules (VBA).
The access application run well in my machine (windows XP profesional). However when I deploy this access application to client machine (windows 2000 profesional), i found this error when user try to click on the 'browse' button.
"error '438' Object doesn't support this property or method"

This is the code for the browse event:
Private Sub cmdBrowse_Click()
 Dim strNewFile As String
   On Error GoTo Browse_Err
   With Me.cdlgOpen
      InitDir = "C:\MyDocuments\"
      .CancelError = True
      .Filter = "Excel Files (*.xls)|*.xls|"   'Can change (i.e. "Word Files (*.doc)|*.doc|") or ("All Files (*.*)|*.*|") see help for other examples
      .ShowOpen   ' Can use showSave for saving file, same principle
      strNewFile = .Filename
      txtFilePath.value = strNewFile
   End With
                             
Browse_Exit:
   Exit Sub

Browse_Err:
   If Err.Number = 32755 Then
      Resume Browse_Exit
   Else
      MsgBox Err.Number & ": " & Err.Description
      Resume Browse_Exit
   End If

End Sub

How can I solve this problem? thanks!

linnyphangAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

bossjohncCommented:
If this code works on some machines and not others, then you may want to make sure the MDAC versions are sufficiently recent/compatible on both machines.

You can download MDACs here...

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/dataaccess.asp

You can use componentchecker to identify incompatible MDAC files and the current version of the MDAC - it's available here...

http://support.microsoft.com/default.aspx?kbid=307255

where there is lots of other useful info on the subject.

This might not be your problem, but I suspect it may be.
0
nmcdermaidCommented:
You will proabbly find that the version of common dialog (it looks like you're using it) is different between machines.

Common dialog is in COMDLG32.OCX.. check the version of this file between machines.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
stevbeCommented:
using the straight api code for the file dialog box avoids the dll nonsense you are experiencing...

http://www.mvps.org/access/api/api0001.htm

Steve
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

linnyphangAuthor Commented:
I deploy the application again by include COMDLG32.OCX in my deployment package.
I install this package on client machine. It works!

However, it wont works if i manually copy this COMDLG32.OCX directly to clinet machine (c:\winnt\system32\)

Thanks a lot for you comments!
0
nmcdermaidCommented:
It's good to have a solution but just be wary about deploying DLL's as unfortunately they are 'common' libraries that other applications use and if you copy on one vesion when all the applications are expecting another version, all hell breaks lose!

As far as copying the files on, you usually also need to register them using REGSVR32

0
stevbeCommented:
"It's good to have a solution but just be wary about deploying DLL's as unfortunately they are 'common' libraries" ...

that is why I always use the api code instead of the control, I never have to worry about it.
0
nmcdermaidCommented:
The API code references COMDLG32.DLL instead of COMDLG32.OCX, so there isn't that much difference.

0
stevbeCommented:
the difference is that I do not have to worry about presence or installation of the .ocx :-)
0
nmcdermaidCommented:
True, but what I mean is, OCX or DLL, it doesn't matter, they are both common libraries. If you can get a version problem on the OCX (as in this case), you can get a version problem on the DLL. :-). We won't know in this case unless bossjohnc wants to try your code. I would be interested to find out.

Certainly as far as Access goes, using API's are far more reliable than ticking things in the References or Components list. In fact it might be a good  habit for me to start using if it stops that annoying 'Reference not found' problem.







0
bossjohncCommented:
No, not me! I'm not the original author - however from my understanding, if you use the API (DLL), it doesn't matter what version it is, as Windows deals with it rather than Access. For example, with the file dialogue API, depending on the version, the dialogue may look different (depending on the version), but the result passed back to Access won't differ.

I have a fairly basic understanding so I might be wrong of course : )
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.