Forum > FV/Textmode IDE
FV and UTF-8 - is it feasible
PascalDragon:
--- Quote from: y.ivanov on November 02, 2022, 08:43:50 am ---
--- Quote from: marcov on October 31, 2022, 07:48:23 pm ---The contents of that branch is what has been added to trunk.
KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.
--- End quote ---
Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).
--- End quote ---
Then please report such occurrences.
--- Quote from: y.ivanov on November 02, 2022, 08:43:50 am ---Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.
--- End quote ---
That is expected. Unicode handling requires a Unicode manager on non-Windows.
alpine:
--- Quote from: PascalDragon on November 03, 2022, 07:35:52 am ---
--- Quote from: y.ivanov on November 02, 2022, 08:43:50 am ---
--- Quote from: marcov on October 31, 2022, 07:48:23 pm ---The contents of that branch is what has been added to trunk.
KVM simply is an abstraction for Keyboard Video and Mouse, which gets a bit more complicated in a portable way.
--- End quote ---
Playing around with this for a day, I can see how much work Nikolay put into it. But it's only half baked and will need at least that much more to cover the size of the original library (e.g. Editors.pas not fixed, etc.).
--- End quote ---
Then please report such occurrences.
--- End quote ---
I've got the impression that this is a work in progress.
--- Quote from: y.ivanov on November 02, 2022, 08:43:50 am ---
--- Quote from: y.ivanov on November 02, 2022, 08:43:50 am ---Initially, on Ubuntu, the testuapp broke with RunError(234) on a first keystroke until I included cwstring into the uses clause.
--- End quote ---
That is expected. Unicode handling requires a Unicode manager on non-Windows.
--- End quote ---
Perhaps, It should be noted somewhere. At least, I noted it here in the forum.
I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?
Because IMO revamping to full Unicode will be easier. Without the vast array of $IFDEFs.
marcov:
--- Quote from: y.ivanov on November 03, 2022, 08:34:24 am ---Perhaps, It should be noted somewhere. At least, I noted it here in the forum.
I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?
--- End quote ---
If you mean the cwstrings, that is not for compatibility with non unicode. That is because enabling unicode by default links to libraries that makes copying simple binaries from system to system more difficult.
alpine:
--- Quote from: marcov on November 03, 2022, 09:10:16 am ---
--- Quote from: y.ivanov on November 03, 2022, 08:34:24 am ---Perhaps, It should be noted somewhere. At least, I noted it here in the forum.
I'm considering my scenario as quite specific - text UI program for non English speakers via remote terminal. Judging by the name, Nikolay is my fellow countryman and I don't know how many others like us have the need to use FV. Is there such a demand? How many of the potential users will require compatibility with the non-Unicode TV?
--- End quote ---
If you mean the cwstrings, that is not for compatibility with non unicode. That is because enabling unicode by default links to libraries that makes copying simple binaries from system to system more difficult.
--- End quote ---
Since I'm trying the Unicode version of FV the cwstring was required to setup the widestring manager, particularly for the UpCase() call at menus.inc:750 which broke at the first place. That was a quick one.
My question for how many of the users will require compatibility with the non-Unicode TV was because keeping the FV that way (with $IFDEFs and WriteBuf/WriteLine) mixes UnicodeStrings with PShortString, i.e. imposes wacky deref macros (?!) and things like that. Revamping with classes instead of objects and managed strings instead of PShortString will simplify everything. But it will break the TV compatibility.
marcov:
I fully agree (classes, strings, exceptions and e.g. resource based forms loading to replace the current cumbersome chained method calls).
But since that would be such massive break, it would make more sense to put it next to FV (e.g. with a certain prefix, name all functions FVNG.dialogs etc) rather than doing it in the FV codebase.
Navigation
[0] Message Index
[#] Next page
[*] Previous page