Common Dialog Initial Directory

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:02
Joined
Feb 28, 2001
Messages
30,088
Hi, group. I've been up to my a** in alligators down here in the South Louisiana bayous and haven't been visiting for a while, but now I have to come back because now I have a problem. I have searched the forum on this topic but not found an answer. It is, of course, possible that I am asking the wrong question in my search, but so far, no joy has resulted from anything I've sought.

In AC97, I use the ComDlg32.OCX module to activate the common dialog box. I use the OpenFile method to find a file that will be opened for analysis. The details of the analysis are unimportant for the problem. Once I find the file, everything else works just right, no headaches there.

The files for this analysis function are kept in a fixed staging area on a networked drive about 99% of the time, though it is certainly possible to browse anywhere on the local or network drives to find your input. Therefore, it would make sense to force the OpenFile dialog box to show its opening view as the folder where most of the files are kept. But it does not. It always shows me the Access initial directory.

Other file-based functions exist that would use different folders, so I don't want to make the Access default directory equal to this staging area for all functions. I have tried to use the .InitDir property of the common dialog object, but it seems to ignore this setting. I tried using the ChDir function before calling the browser box, but also no joy.

Of course, once the browser box has been used to find the first file to be analyzed, all subsequent calls point to the right place until I close the form in question. But I would really like for the first OPEN to also point to that directory / folder.

The Help Text for the Common Dialog functions include a reference to a "New Search" (such as would be part of the Applications .FileSearch object), but I can't find the flag or method for that function in the object browser. Therefore, I cannot set it to override the initial directory.

Has anyone deciphered the ComDlg32 vagaries to allow this file folder pre-selection process to work the first time around? My users can be told where to look, but from an aesthetic viewpoint (and an ease-of-operation viewpoint), it would be far more preferable to just plunk them down in the right place right away.

Any takers?
 
Having built a sample in both pure VB and Access VBA, I cannot replicate the situation, I have tried:

Private Sub Command1_Click()
Cmdlg.InitDir = "D:\"
Cmdlg.ShowOpen
End Sub

which works. I have also hard set the InitDir in the properties tab which also responds the same.(D:\ is not my default directory btw)

Sorry.
 
Fornation, I appreciate the attempt. I have no idea what I managed to do, but whatever I did, I did it well.

I'll hang on a while to see if anyone else has seen a problem like this.

BTW, my code fragment in AC97 looks like

Code:
' ... generate path into stDfltPath

BrowseBox.Object.DefaultExt = ".DOC"
BrowseBox.Object.InitDir = stDfltPath
BrowseBox.Object.Flags = {a bunch of flags}
BrowseBox.ShowOpen

I don't recall offhand why it requires the .Object. in the middle of that code segment, but I recall that it didn't work right without it.
 
National Security aside, if you can break off the bit of code and sample form you use and mail it to me here formatian@aol.com, I'll see if it works on my PC, then we'll know what's going on.
 
I use the API to open the common dialog so I'm not sure if that makes a difference but this is the line of code that I use to set the initial directory:

MyOpenFile.lpstrInitialDir = "C:\Data"
 
Fornation, unfortunately the code is SO complex that it would take a while for me to slice out the module, which is called by an event routine. Thanks for the offer, but I can't put security aside from this workstation. It goes through a network monitoring system that would probably have kittens if I sent out anything that looked like e-mail to a foreign address.

Here is the summary of what is going on

User clicks [Browse] button - I find the file through ComDlg32 and assure that it exists and isn't empty.

User clicks the [Evaluate] button - A HUGE subroutine gets called to read the document, look in key places for key data, load up a temporary holding array for 300-500 elements. The data set is "sparse" and some of the elements are place-markers, not live data. The net result is to grab maybe 80-100 non-zero, non-constant values for importation into several tables with multiple relationships. Evaluation status and data summaries are displayed automatically.

User clicks [ViewScan] to get detailed error/edit messages if there is any question about data validity.

User has the option of clicking [EraseIt] right away, or [ImportIt] followed by [EraseIt].

In either case, when the user erases the control form (which is unbound to anything at all), it is possible to start the Browse-Evaluate-Import-Erase cycle again and again. The problem only occurs on the first Browse, not subsequent Browse calls, so it is NOT a super high priority thing. It is more of an annoyance than anything else.

Pat, I don't have a property like that because I don't use the API. In the OCX, you are supposed to use .InitDir, which is probably the corresponding property. But it seems to ignore me when I set that value. Kind of a bummer, actually.
 
Can you accept incoming mails from unidentfiied sources?
Could I post my example here to see if it works on your PC?
 
Thanks for the offer, Fornation, but this problem is too minor a deal. I was mostly hoping that someone had run into it before and had a handy answer. But, alas, that appears to not be my destiny with this problem. Ah, well.

I'll just have to warn my users that the problem isn't fixed yet. Considering everyone's work load here, they'll understand that I just haven't slogged my way through it yet. I've got other, higher priority fish to fry and they know it. (They are the ones who asked for the fried fish in the first place.)
 
I too am having trouble with the OCX.

Pat, can you provide guidance for using the API?
 
This is the article I got the code from:

ACC97: How to Use the Common Dialog API in an Access Database (Q303066)
 
Thanks for the reference, Pat. Much as I was hoping to avoid this step, I might just have to do this. My other maintainers are VERY junior and don't have the programming background that I do. Anything that involves API calls gives them shivers. But what the hey, they have to learn sometimes I guess.
 

Users who are viewing this thread

Back
Top Bottom