rejetto forum

delphi 10

rejetto · 112 · 11168

0 Members and 1 Guest are viewing this topic.

Offline LeoNeeson

  • Tireless poster
  • ****
    • Posts: 740
  • Status: On hiatus (sporadically here)
    • View Profile
    • twitter.com/LeoNeeson
find attached the changes of rc4
Thank you! :) (I'll check it later)

i had to disable the translation system, the one we added recently, as it was not compatible
Don't worry, perhaps you will find another alternative in the future.

i made an attempt with lazarus, but i'm stuck trying to compile ICS with fpc.
if anyone is willing to make this other porting i will see what i can do, at the moment my spirit is already worn out but delphi10.
Yes, it seems latest ICS-V8.58 is not compatible with FPC. In case you or someone else is interested on compiling it with Lazarus, the last compatible version, is ICS-V5, according to THIS message: "It compiles with version 5 (2005-07) and only if you include the units and create objects and events manually."

If/when i have more time i would like to try to see if i can use delphi's socket lib instead of ics, and have less dependencies.
Perhaps that could help to make sources being easily compilable on Lazarus (since latest ICS is not compatible with Lazarus/FPC). We look forward to new changes that you could bring on the future using Delphi 10 (my best wishes on that). ;)  8)

Cheers,
Leo.-
HFS in Spanish (HFS en Español) / How to compile HFS (Tutorial)
» Currently taking a break, until HFS v2.4 get his stable version.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
Don't worry, perhaps you will find another alternative in the future.

that, or maybe fixing this library is not hard, but i will have to focus on the basics for now.

but, I did not manage to login (locally) with FF & Chrome...

confirmed, the old build didn't work, but next one will

Quote
and the password field in hfs Others Options > users account is inaccessible (invisible).

that was just the 'group' enabled by default, causing the password to disappear. Fixed in next release, thanks.


I had to revert to zlib included in ICS, as the other one had problems. I'll reconsider this in the future.

New release: please give a look https://github.com/rejetto/hfs2/releases/tag/v2.4-alpha02


Offline Rapid

  • Occasional poster
  • *
    • Posts: 42
    • View Profile
    • R&Q Portal
Hi Rejetto! This is a great news that you start using github.
I'm not sure what you mean by too late to founding my post?
3 years - it's not too much :)

But as I see you are only at the beginning of rewriting hfs to full Unicode support.
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.

Code: [Select]
move(idxS[1], result[p], length(idxS));I think this should be as
Code: [Select]
MoveChars(idxS[1], result[p], length(idxS));
It would be great if you could compare your code with mine.
I had to make a big changes because of TreeView unpredictable self-reorganization (all nodes are recreated when monitor is disconnected).

ps.
As you made your work as public, it would be great if you added your coding-standards.
So what merge-requests are you willing to merge.
For example:


Regards,
Rapid D


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
Hi Rejetto! This is a great news that you start using github.

nice to see you :) and thanks for commenting this

Quote
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 ;)

Quote
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.

Quote
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.

Quote
Code: [Select]
move(idxS[1], result[p], length(idxS));I think this should be as
Code: [Select]
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.

Quote
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.

Quote
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

Quote
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.
« Last Edit: May 07, 2020, 10:10:32 PM by rejetto »


Offline SilentPliz

  • Operator
  • Tireless poster
  • *****
    • Posts: 1298
  • ....... chut ! shh!
    • View Profile

Hi!

I tested 'unicode' with Chinese words:
Treeview (files, folders) ... OK
Accounts name ... OK

But I did not manage to connect with an user account written in Chinese.

The 'Locale of WIN 2007' for the test is in French.
« Last Edit: May 07, 2020, 03:21:21 PM by SilentPliz »


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
thanks SP, i just fixed a number of unicode problems, including the one you reported
https://github.com/rejetto/hfs2/releases/tag/v2.4-alpha03


Offline NaitLee

  • Tireless poster
  • ****
    • Posts: 142
  • Computer brained boy
    • View Profile
Hey, I did a simple test with 2.4 rc5 (alpha 3) for the Unicode problem with my takeback template, but still found something worked wrongly:

  • The takeback template with Chinese language set even works well in rc4, but get a mess-code problem in rc5: File names are still well, even Korean file names are shown because of the Unicode update, but GUI (built-in) texts got mad. Setting the meta charset of the template/webpage is useless to the problem. This problem got fixed after I save the template with ANSI encoding (keeping meta charset as utf-8), but this is neither we want nor the template makers want, this will cause some symbols which are utf8-only get disappeared.
  • Though the usernames in HFS now saved as Unicode, when I attempting to login as a Chinese username, with takeback template (comes with the alternative login form ver2 by Leo) I got "this user does not exist" again as the same as in 2.3m, and with the default template I got a "400 - bad request" then no page on my site can be accessed with that error code...

With problems above users may feel more uncomfortable than using old version... :( Sorry that I know nothing about Pascal and can do no help to the source code... :-[
Wish these problems can be dealt successfully...
« Last Edit: May 09, 2020, 12:23:11 AM by NaitLee »
Busy in school until late June, 2021.
Check out my template ;)


Offline LeoNeeson

  • Tireless poster
  • ****
    • Posts: 740
  • Status: On hiatus (sporadically here)
    • View Profile
    • twitter.com/LeoNeeson
...but GUI (built-in) texts got mad. Setting the meta charset of the template/webpage is useless to the problem.
With problems above users may feel more uncomfortable than using old version... :(
Could you please post a screenshot of how it looks on v2.3m, v2.4 RC4 and v2.4 RC5? (to easily spot the problem). I'm sure some screenshots could give a better picture of the problem (you can upload them on Imgur or as forum attachments).

  • Though the usernames in HFS now saved as Unicode, when I attempting to login as a Chinese username, with takeback template (comes with the alternative login form ver2 by Leo) I got "this user does not exist" again as the same as in 2.3m, and with the default template I got a "400 - bad request" then no page on my site can be accessed with that error code...
I wish this could be solved. I hope Rejetto could entirely review the login and logout (internal) functions, specially the logout, as it's being discussed here. Perhaps if he do some changes, your problem could be also solved.

@Rejetto: :-[ :'( Ti prego, per favore, guarda questo messaggio e lascia un commento. Grazie...

Cheers,
Leo.-
HFS in Spanish (HFS en Español) / How to compile HFS (Tutorial)
» Currently taking a break, until HFS v2.4 get his stable version.


Offline dj

  • Tireless poster
  • ****
    • Posts: 275
  • 👣 🐾
    • View Profile
    • PWAs
but GUI (built-in) texts got mad
save your tpl as "UTF8 with BOM" helps (working example of my tpl)


Offline NaitLee

  • Tireless poster
  • ****
    • Posts: 142
  • Computer brained boy
    • View Profile
save your tpl as "UTF8 with BOM" helps (working example of my tpl)

Yes it really helps...
It's a pity that I have not know something about BOM before this. But here in Stack Overflow says utf-8 with BOM is not recommended...
Should these tough encode problems solved by keeping the compatibility to HFS or following the national standard (a pdf, something is in section 2.6 and 2.13)?
« Last Edit: May 09, 2020, 02:21:14 PM by NaitLee »
Busy in school until late June, 2021.
Check out my template ;)


Offline SilentPliz

  • Operator
  • Tireless poster
  • *****
    • Posts: 1298
  • ....... chut ! shh!
    • View Profile
@NaitLee, dj, all, :) :)

It seems that currently the work of rejetto on hfs 2.5 is directed on the rewriting of the basic functions, in order to (re)find the good functioning of hfs not only in unicode, but also it aims to adapt it to the new 'compiler' requirements.

It's good to point out what is dysfunctioning.

But do not tire yourself too much to adapt your work on your templates day by day, from these alpha versions.

I think it is wiser to wait for a 'stabilization' of the rewriting of the program ... otherwise, you will look like Sisyphus. ;)
« Last Edit: May 09, 2020, 05:23:44 PM by SilentPliz »


Offline NaitLee

  • Tireless poster
  • ****
    • Posts: 142
  • Computer brained boy
    • View Profile
It seems that currently the work of rejetto on hfs 2.5 is access on the rewriting of the basic functions, in order to find the good functioning of hfs not only in unicode, but also it aims to adapt it to the new 'compiler' requirements.

Yes, with several tricks these problems can be avoided. It's a wise choice to adapt the application itself to a stable environment first, then go ahead for these tough but not-so-necessary things.

If this is really hard-as-rock, the Unicode username problem can be put off, since a person with a wide-enough knowledge and technical skill will always try to adapt to a thing rather than always require the thing to change.
But be aware at the login/logout problem, it seems unadaptable to most ones...
Busy in school until late June, 2021.
Check out my template ;)


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
Hey, I did a simple test with 2.4 rc5 (alpha 3) for the Unicode problem with my takeback template, but still found something worked wrongly:

thanks for your time! your link was not working, so i just downloaded version 0.13b from your signature.

Quote
The takeback template with Chinese language set even works well in rc4, but get a mess-code problem in rc5: File names are still well, even Korean file names are shown because of the Unicode update, but GUI (built-in) texts got mad.

what are these texts you are talking about? i don't understand.
I tried to install your tpl and saw nothing bad with unicode chars.

Quote
I got "this user does not exist" again as the same as in 2.3m, and with the default template I got a "400 - bad request" then no page on my site can be accessed with that error code...

i tried, with your template, to have an account 會 and could log in successfully.
Let me know if you find exactly how to reproduce the problem.


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile

Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
If this is really hard-as-rock, the Unicode username problem can be put off, since a person with a wide-enough knowledge and technical skill will always try to adapt to a thing rather than always require the thing to change.

silentpliz is right, the goal is to have a tool working well LIKE and BETTER than before, all problems must be solved.
I need to know all the problems, but i need to be able to reproduce them.