Create file and open with Notepad++ fails

[ghisler(Author)]

It should also be possible with this pathname: "C:\Program Files (x86)\Npp\notepad++.exe". Does it?

Yes it does, and also with environment variables like %commander_path% and similar.

[JOUBE]

It should also be possible with this pathname: "C:\Program Files (x86)\Npp\notepad++.exe". Does it?

Yes it does, and also with environment variables like %commander_path% and similar.

That's very good. And it's very good that this reaches Tc11 (at last moment).

Edit: 2ghisler(author)
Don't move this thread to "fixed bugs". You just - as you say - built a workaround around this bug in TC.

[white]

Incidentally, I simply installed the update that was automatically offered to me in notepad++ on that day mentioned. I use notepad++ every day. It was tow days after that post in that thread at notepad++.

See https://npp-user-manual.org/docs/upgrading/#no-new-version-found-safety-delay

[JOUBE]

See https://npp-user-manual.org/docs/upgrading/#no-new-version-found-safety-delay

Since you value an answer: I'm just a user of notepad++. The Tc should work with it and I am not interested in anything there (Docs, news forum) beyond notepad++. Unfortunately, the rather embarrassing thread - in which the Tc is mentioned - probably remains there somewhere.

The following remains:

This problem exists in 10.52 which I was using till now, was hoping that v11 has this issue fixed.

So, to be clear, if Tc wants to speak with notepad++.exe, Tc has to handle it.

2white
I have added this fix to Total Commander 11 now.

Joube

[ghisler(Author)]

Don't move this thread to "fixed bugs". You just - as you say - built a workaround around this bug in TC.

No, adding the dot is necessary because of notepad, too bad that notepad++ behaves differently...

[JOUBE]

Don't move this thread to "fixed bugs". You just - as you say - built a workaround around this bug in TC.

No, adding the dot is necessary because of notepad, too bad that notepad++ behaves differently...

'Your' dot is intended to prevent the editors themselves from simply appending .txt. With these editors, a file without an extension is actually not possible/desirable. For me, on the other hand, notepad++ behaves correctly because it gives the user the freedom to create files without an extension. You have followed the user's wishes to create files without extensions with the other editors and have achieved this with the trick: dot. You have made that the default (even hardcoded), although these editors don't actually want it (they want to attach .txt instead). So this is of course not correct to overwrite this. The users have normaly actually to reconfigure this in that editors themselves.

Therefore, there is only one way to 'save' the matter. Installation of a switch in the ini with the default value '.'. Which you can then switch off. If you install this as a switch on the page with the editor in the configuration (with a dot/without a dot), you don't need to explain anything further, because using notepad++ will then immediately see what doesn't work with notepad++, based on the error message within notepad++ and the user know the config page where they can change it, because they have entered Notepad++ there thereself.

Joube

[Horst.Epp]

2JOUBE
What's your problem now ?
The current solution works for any editor.

[white]

'Your' dot is intended to prevent the editors themselves from simply appending .txt. With these editors, a file without an extension is actually not possible/desirable.

Sure it is. It's just that they utilize a default extension. That doesn't mean you can't use other extensions or no extension. By adding a dot at the end of a filename you are explicitly specifying the filename extension, namely an empty extension. This is a feature of the operating system and has been around since the MS-DOS era.

For me, on the other hand, notepad++ behaves correctly because it gives the user the freedom to create files without an extension. You have followed the user's wishes to create files without extensions with the other editors and have achieved this with the trick: dot.

As explained, it is not really a trick but a feature of the operating system. Notepad++ handled that fine until a fix was created for an issue I reported that caused Notepad++ to crash. The crash occurred when there was an existing file with a filename that really ended with a dot and that was opened using the \\?\ namespace. The "\\?\" prefix causes the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. To prevent the crash an error is displayed when the passed filename ends with a dot. However this should only happen when the \\?\ namespace is used, so the fix was bad. A small change in the code has been made that should fix this, but a new version has not been released yet.

This isn't the only case where TC adds a dot to the filename and I agree with you that it would be best if the user has control over it. Here is a suggestion I made earlier:

It would also be nice if, in addition to above, the user can control whether TC adds a dot to filenames without filename extension. TC is inconsistent in that it adds a dot when calling associated programs or external editor/viewer, but does not do so when a file is dragged and dropped on a button or when TC replaces special variables like %N used in button bar etc. A solution could be to allow another modifier in the command fields, similar to the modifiers * and **. Perhaps a more flexible syntax should be introduced. For example (?<modifiers>), similar to the inline regular expression modifiers which can enable or disable certain behaviors.

[JOUBE]

and I agree with you that it would be best if the user has control over it.

Yes, hardcoded is never a good solution, also in this case. (e.g. if you rename - the stange filename - notepad++.exe to npp.exe ghisler(autor) 'fix' doesn't work). The user should - especially in the case of an interface to the outside - have the control.

Joube

[AntonyD]

2ghisler(Author)
It's strange - but why not read the information about the file, where in the "OriginalFilename" field - there will definitely be
the required string `notepad++.exe`
And no any external renaming of the executable file name will confuse us here. And the fix will always work clearly.

[white]

Yes, hardcoded is never a good solution, also in this case. (e.g. if you rename - the stange filename - notepad++.exe to npp.exe ghisler(autor) 'fix' doesn't work).

Mr. Ghisler said in this thread:

Since it's a workaround, I wanted to make it as restrictive as possible.

So it's meant to be restrictive. It is a workaround as a service to the users.

[JOUBE]

Mr. Ghisler said in this thread:

Since it's a workaround, I wanted to make it as restrictive as possible.

Don't move this thread to "fixed bugs". You just - as you say - built a workaround around this bug in TC.

Moderator message from: white » 2023-08-03, 09:34 UTC

Fixed quotation.

[white]

Don't move this thread to "fixed bugs". You just - as you say - built a workaround around this bug in TC.

In this particular case, it is a workaround for a bug in Notepad++ that solves the problem described in the topic start. The general behavior of TC of adding a dot, is by design. If you have a suggestion to change this behavior, I suggest to post a suggestion in the Suggestions forum.

[ghisler(Author)]

I wouldn't call the behavior of notepad++ a bug, just an unexpected misbehavior. Windows does not allow dots at the end of names, although the underlying NTFS file system supports it. Using the prefix "\\?\" tells Windows to ignore its rules and just pass the name to the file system unchanged. But TC didn't pass the name with \\?\ prefix to notepad++, so it shouldn't ignore the Windows rules.

[Sir_SiLvA]

This is a Tc bug.

In this particular case, it is a workaround for a bug in Notepad++ that solves the problem described in the topic start.

So it IS a np++ bug