PDA

View Full Version : Wildfile "locks itself" after one use



bschor
September 19th, 2011, 05:48 PM
I love the Wildfile macro -- I probably use this feature of VEdit as much or more than any other! I'm happy with the redesign, and very happy it is now available in Windows 7.

I ran a Wildfile query against a bunch of files, and it worked as I expected (i.e. flawlessly). However, when I did it a second time (after exiting VEdit), I got the message "In Overwrite-Only Mode --see (Config, File Handling)". The problem was that the previous Wildfile created a file called search.tmp in Program Files\VEdit\config -- if I manually delete this file, I can run another Wildfile query.

Two questions/issues. 1) Why is this temporary file "hidden away" inside Program Files? [I think I installed VEdit as Single User, so this may be the default, but shouldn't configuration info always be stored in a User area?] 2) Why is this file written in Overwrite-Only mode in the first place?

Note that I'm being a little "lazy" by asking this in the Forum, rather than diving into the macro itself and trying to figure it out/fix it. Sadly, I've got too much on my plate at the present to indugle myself "having fun with the internals".

Bob Schor
Happy VEdit User for >2 decades

Scott Lambert
September 19th, 2011, 06:10 PM
Hi,

I think the single-user install option is NOT a good idea on Win7. Windows 7 is very picky about files being altered under c:\program files or c:\program Files (X86).

My suggestion is you do an uninstall of Vedit, and reinstall using the multiple users option. You want the User_Home under the directory [driveletter]:\users. The location is the parent of My Documents. In my case this is c:\user\owner, but your system may be different.

When the install program asks where to put the user_home directory, specify c:\users\[parent of My Document]\vedit
(my system it is: c:\users\owner\vedit

This is what I did on my system, never had a problem.

Did I make any sense???

Scott

ian binnie
September 19th, 2011, 08:51 PM
I love the Wildfile macro -- I probably use this feature of VEdit as much or more than any other! I'm happy with the redesign, and very happy it is now available in Windows 7.

I ran a Wildfile query against a bunch of files, and it worked as I expected (i.e. flawlessly). However, when I did it a second time (after exiting VEdit), I got the message "In Overwrite-Only Mode --see (Config, File Handling)". The problem was that the previous Wildfile created a file called search.tmp in Program Files\VEdit\config -- if I manually delete this file, I can run another Wildfile query.

Two questions/issues. 1) Why is this temporary file "hidden away" inside Program Files? [I think I installed VEdit as Single User, so this may be the default, but shouldn't configuration info always be stored in a User area?] 2) Why is this file written in Overwrite-Only mode in the first place?


First, I agree that Wildfile (or any other program that writes to Program Files) at any time after installation is a bug.
This has been the case since XP, but only with Vista was it prohibited.
In fact the files are not written there, because of feature of Windows designed to handle legacy programs.
The directories are virtualised, and each user gets a copy. The detail is more complex.

There is nothing wrong with installing Vedit as a Single User, macros should use %APPDIR%.

PS To clarify the directory should be %APPDATA%. I typed this from memory, as I now use a Mac for most of my computing.
Also you shouldn't have to enter this; Vedit should do this automatically.

bschor
September 19th, 2011, 09:05 PM
Thanks for the speedy replies. I've done the following: First, I followed a mix of Scott's and Ian's suggestion -- I reinstalled VEdit using "Multiple", and took the default Home directory of %APPDIR%\VEdit. Same thing, first Wildfile is fine, second "locks". Now the Search.tmp file is in
Users\RSchor\AppData\Roaming\VEdit\Config. Next, I tried Ian's suggestion, modified slightly to use %HOMEPATH% (in place of %APPDIR%).
Again, same thing, locks, but now the file is (as expected) in \Users\RSchor\VEdit\Config. I just checked to be sure the file isn't marked ReadOnly (it isn't) -- must be something Wildfile is doing ...

pal
September 20th, 2011, 07:23 AM
Sorry, first line should read: I think the single-user install option is NOT a good idea on Win7.


What is the single-user option supposed to do?

Normally, when installing Windows applications, there are two options: install for current user, or install for all users.
I assumed that the single-user option is the same as "current user".

Anyway, in both cases the user configuration data (USER_CFG) should be stored in user specific directory where the user has write access.
I wonder why VEDIT sets USER_CFG to point in program files.

--
Pauli

pal
September 20th, 2011, 07:38 AM
There is nothing wrong with installing Vedit as a Single User, macros should use %APPDIR%.

No, macros should not use environment variables.
One reason is that the variable may not exist in all Windows versions.
For example the variable APPDIR does not exist in my system (XP). (However, there is a variable APPDATA.)

Macros should use VEDIT internal string value USER_CFG, as Wildfilew.vdm does.
VEDIT installer should set this string to a correct value.

--
Pauli

Scott Lambert
September 20th, 2011, 11:38 AM
What is the single-user option supposed to do?
--
Pauli

My understanding is it is for backwards compatibility, when everything could be stored under c:\vedit. Under XP and earlier it is a viable option.

Or is that a different option, I am confusing it with?

Scott

mrvedit
September 23rd, 2011, 02:55 PM
I cannot replicate the problem on Windows 7.
After installing 6.21 as "[Single]", USER_CFG is set to c:\users\ted\appda\roaming\vedit\config as it should be.
This can be checked by going to VEDIT's "COMMAND:" prompt (with <Ctrl-E>) and entering the command "cfs" (short for Config_String). In this case I get:



HOME "c:\Program Files (x86)\vedit"
MACRO_DIR "c:\Program Files (x86)\vedit\macros"
CONVERT_DIR "c:\Program Files (x86)\vedit\convert"
USER_HOME "C:\Users\Ted\AppData\Roaming\vedit"
USER_CFG "C:\Users\Ted\AppData\Roaming\vedit\config"
USER_MACRO "C:\Users\Ted\AppData\Roaming\vedit\user-mac"
FILE_CFG_DIR "C:\Users\Ted\AppData\Roaming\vedit\file-cfg"
SYNTAX_DIR "C:\Users\Ted\AppData\Roaming\vedit\syntax"
PROJECT_DIR "C:\Users\Ted\AppData\Roaming\vedit\projects"
BACKUP_DIR "C:\Users\Ted\AppData\Roaming\vedit\backup"
VEDIT_TEMP "C:\Users\Ted\AppData\Local\Temp\VeditTmp"
FTP_DIR "C:\Users\Ted\AppData\Roaming\vedit\ftp"
VEDIT_INI "C:\Users\Ted\AppData\Roaming\vedit\vedit.ini"

These values come from the vedit.ini file:



HomeDir=c:\Program Files (x86)\vedit
UserHomeDir=C:\Users\Ted\AppData\Roaming\vedit
MacroDir=c:\Program Files (x86)\vedit\macros
ConvertDir=c:\Program Files (x86)\vedit\convert
UserCfgDir=C:\Users\Ted\AppData\Roaming\vedit\conf ig
UserMacroDir=C:\Users\Ted\AppData\Roaming\vedit\us er-mac
FileCfgDir=C:\Users\Ted\AppData\Roaming\vedit\file-cfg
SyntaxDir=C:\Users\Ted\AppData\Roaming\vedit\synta x
ProjectDir=C:\Users\Ted\AppData\Roaming\vedit\proj ects
BackupDir=C:\Users\Ted\AppData\Roaming\vedit\backu p
VeditFtpDir=C:\Users\Ted\AppData\Roaming\vedit\ftp
VeditTempDir=%TEMP%\VeditTmp
Startup=startup.vdm


If these are wrong, you can try editing the vedit.ini file with notepad. Or delete all VEDIT files and try in the install again.

In any case the USER_CFG variable must point to a directory in which you have full control.

pal
September 23rd, 2011, 05:43 PM
My understanding is it is for backwards compatibility, when everything could be stored under c:\vedit. Under XP and earlier it is a viable option.
Or is that a different option, I am confusing it with?


No, that is the "Traditional" option.
With Traditional option, everything can be stored under single directory (but it does not need to be c:\vedit).
On the other hand, I recall that even with Traditional option, the installer prompts for Vedit directory and User directory separately.

--
Pauli

bschor
September 23rd, 2011, 10:30 PM
Dear Mr. VEdit,
Thanks for the comprehensive reply. I've done some further experimentation myself, and have seen WildFile work as I expect it to (i.e. without the error I reported). I'm about to get on an airplane, but I'll do some more testing when I reach the Other Coast.

I was thinking "Why did I have this failure, but now it seems to work?" An idea is that I was using VEdit in an "unconventional" way -- to search for a string within binary (non-text) files (they were source files in a non-text-based "language"). I wonder if, when the original file was opened, some switch got set that said "Oh, this isn't a text file, better set the Overwrite-Only mode", and somehow this setting is passed along to search.tmp. Will experiment and report back.

Bob Schor

bschor
November 1st, 2011, 03:32 PM
I've done more experimentation, and now can describe (I hope) how to cause the WildFile "lockup" I described earlier.

I've been using VEdit for several decades, so some of my practices are "old-school", i.e. learned with the older WildFile macro. For example, if I want to search all files in a directory (and sub-folders), I first open (with VEdit) a file in the top folder, just to get to the right place. A significant feature is that I'm using WildFile to search in non-text (binary) files, files that, themselves, should be opened in "Overwrite-only" mode.

So with a file newly opened, I do a WildFile search, which works just fine. I can, in fact, do several different searches, and as long as I don't exit from VEdit, I'm fine.

But once I exit and try to re-enter VEdit and do another WildFile search, I get the dialog warning (which is currently on my screen) In "Overwrite-Only" mode -- See {Config, File Handling}. It then opens Search.tmp left over from my last search.

The "Workaround" is to simply delete Search.Tmp, saved in User_Cfg. Still, it would be nice if I didn't have to "manually" fix this each time it occurs.

Bob Schor

pal
November 8th, 2011, 03:56 PM
The only way I have been able to replicate the problem is:

1. Set {Config -> File handling -> Enable auto file type} OFF
2. Perform Wildfile search on binary files.

Now, depending on what you searched, you may have search results with very long lines.

3. Exit and re-start Vedit.
4. Set {Config -> File handling -> Enable auto file type} ON
5. Run Wildfile again.

Now Vedit sees binary data in the search results, so it opens it in binary mode (and thus Overwrite only mode, if you are using the default configuration).
Therefore it can not erase the old contents of the search results file.

In this case, if you press [View] button in Wildfile, the search results are opened in Binary (64 column) mode.

I don't know how the "Enable auto file type" could be changed when you restart Vedit unless you change it manually.

--
Pauli

GreenviewData
November 10th, 2011, 06:54 PM
Perhaps the solution is to perform a Config(F_OVER_MODE,0,LOCAL) immediately after search.tmp is opened.
Ted.

bschor
November 15th, 2011, 06:40 PM
Perhaps the solution is to perform a Config(F_OVER_MODE,0,LOCAL) immediately after search.tmp is opened.
Ted.

Yes, indeed, putting "Config(F_OVER_MODE,0,LOCAL)" after "File_Open(*"|@(#96)"*, ATTACH+OVERWRITE+NOMSG)" (line 1881, or thereabouts, in WileFileW.vdm) "unlocked" a "stuck" version of search.tmp, and let me search without further problems. [Oooh, I just realized I haven't tested exhaustively -- I was trying to WildFile search on text files, having previously "locked" WildFile by doing searches of binary files. I need to test searching binaries, and then seeing if I can again search binaries. Just a minute, I'll check ...]

Very interesting -- there's still a (minor) bug. I noticed when I first made this change and did a WildFile on some text files, I didn't get a neatly-formatted header with "Searching for ...", "Found ...", and the results nicely lined up for double-clicking. However, when I tried it again, it looked fine.

When I did the test mentioned above, namely searching within binary files, the first time it worked just fine, showing me all of the occurances and letting me double-click. However, when I closed VEdit and tried again (whether a binary or a text file), I was back in "unformatted hell", and seemed to be "stuck" there. I managed to "unstick" myself and get back nicely-formatted output by remembering that when I first tried Ted's fix, I tried to "double-click" even though there no neatly-formatted target. Nothing happened, but when I next opened WildFile, things looked perfect.

What seems to be happening is that the "display" of WildFile can exist in two modes -- "nicely formatted", and "messed up" (which looks like perhaps the proper EOL characters are not there). To change from "Nicely formatted" to "messed up", use WildFile on a binary file. To change back, try to "double-click" on a filename in the "messed-up" display, exit WildFile, and restart.

So we're 95% towards a solution. I'll put on my Thinking Cap and see if I can't figure out the last 5% (but if Ted figures it out first, I won't be disappointed ...).

Bob Schor

mrvedit
November 16th, 2011, 04:19 PM
Most likely another buffer is getting put into binary mode when it should remain in text mode. I will try to replicate and fix this too.

I apologize for my "absence" these past two weeks. I've been busy training new support staff. Well honestly - I have also taking advantage of the last few days before winter sets in.

pal
November 19th, 2011, 09:01 AM
Bob,

What do you mean by "messed up" display? Do you mean that the search results file is in binary (64 column) mode?

Do you have the setting {Config -> File handling -> Enable auto file type} enabled or disabled?
(Normally, it should be enabled.)
Do you change this setting when searching in binary files? If you change the setting, do you save the configuration?
As I explained earlier, the only way I could replicate the problem was by changing that setting.

When you perform the search on binary files, how do the results look like? Do you have very long lines, or are all the lines 64 characters?
Do you close the search results file before performing the next search? (The auto file type checks the format only when the file is opened.)

When you restart Vedit after performing binary search, do you ever get a warning "Cannot undo this operation"?
You would get that warning if the search results file is big (which happens easily with binary files because of the long lines).

pal
November 19th, 2011, 09:51 AM
I added another command, Config(F_F_TYPE,1,LOCAL), to turn off binary mode.
At least with these changes, the search results are always displayed correctly even if auto file type was turned off during binary file search.
But I still don't see how this problem could occur if you do not deliberately change the setting.

Here is the modified macro:

50

bschor
November 19th, 2011, 06:31 PM
I added another command, Config(F_F_TYPE,1,LOCAL), to turn off binary mode.
At least with these changes, the search results are always displayed correctly even if auto file type was turned off during binary file search.
But I still don't see how this problem could occur if you do not deliberately change the setting.


Pauli,
That fixed it! [I should have mentioned that I was using the Display List with Filenames option, and, yes, the binary file "snippets" did appear as 64-character lines of text + gibberish].

As to how this occurs, I do not deliberately change the settings. I usually use VEdit as a simple (?!?) text editor, editing text files. However, I admit to "abusing" the WildFile macro to help me find strings buried in "binary format" files. In particular, I have some LabVIEW code (extension "vi") that are definitely not text -- this is a graphical language where variables are "pictures" connected by "wires" (to control program flow). I use WildFile to search a collection of a thousand of these VIs looking for which ones reference "My data file.txt" (or some other string or variable name I know about). While I can't edit the file with VEdit, being able to say "Out of these 1000 files, these three are the ones I need to inspect using LabVIEW" saves me a lot of time and aggravation. But when I tried doing this with Version 6.2, I encountered first the "Lockup" that I originally described (and for which Ted provided a fix), and then the garbled display (for which I thank you!).

The only change I made to the macro you sent (after testing that it worked!) was to change the comment at the top, changing the "Last change" line to have today's date and updating the version number to 1.15.

Again, thank you for your help and expertise!

Bob Schor