I had this issue in 0.9.14 and never could resolve it, so I was excited to see the release of 0.9.15. The issue doesn’t seem to be resolved for me, though.
The issue is, ever since updating to 0.9.14 the directory memory has quit working. What I mean is that prior to that release, when I clicked to import a file, it went to my desktop (where I keep temporary files). When I saved a file, it automatically chose my Lightburn folder on my secondary drive. Basically, each file access option remembered the last directory it used, and they remembered independently. Now, each option uses the last accessed directory for the application. Meaning, I open a file from my Lightburn folder and then try to import a file, but the file import goes to the Lightburn folder instead of the desktop, which is the last place I imported a file from.
I know it isn’t a critical issue, but it sure does save a lot of time to not have to constantly change directories. Is there a setting somewhere that I’m not finding that controls this behavior?
There are no controls for this kind of thing - it’s supposed to just do this for everyone, all the time. Is there anything special about the places you’re saving to? Networked, OneDrive, DropBox synced, anything like that? Any weird characters in the name of the path?
The 0.9.14 and 0.9.15 releases both use a new ‘under the hood’ thing designed to prevent crashing when you have thumbnail viewers that were written using the same framework as LightBurn, but different versions. It’s feasible that this tool is somehow not getting or respecting the folder paths it’s given, but I can’t think of why it would work for nearly everyone. It’s a pretty dirt simple thing.
Try this: In LightBurn, go to Help > Generate Support Data, then paste what it gives you in a reply here. I can have a look at your prefs to see if I can spot anything weird in the paths.
None at all, I’m afraid. I looked through your settings info and saw nothing out of the ordinary. I have no idea whatsoever why this is happening.
Try this:
Browse to the LightBurn program folder.
Rename LBFileDialog.exe to LBFileDialog.exe.backup
See if it remembers paths now.
If it does, it points at that mini-app either not respecting the path it’s given to start in, or the path value not being passed to it correctly. It’d be a place for me to start looking. I can’t think of any reason this would be failing just for you though.
Oz, I just tried the same import then save as the OP, and it performs as he states. ie only uses one path for import and save.
If I rename the LBFileDialog.exe as you suggested then the import and save paths are kept separate
That executable is actually the file dialog you see then you open, save, etc. Technically, it’s just calling a Windows OS function to display it.
There are some companies (notably Dell Computers) that ship with tools built using the same framework that we build LightBurn with. In the case of Dell, they have a thumbnail / preview provider for their backup tool written using that framework, but a different version. When you go to open a file window, it opens all the file previewers to provide the thumbnails, and that one tries to load the libraries it uses, sees that they’re already loaded (because of LightBurn) and tries to access them. Since they’re the wrong version, and some stuff has changed, it fails, it dies, and takes LightBurn with it because it’s all in the same process space.
The LBFileDialog was built not using the framework we build LightBurn on, so it doesn’t have this conflict. We write all the information necessary to display it into a temporary text file, then launch that little app with the path to that file as an argument. It reads all the options, sets up the window, lets you browse for the filename, then closes, returning the filename back through that temporary text file. If something does crash it, it won’t take LightBurn with it, because it’s a distinct application.
So, it likely won’t hurt to remove it, but I’d really like to figure out why it’s not working for some people. I’ll keep poking.
So this is apparently another way Windows is an idiot (and I’m not far behind). If you tell Windows to use an initial path that contains /'s instead of \'s as the path separator, it fails, and falls back to whatever the last folder was that you used.