Working directory isn't working

[dunkers]

Slickedit 12.0.2.0.

I create a new workspace and project in directory x:/foo. In this project I make the working directory y:/bar. If I now try to add files to the project the browser opens in the project directory (x:/foo) rather than the working directory (y:/bar). Even after navigating to the right place, next time we're back to the project directory. You might imagine that a large project with longish paths is a right pain to deal with.

Slickedit 12.0.0.0 did this correctly and used the working directory to open files.

[hs2]

The 'Add File' dialog uses the current working directory as base directory.
You could 'cd' to the desired directory before adding new files.
BTW The file dialog should display the 'Change dir' checkbox and it has to be checked that the directory is changed when navigating to another location. If the checkbox is not shown is intentionally disabled.
In this case I can imagine that it's good to go back to the starting (root) directory (the current working dir) when adding new files/trees/wildcards to the project. But - as many other things - it depends

HS2

[dunkers]

Ah, I forgot about the CD thing, but then I've not needed to use it before. Thanks for reminding me

Today I started up the same project and file open, or adding project files, starts in the directory of the file I have open (just one). The CD tickbox is not ticked and I haven't changed that at all. Of course, this directory isn't the working directory either (but one of several sub-directories).

If I recall correctly, the CD tickbox produced varying results last time I tried it (many moons ago) and didn't get me where I wanted, so I stopped using it. The File | Change Directory menu item works temporarily but is easily forgotten.

 The working directory setting wasn't always adherred to either, but it was better than CD. It seems that it's completely ignored now.

[hs2]

I'm curious - do you see the 'Change Directory' tickbox when doing 'Add Files to Project' ?
I don't... (WXPSP2 - v12.02 r8)
BTW cd on cmdline without argument quickly tells you where you are.
HS2

[dunkers]

No, I don't see the CD box when adding files from the project dialogs. I just checked 12.0.0.0 and that's the same. I also noticed that the add files from the project dialog uses the directory of the file in the edit window! This is the same as 12.0.0.0, I just never noticed before.

Thinking about this, it seems that the directory used for file open/add is that of the currently edited file, and if that's missing (such as when the project is first set up) then the directory of the project file is used instead. The 'working directory' would be just for compiles and stuff, but since I rarely use SE to run a compile I've always taken it to mean the default directory. So it might be my expectation that's broken rather than the setting, but I sure wish it'd work like I expect it to (particularly since 12.0.0.0 seemed to much of the time)

Thanks for the command line tip. Amazing how long one can go without tripping over things like that!

[hs2]

I bet you're using 'set-var def_switchbuf_cd 1' which gives the impression that e.g the 'Add File to Project' dialog takes care about the current buffer. In fact it doesn't. Only the current working dir matters.
As you surely know this setting causes that your working dir follows the current buffer...
I'm using 'set-var def_switchbuf_cd 0' and if I do a 'cd <newdir>' and I'm adding a file to my curr. project afterwards the initial directory of the dialog is <newdir>.

Edit: This effect could be the explanation for the seemingly unreliable behavior of the 'Change Directory' feature in the file dialogs.

HS2

[dunkers]

I bet you're using 'set-var def_switchbuf_cd 1'

Apparently I am, although I don't recall setting it thus.

As you surely know

I surely didn't, but I do now

could be the explanation for the seemingly unreliable behavior

Good thinking. I'll try it at 0 for a bit and see if I'm less confused. Thanks++

[ScottW, VP of Dev]

I'm still trying to determine if there's a bug in here or not. Please let me know what you conclude so I can file a change request.

 

--Scott

[hs2]

No - it's not a bug - it's just 'crosstalk' between 2 features
If one selects 'Change dir' in a File dialog (does sth. useful there) and leaves it, the working dir is changed accordingly.
Now the curr. buffer (edit win) gets activated and if 'def_switchbuf_cd = 1' the working dir is imm. changed again to the directory where the buffer / file resides and maybe w/o getting noticed by the user.
Now if the file dialog is used again it starts in another (working) dir as expected due to the intermittent dir change caused by the buffer / edit win activation having def_switchbuf_cd set to '1' ...
A bit convoluted, right

HS2

[dunkers]

Yes, I think there is a bug. Whilst I concur with hs2 about the file open during normal use stuff, my original complaint was with the project add files/tree affair when first setting up a project, and even changing my CD setting hasn't fixed that.

To recap, when you come to add files to the project, the directory that the add/tree dialog opens into is the directory that holds the SE project files, not the directory with the source files. My feeling is that the specified working directory should be used here since that's saying where the source files are.

As I noted originally, 12.0.0.0 and earlier did it this way so 12.0.2.0 has broken this bit. I'd class that as a bug

For reference, I tend to have all (or most) SE project files in a single directory. Never do I put them in the source directory (which gets checked into source control and shared with other people).

[hs2]

@dunkers: Did you try to change the (working) dir using 'cd' on cmdline or the GUI version and add project files afterwards
with def_switchbuf_cd set to '0' ?. This is working for me and the dialog starts up in the desired directory.
I think the (non-obvious) issue with adding project files is that SE opens the <project>.vpj file for modification in an internal buffer and with def_switchbuf_cd set to '1' it also causes that your working dir changes to the dir where the <project.vpj file resides...

I wouldn't force the dialog's initial directory to the specifed project root. That could be fine for well-structured projects located in a hierarchical directory tree but there are projects where the files are spread over the filesystem.
Also for projects with a clean hierarchy but with deeply nested sub-dirs it might not be helpful if the dialog flips back to the project root everytime it's opened.
Though it might be helpful if a new project is created and the <project>.vpj is not located in the project root. But that's done once and helps only a bit when starting to add files. But maybe I miss some points here...
However, I think the current implementation is almost fine and doesn't apply any (unwanted) restrictions.
And it's also more transparent if the file dialogs always refer to the current work directory.
Almost fine ? I find it useful to have the 'Change dir' checkbox visible also for this dialog. Why not ?

HS2

PS: I'm using this small cmdline helpers to make life a bit easier.
'cdb' changes dir of the current buffer and 'cdp' to the current project dir (needed to attach them b/c the forum SW can't handle it inlined)

[dunkers]

Did you try to change the (working) dir using 'cd' on cmdline

No, because that kind of defeats the object of having a GUI and working directory setting

with def_switchbuf_cd set to '0'

Yes, this is with def_switchbuf_cd set to '0'. That has affected the normal file open which now remains at the project (source files) root if I don't elect to tick the CD box. That's great.

I wouldn't force the dialog's initial directory to the specifed project root.

The directory is going to be set to something, so the working directory would seem the logical choice. If it happens that this directory is far away from source then the SE project directory is likely to be too.

If the directory chosen was remembered (recall, it has the CD tickbox missing) then it wouldn't be so aggavating, but having to re-browse a lengthy path for every source directory is enough to make one want to post a bug report

I think the current implementation is almost fine

Sorry, but it is not fine. I still have SE 12.0.0.0 installed and have taken to using that to set up new projects (which I then edit with SE 12.0.2.0) because of this change of functionality (aka bug). You can't get more damning that that.

[hs2]

If the directory chosen was remembered (recall, it has the CD tickbox missing) then it wouldn't be so aggavating, but having to re-browse a lengthy path for every source directory

That's the reason for 'cdp'

Want the CD' tickbox in v12.02 r10 NOW ?
project.e - _add.lbutton_up() [line 4790]:

Code: [Select]

                      // HS2-CHG:   OFN_NOCHANGEDIR commented - maybe I want to come back to add files near this (curr.) dir
                      // OFN_NOCHANGEDIR|OFN_FILEMUSTEXIST|OFN_ALLOWMULTISELECT|OFN_SET_LAST_WILDCARDS,
                      OFN_FILEMUSTEXIST|OFN_ALLOWMULTISELECT|OFN_SET_LAST_WILDCARDS,

HS2

[dunkers]

Ah, thanks for that

But I'm still convinced it's a bug and needs fixing - what was so bad about the original feature that it had to be changed? Nothing, it just got broken, so far as I can see.

[Lee]

I've just tested your scenario on several different versions dating back to 10.0.3, and so far I have not found any change in behavior in any version.  They've pretty much all work the same.  For testing, I started with a default config, and used CUA emulation with no changes.  I created two seperate file trees with projects in one and source in the other, c:\projects, and w:\source and set the working directory for the project (Project > Project Properties... > Directories  > Working Directory) to W:\source.  Now, depending on how you got to Project Properties does change the behavior for the initial directory for Add Files/Add Tree:

(main menu) Project > Project Properties... > Files > Add File, the initial directory would be the current directory SlickEdit (cd on the cmdline).  So if I was in c:\temp, the initial directory would be c:\temp.

(cmdline) project-edit, ditto.

(right-click on project in Project Tool window) Add Files... or Project Properties... > Add Files, the initial directory would be set to the project directory (the location of the vpj file). 

The source for project-edit (macros\project.e; line 196-ish)  command confirms that this is done deliberately, and it has worked that way pretty much since at least v7 from what I can tell, maybe earlier.  I'm sure it was originally added on behalf of a feature request for people with multiple project files, but I'd have to go way back in the feature tracker to find when it was requested and why it was done that way.

Please double-check and confirm that your setup is working the same as I've described above.  In none of the cases above was the current projects Working Directory ever used as the initial starting directory when adding files.  As everyone has a different workflows and project hierarchies, no matter what we set the initial directory to in Add Files/Tree, someone is going to have a differing opinion on how it should work.   I've spoken with both Clark and Scott about it, and we don't see it as bug as it's currently implemented.  Now whether we should change the existing behavior, that is another story.  If somebody makes a strong enough argument, we can consider making the appropriate changes.