PrestoSoft Community

It is one of four EBCDIC code pages (alongside 500, 875 and 1026) with mapping data supplied by Microsoft to the Unicode Consortium, and one of seven (alongside 273, 424, 500, 875, 1026 and 1140) supported by Python as standard. Wow! The best to create a mess, I think. :D EBCDIC... And you call me ...

There is something wrong when comparing directories (or drives) with the latest version of EDP 32: only very few directories are shown.

Gosh! Not a trivial question. There were so many changes and fixes that it's hard to pinpoint the most significants. Furthermore, to decide what is significant depends on what you need to do. I think I do a fairly deep use of EDP so I would desperately miss many of the new features, but if your need...

Hint: do not simply modify the standard toolbars; use a name different from the standards for your custom toolbar.

Example 1: select two files at wish, let's say "a.txt" and "b.txt", with the windows file manager; right click on either, the local menu appears; select "Compare" (the only EDP available in this case); EDP does NOT start comparing as was customary but shows the file sel...

13.0.1.0 (32 bits)... Guess the Windows version.
I can confirm that it's ok on Win10 (64 bits, of course).

I just installed 13.0.1.0 (32 bits) and I discovered there are problems with the "Compare to..." shell extensions. If I select a couple of files at once or I ask "Select firsti item to compare" and then "Compare to...", the second file selected takes the place of the fi...

Comparing a couple of text files whose unique difference is a CR-LF at the end of the last line I get "identical". What matters is "ignore linebreak styles". If it's unchecked then the difference appears. Honestly, I'm not sure I can really call it a bug. But if you say "Ign...

I beg your pardon. It's always been so.
Probably I never took note of that because I usually ask to delete also the directory.
Sorry.

Thank you very much, as always.
As I wrote, I think it was already so a few versions ago.

Well, to begin with: it wasn't so up to not so many versions ago.
Then, no need to sort again: the directory position is exactly the same of the removed files!
The unnecessary waste of time is exactly to have to recompare (and resort).

Does that depend on how the list is sorted? Of course. But I almost always sort the directories on relative path and I didn't change it lately (or at least I don't remember having done it) and anyway now I double checked the sorting mode is that. Recipe: compare two directories with subdirs (it doe...

Now, when a directory becomes empty after a deletion, the directory itlsef shifts at the bottom of the list. In a case, after a deletion, a copy and a recompare (more on this once I have replicated the exact sequence) in the list I had both the directory (this usually means it's empty) and its conte...

Bah! Forgive me.
I was looking for it after having clicked "empty files"...

I had the same feeling, back then, but it was just a feeling. Nothing certain.
And so far I'm unable to reproduce the problem.
As soon as can get to it I'll let you know, you can bet!