Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / February 2005

Tip: Looking for answers? Try searching our database.

Common Dialog in Access 2000

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
deko - 25 Feb 2005 13:33 GMT
What is the best way to get a Common Dialog in Access 2000 Standard Edition?

Microsoft suggests this:

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
End Type

(See: http://support.microsoft.com/default.aspx?scid=kb;en-us;303066)

In Access 2003 I was using this:

Private Sub Browse(strTag As String)
   Dim dDialog As Office.FileDialog
   Dim varDir As Variant
   Set dDialog = Application.FileDialog(msoFileDialogFolderPicker)
   dDialog.AllowMultiSelect = False
   dDialog.Title = " Select Directory"
   If dDialog.Show = True Then
       For Each varDir In dDialog.SelectedItems
           Me!txtPath = varDir
       Next
   End If
End Sub

Do I need MS's private function?

Thanks in advance.
Wayne Morgan - 25 Feb 2005 15:14 GMT
You will also find an example for that here:
http://www.mvps.org/access/api/api0001.htm

The advantage of the longer method is that it calls the Windows API and so
should always work. Calling the Office Dialog could cause a problem if you
have mixed versions of Office. As you may have noticed, in order to get the
Office Dialog to work you had to set a reference to "Microsoft Office 11.0
Object Library". This is version specific. Moving up a version usually isn't
a problem, but if you try to open your file on an older version of Access
that supports your file format, this is likely to break and you'll have to
go into the references dialog to manually set it to the older library. Also,
if you are creating MDE files, you'll have to reset this for the version of
Access the MDE is going to be created in, before creating the MDE. This is
one of the reasons and MDE has to be created on the same version of Access
that it is going to be run on.

Signature

Wayne Morgan
MS Access MVP

> What is the best way to get a Common Dialog in Access 2000 Standard
> Edition?
[quoted text clipped - 47 lines]
>
> Thanks in advance.
DFS - 25 Feb 2005 15:21 GMT
> You will also find an example for that here:
> http://www.mvps.org/access/api/api0001.htm
[quoted text clipped - 10 lines]
> you are creating MDE files, you'll have to reset this for the version
> of Access the MDE is going to be created in, before creating the MDE.

> This is one of the reasons and MDE has to be created on the same
> version of Access that it is going to be run on.

Doesn't have to be.  I created and delivered an Access 2000 .mde that ran
fine on Access 2003 when my clients upgraded.

>> What is the best way to get a Common Dialog in Access 2000 Standard
>> Edition?
[quoted text clipped - 47 lines]
>>
>> Thanks in advance.
Wayne Morgan - 25 Feb 2005 18:32 GMT
Thanks, again though you were moving up to a newer version. Also, were you
using the runtime version of Access or the full version on the clients'
machines?

Signature

Wayne Morgan
MS Access MVP

> Doesn't have to be.  I created and delivered an Access 2000 .mde that ran
> fine on Access 2003 when my clients upgraded.
DFS - 26 Feb 2005 02:17 GMT
> Thanks, again though you were moving up to a newer version. Also,
> were you using the runtime version of Access or the full version on
> the clients' machines?

Full version.  In fact, I believe the default file format is Access 2000
when Access 2003 is installed.  I know I've seen that on several machines.
Maybe that's only upgrades?

>> Doesn't have to be.  I created and delivered an Access 2000 .mde
>> that ran fine on Access 2003 when my clients upgraded.
Wayne Morgan - 26 Feb 2005 16:49 GMT
You're correct about the default file version, it is the 2000 file version
for Access 2000, 2002, and 2003. I believe that the problem comes in with
the "Microsoft Access x.x Object Library" and the runtime version. The
runtime is more restrictive in what it will let you do and I suspect that it
won't let the object library reference upgrade itself. I would have to
reinstall the older version to test this though. It should be testable by
creating and MDE in Access 2000 and opening it with Access 2003 using the
/runtime switch.

Signature

Wayne Morgan
MS Access MVP

> Full version.  In fact, I believe the default file format is Access 2000
> when Access 2003 is installed.  I know I've seen that on several machines.
> Maybe that's only upgrades?
Tim Marshall - 25 Feb 2005 15:56 GMT
> You will also find an example for that here:
> http://www.mvps.org/access/api/api0001.htm
>
> The advantage of the longer method is that it calls the Windows API and so
> should always work.

Indeed it does.  I used the above code in Access 97 and it ported to
Access 2003 with no difficulty whatsoever, no changes or tweaking required.
Signature

Tim   http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

deko - 26 Feb 2005 05:30 GMT
> The advantage of the longer method is that it calls the Windows API and so
> should always work. Calling the Office Dialog could cause a problem if you
[quoted text clipped - 8 lines]
> one of the reasons and MDE has to be created on the same version of Access
> that it is going to be run on.

I think the Office Dialog is clearly better.  Sort of like .NET - if MS
wants to abstract the API and make it easier for me, great.  The more
productive and less arcane this business is the happier I am.  But from a
manager's perspective, the API is clearly a better solution.  I guess it
depends on how much control you have over your environment (which is usually
not much).

As an aside, you mention that "Moving up a version usually isn't a
problem..."  I assume this the case for other references as well - e.g.
Excel, Internet Controls, Scripting Runtime.  I'm thinking about my early
bound automation code and know from experience the unpredictable results
caused by broken references.
Wayne Morgan - 26 Feb 2005 16:54 GMT
Yes, I've run across this with Excel also. I can take a '97 Excel spread
sheet to a machine with Excel 2003 installed. If I open the spreadsheet on
that machine then take it back to the machine with Excel 97, the code will
error out until I reset the object libraries to the '97 versions. The DAO
library usually stays put (the newer machine has the old library available),
it's the Excel library that is usually the problem.

Signature

Wayne Morgan
MS Access MVP

> As an aside, you mention that "Moving up a version usually isn't a
> problem..."  I assume this the case for other references as well - e.g.
> Excel, Internet Controls, Scripting Runtime.  I'm thinking about my early
> bound automation code and know from experience the unpredictable results
> caused by broken references.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.