Re: [Clip] Puzzling behavior of Select FileName
- --- In email@example.com, loro <tabbie@...> wrote:
>That's odd. I just tried it again very carefully (and several times) and it is still doing for me what I said it was. In fact, if you add just the e instead of the er, it 'breaks' and returns 02.jpg. Also, if I start with the original filename which returns the entire filename and change 'Rex and Belle 2' to 'Rex and Bell 2' by removing an e, it again breaks and returns 02.jpg. It's very unexpected.
> joy8388608 wrote:
> >NTL 6.2 on Win 7 machine.
> >I'm not yet sure of the pattern, but I'm getting odd results from
> >this simple script.
> >^!Select FileName
> >^!Prompt ^$GetSelection$
> >Use the single filename below and place the cursor between the J and
> >P on JPG then run the clip. The prompt shows me the full filename.
> >Now change the filename by adding 'er' after Rex and do the same.
> >Now it selects and shows me '02.JPG'
> >Is there something about folders with blanks and\or parens () or
> >filenames with blanks?
> >data... one long line
> >C:\Users\user\Pictures\OtherPics\Cats\Rex and Belle 2\201010 Patch
> >under Belles right eye 02.JPG
> Actually, for me only 02.jpg gets selected in both cases. Maybe more
> interestingly, if I replace the spaces in the file with hyphens like so
> C:\Users\user\Pictures\OtherPics\Cats\Rex and Belle
> 2\ is now considered part of the file name.
> Looks like Select FileName really means select to the first blank
> space. If all the spaces are replaced, the whole path is selected.
I have the Light version of NT instead of Pro so that may be one place to look. I am fully aware of the joys of spaces in filenames, but thought it was strange that the particular changes I was making causes the clip to work differently each time.
The unasked question is why it couldn't be fixed. I have no idea of how the internal code works, but it seems that looking backwards from the cursor position for a letter followed by a colon then forward from there for a period, 2-6 letters and a word boundary would handle most of the situations. I changed my code to do a search like that instead of using Select FileName and it works ok. Just putting it out there.
Thanks for the reply.
- There are two reasons for NoteTab's 'select filename' behavior:
1. Filenames do not necessarily start with a drive letter. Especially in a document, that just happens to have a filename in it.
At one extreme is "filename", at the other is "//servername/sharename/path/filename.extension.nutherextension.andanother.etc"
2. The position of the cursor, which is where NT starts looking from, in both directions, for a delimited block of text. Delimiters are spaces and quotes, among others.
Consider the FILENAME option for ^!select as a bonus, which may be useful in concert with other tools. It interprets certain strings with delimiters embedded as filename, as opposed to a list of delimited words. It does NOT interpret spaces, and a few other delimiters, as part of a filename. If you want to include some of these delimiters, as you have already found, there are other ways to do what you need. Even with NoteTab light <g>.
--- In firstname.lastname@example.org, "joy8388608" <mycroftj@...> wrote:
> The unasked question is why it couldn't be fixed. I have no idea of how the internal code works, but it seems that looking backwards from the cursor position for a letter followed by a colon then forward from there for a period, 2-6 letters and a word boundary would handle most of the situations.