+ Reply to Thread
Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Wildfile "locks itself" after one use

  1. #11

    Reproducible WildFile "lockup" failure

    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

  2. #12
    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
    Pauli -- Using Vedit 6.24.2 on Windows 7 Enterprise (64 bit) and on Windows 10 (64 bit)

  3. #13
    Perhaps the solution is to perform a Config(F_OVER_MODE,0,LOCAL) immediately after search.tmp is opened.
    Ted.

  4. #14

    And the Winner is -- Ted! (Well, almost ...)

    Quote Originally Posted by GreenviewData View Post
    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
    Last edited by bschor; November 15th, 2011 at 05:42 PM. Reason: Needed to change title

  5. #15
    Administrator
    Join Date
    Aug 2011
    Location
    Ann Arbor, MI
    Posts
    103
    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.

  6. #16
    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).
    Pauli -- Using Vedit 6.24.2 on Windows 7 Enterprise (64 bit) and on Windows 10 (64 bit)

  7. #17
    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:

    Attachment 50
    Pauli -- Using Vedit 6.24.2 on Windows 7 Enterprise (64 bit) and on Windows 10 (64 bit)

  8. #18

    Thanks, Pauli (and Ted), for fixing WildFile!

    Quote Originally Posted by pal View Post
    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

+ Reply to Thread

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts