Problems with %$CLIPBOARD0% and %$CLIPNAME1%

[ghisler(Author)]

I don't think that spaces within double quotes should be removed, they must be there for a reason. For example, the user may actually want to access a file with trailing spaces, so the only way to do this would be writing "C:\Path\To ".

[Fla$her]

But TC itself doesn't allow to give names with spaces at the end. These files usually come from *nix. For Windows, such names do not make sense, because they are not supported when they are created. Spaces in front of names (not paths) are, of course, allowed.

But here's the thing. Some sites, due to poor design, give paths like this: " C: \ Program Files \ Path \ To ". Therefore, I usually use scripts to cast such paths to "C:\Program Files\Path\To".

[JOUBE]

Some sites, due to poor design, give paths like this: " C: \ Program Files \ Path \ To ".

Therefore ghisler(author) see it right (as sometimes ) und do it right here.

[Fla$her]

Therefore ghisler(author) see it right

The conclusion from the quote, if we follow common sense, should be the opposite.

[Fla$her]

TC 11.50RC2
And again the bug was not fixed.

But quotation marks are no longer added to those that were on the clipboard, which is gratifying.
The difference between Q and q matches the description.

[ghisler(Author)]

Thanks for confirming the working of lowercase 'q'. The other problem you have is not a bug. I can't handle every possible input in the world.

[Fla$her]

I can't handle every possible input in the world.

You're obviously exaggerating. There is nothing difficult in removing all the adjacent whitespace characters (\s). Why do this selectively for some characters? What's so hard about adding form feed 0x0C and vertical tab 0x0B to processing?

[ghisler(Author)]

Sorry but WTF is \f ? Why does it matter? It does not appear anywhere where the user would copy it. It can only be created artificially.

[Fla$her]

Many binary files with these characters can be represented in text or binary form, from which they are easily copied to the clipboard.

By the way, there is also a problem with \t — they are deleted everywhere, and not on the borders of phrases. Logically, they should be replaced with spaces:

Code: Select all

this	string	contains	tab	characters

>>>

Code: Select all

this string contains tab characters

or in the case of _NEq >>>

Code: Select all

"this" "string" "contains" "tab" "characters"

[ghisler(Author)]

Many binary files with these characters can be represented in text or binary form, from which they are easily copied to the clipboard.

Then why just \f? Makes no sense to me.

By the way, there is also a problem with \t — they are deleted everywhere

All non-printable characters with a code <32 (space) anywhere within a name are being removed.

[Fla$her]

Then why just \f? Makes no sense to me.

Why just? I also wrote about other non-printable characters, including \v [\x0c].
I've only shown a list of known metacharacters for regular expressions, but there are, of course, other non-printable characters from Unicode. But it would probably seem too much to you.

All non-printable characters with a code <32 (space) anywhere within a name are being removed.

Do you mean less? This is a defect, it shouldn't be like this. I select cells of the same row with names in the table by Ctrl+Click and copy by Ctrl+C, and TC in variables for some reason glues them together, which is completely meaningless and logically unacceptable. You need to do the same thing as with characters like \r and \n, i.e. use them as variable separators. Only leading and trailing tab characters of the value returned to the variable should be deleted.
[\t\r\n\v\f]+ between phrases should become one delimiter between the returned variables.

[ghisler(Author)]

I have made two more changes, please check them:

18.12.24 Fixed: %$CLIPNAME*<number>: Treat any character with code<=32 outside of a name as a space character (except for line breaks #13 and #10) (32/64)
17.12.24 Fixed: %$CLIPNAME*<number>: Replace tabs within names with spaces instead of removing them (32/64)

[Fla$her]

This doesn't correspond to what I wrote, given that each cell contains a separate name, and when replaced with spaces, it returns "this string contains tab characters" instead of this string contains tab characters (NEQ) or "this" "string" "contains" "tab" "characters" (NEq).

The problem with the mshta example has been fixed, thanks for that. )

[ghisler(Author)]

Sorry, I will not make any other changes to this function.

Moderator message from: ghisler(Author) » 2024-12-19, 08:19 UTC

Moved to will not be changed