activate-files doesn't show path in windows version

[Jim Emerson]

The activate-files dialogue does not show the path of the files. This is an issue where you have two files in a project/workspace with the same name.

The OSX version does show the path of files.

[chrisant]

There are two columns.  The first column shows the filename, the second column shows the path.  Maybe your first column is so wide that you can't see the second column?

Or I prefer to use the EnhProj macro as a replacement for both the Open File dialog and the Files toolbar.  Check out the screen shot there to see what it looks like (go to the end of the thread for latest version).

[Jim Emerson]

Thanks for the reply. It's not the path column size, there is plenty of room there. Actually, if I switch to the 'open files' view, the paths are there but going to project and workspace views, the path is just empty.

I did download and get the EnhProj going so that'll work for me.

Thanks again.

[livingintown]

it's a very annoying bug, I often open lots of files (>20), and depending on activate-files command (I binded it to \be in vim command mode) to pick up one from list, but path shows nothing in this version.

still get no fixed!

Dan

[ScottW, VP of Dev]

I'm not able to reproduce this problem. Can you post a screenshot so we can see what's going on?

[livingintown]

here is. You can see the path column shows nothing on it.



Dan

[Dan]

What platform are you on?  It looked from the screen shot like you might be using unix, so I tried under linux but still could not reproduce it.

Does it do it to every file?

Do these files exist on disk?

Are the files local?

[chrisant]

I don't know if it's related, but whenever I see ".." in a File or Path column in SlickEdit, it seems to mean that SlickEdit is truncating the text because it doesn't fit.  I saw this just now in the File column in the Find Symbol toolbar, and I can make the column wider and eventually a very long filename shows up once there is room for the full filename.

I wish that SlickEdit would show as much as fits plus "..." at the end, as is the common metaphor on Windows.
For example, this:
    "PartOfSomeVeryLongFilena..."
Instead of this:
    ".."

And when the editor condenses out a path to allow seeing the filename, then it could look like this:
    "c:\...\PartOfSomeVeryLong..."

[livingintown]

I am on windows, the theme looks like linux any way. .

[livingintown]

Any progress? are you guy able to re-create it in your application or still need me to provide more info?

[ScottW, VP of Dev]

So far, we are unable to reproduce this problem. The ".." is used when a path is too long for the space that is provided. In all of my testing, we still get at least the drive letter, "C:/..".

We still need the answers to Dan's questions:
1) Do all files show up with ".." for the path? If not, can you provide the full path for some files that do and for some that don't? We need to figure out what's triggering this behavior.
2) Does the same file show up with or without the path on the Project or Workspace tabs?
3) Are these files that have been saved, or are they new buffers that have not been saved yet?
4) Can you provide the full path for these files as reported by the operating system?
5) Is that path local to the machine or on a network share?

This should help get to the bottom of this.  Thanks!