Keeping track of dlg.InitialDirectory

General
1

I’ve spent more than an hour on this and done enough reading. I’m stumped. Surely this must be programming 101? - perhaps I’m stumbling with a certain method or syntax.

I have File Open and File Import

On File Open, the user is pointed to the folder that contains previously saved files ready to open:

dlg.InitialDirectory = SpecialFolder.ApplicationData.Child(myAppDataFilesFolder)

All good - this works as expected.

When “importing” files, AND on application startup, the program points the user to a default position:

dlg.InitialDirectory = SpecialFolder.Desktop

From then on, if the user wants to import files, then my program should take them the last directory/folder that they have imported a file from.

It seems by default the OS always takes you back to the last folder you were at anyway, which makes sense. So, I almost need do nothing. BUT if the user opens a file first, then wants to import a file - the last directory/folder will be the “open file” directory/folder.

This is what needs to happen:
When the user imports a file, then the next time they import a file they should end up in that same location. regardless of what directory or folder they were previously in. [EDIT] Sorry, that almost doesn’t make sense. I mean “Open File” changes to a set location, but “Import” should always return to the last import location.

I’ve tried creating a variable importedFileCurrentFolder then assigning that to f.NativePath and also f.AbsolutePath thinking that I would get the “path” but I not only get the path but also the filename.

Help appreciated. Cheers.

2

importedFileCurrentFolder = f.parent.nativepath

3

Thanks muchly Dave - I will have to check it out tomorrow.

It’s almost midnight here. After a long Sunday of coding, culminating in a few beers, I need to keep myself away from my code.

When I get home from work tomorrow it will be the first thing I do. Looks good.

Cheers.

4

Please note that Windows has some special behavior regarding this.
It’s been explained in this post.

5

Well it wasn’t easy for me to implement, but I seems to be working correctly. This is what I ended up with:

On app start:

importedFileCurrentFolder = ""
On import file:

Dim dlg As New OpenDialog
Dim f As FolderItem
 
  If importedFileCurrentFolder = "" Then
    dlg.InitialDirectory = SpecialFolder.Desktop // set initial directory
  Else
    dlg.InitialDirectory = GetFolderItem(importedFileCurrentFolder) // set current import directory
  End If
  
  f = dlg.ShowModal
  
  If f <> Nil Then . . . do some code.

importedFileCurrentFolder = f.Parent.NativePath //reset to the last working location for next file import

@ Jürg Otter
Thanks, I’ll have to check that out.

Cheers.

6

That was exactly what I was suggesting… but I figured it would be a better learning experience if you fleshed it out yourself :slight_smile:

7

Well Dave, that’s exactly what I thought as well :stuck_out_tongue: It took me about 2hs to get there, and I didn’t want to ask on this forum unless I had to.

The FolderItem class of objects is complicated and hard for me to comprehend. There are aspects that I can grasp, but if I go back to it in a months time or so, then I almost have to start over again. btw. I’m not saying I’m necessarily stupid, it’s just that I only work on this a couple of hours a day (if that) as a hobby.

My approach to software programming is the same as it’s always been:
Do some reading, try it out, if it doesn’t work, then repeat. Basic trial and error. Someone wrote something similar on this forum a while back. I do try to understand how, and mostly that is the case, but sometimes I just move on.

The problem with my trial and error approach is that sometimes there can be an issue later on in the program like “all because it works “now” doesn’t mean to say it won’t conflict with something else down the track”.

Therefore, can I please ask if this is what you or anyone else considers to be the standard.

dlg.InitialDirectory = GetFolderItem(importedFileCurrentFolder)

GetFolderItem is the key here, but are there other approaches to this solution?

At the moment this works perfectly :slight_smile:

Cheers.

8

Examples in the LR are your friends. I cannot recall the number of times I built big portions of my programs with them, sometimes hardly modified.

The problem with programming, though, is to have the clearest view as possible of what you want to achieve, before starting to code. Analysis of the program must come before coding. Otherwise you lose sight of the goal, and get lost in ancillary problems.

Finally, don’t get stuck for too long when you have people willing to help in this forum. Try to explain as clearly as possible what you want to achieve, and generally you will get the answer very quickly.

9

Thanks Michel.

One positive thing I do have is an absolute clear direction of what my software should do. This is an updated version of software I wrote using basic many years ago.

I have to say that when I discovered Xojo and looked at the possibilities, then I jumped straight in and have been developing whilst learning at the same time. I know I haven’t done things the “right way” but I’m learning.

I’m still enjoying the process. I enjoy solving problems (in this case programming & algorithms). It’s nice to have a good set of tools and use them to create a solution.