Fixed Starting editor from VIEW

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
There is a bug in how VIEW handles starting the configured editor: It passes the original file path+name that was used to open VIEW, but with the working directory set to the directory containing the file:

Code:
C:\Data> VIEW subdir\file.txt
shows the contents of file.txt. If I then press Ctrl+E or select File|Edit, my editor starts up and tries to open C:\Data\subdir\subdir\file.txt.
 
#2
It passes the original file path+name that was used to open VIEW, but with the working directory set to the directory containing the file
In the Editor/CMD section of the VIEW Preferences, specify %f as the Editor Options. This should force VIEW to use the full path. Does this fix the problem?
 
#3
In the Editor/CMD section of the VIEW Preferences, specify %f as the Editor Options. This should force VIEW to use the full path. Does this fix the problem?
The help says:
Code:
F    The selected file name(s) - includes fully qualified path
 
f    File name only (no path)
Please clarify. When I start VIEW this way
Code:
v:\> view ip2c\ip2c.btm
and ask to edit the file with %F as the editor option, my editor (TextPad) asks if it's OK to create "V:\ip2c\ip2c\ip2c.btm". So it would seem we don't want VIEW to use full paths.

And when I start VIEW with multiple file names, there is very little indication that there are two files open (a couple of toolbar icons activated). Is there a way to get a greater indication that there are more than one file open? And when there are more than one file open, File\Close terminates VIEW, just like File\CloseAll does. Given that the two menu items exist, I'd expect "Close" to close only one file.
 
#4
Same here. With %f, it works because only the actual file name is passed. The behavior with %F is the same as without any option, so I think the "full path" that %F is supposed to produce does not refer to "the absolute file system path", but instead to "the full path as originally passed to VIEW". Same with %D, which is not the fully qualified path to the current directory, but instead the directory portion of whatever VIEW was started with.
 
#5
With %f, it works because only the actual file name is passed.
You are right - %f happens to work by good fortune and not by design. %f and %F should work as stated in the Help file.

I will fix the bug in the next VIEW update.


And when I start VIEW with multiple file names, there is very little indication that there are two files open
Is there a way to get a greater indication that there are more than one file open?
In a word, no.

Given that the two menu items exist, I'd expect "Close" to close only one file
You should be able to implement this behavior as follows:

1. Enable View Next File in the Keyboard section of Preferences
2. Enable Closing File Window to behave like pressing ESC key in the File Options section

Selecting Close from the File menu should now take you to the next file - just like pressing ESC.

However, there is a bug which is stopping this from working. I will fix this too in the next update.
 
#6
Charles, I purchased "V" in 2010 (May?) and since had a big crash. I moved to Windows 7 and though "V" still sits on my "Apps" drive and I have access to the old registry and the "Prineas" key, I can't find registration info. And I can't find reg info among my thousands of emails. If you have records confirming this, could you supply me with new registration info?
 
#8
I sent an email to the address I had on file for you.

If you haven't received it, send me an email at v at fileviewer.com.
Yes, I got it this morning, quite promptly, but I didn't have time to respond. So ... thanks!

And, as it is, Esc will take me to the next file. But it doesn't cycle back to the first after the last. Is (should there be) a way to do that (or a way to go to the previous file).