Hi Rejetto! This is a great news that you start using github.
nice to see you
and thanks for commenting this
I'm not sure what you mean by too late to founding my post? 3 years - it's not too much
i meant i could have started from your base, but i started from scratch.
Anyway, i'm sometimes taking inspiration from yours, so...thank you
But as I see you are only at the beginning of rewriting hfs to full Unicode support.
you think? i hoped to be almost finished with the unicode thing
but i still have to check all 'data loss' compiler warnings, if not all of them.
As per my understanding, all AnsiString should be divided into String ot RawByteString.
Because AnsiString is not the same as was String in pre-unicode Delphi.
AnsiString is a codepaged string and it can be even MultiByteString. And that makes it very dangerous to use for unknown incoming bytes.
This is an interesting topic.
I like the name rawByteString more, as it expresses what i'm using it for.
First thing i did was to check its definition
> type RawByteString =AnsiString;
I deduced it was just a matter of taste, but I was undecided on what to do as I already had many ansistrings around.
I tried to introduce the rawBS in a few places but I had some compilation issues. IIRC it was on 'var' parameters, it required the exact type. Then considering it as unnecessary I skipped it, as there was much else to do.
I saw the multibyte reference in the doc you are talking about. The only thing i can suppose is that some function may behave differently (through overload) on systems with some codepages. It's not easy for me to test, and maybe some asian user may help.
Anyway, I know I have many asians users and I would expect the problem to have happened even with the previous versions.
The only reports i have received were about unicode filenames.
move(idxS[1], result[p], length(idxS));I think this should be as
MoveChars(idxS[1], result[p], length(idxS));
right, i should verify every usage of 'move' against the type of string.
But for ansistring i should still use 'move', as the docs say to use moveChars only for unicode.
It would be great if you could compare your code with mine.
i should, and i was, but stopped to give priority to more 'apparent' issues.
I had to make a big changes because of TreeView unpredictable self-reorganization (all nodes are recreated when monitor is disconnected).
what kind of changes? all about strings in main.pas ?
was you using Delphi 10.3 ?
i detached the monitor and all was well, then reattached and the whole program was stuck (CPU 100%). I will investigate. Thanks
As you made your work as public, it would be great if you added your coding-standards.
i should consider that, even if i'm not very concerned about it. But i'm willing to consider merge-requests.
This project for me is a "survivor", and I hate working with delphi. Yet HFS makes still sense and a lot of people using it.