Hallo Fred van Stappen,
vous ecrit au Fri, 3 Jun 2022 10:58:40 +0000:
> > Additionally, I'm afraid that it will not be easy to adopt the "old"
> > code to the requirements of the new compiler.
>
> Imho the "old" code does not use "direct typecast" so it should not
Well, I checked it, and found that it DOES use such typecasts. At
least, using it for translations "may provoke" the implementor to do
so, as I found done adopting your "podemo" project. I got it to work
with both lines of code, even with quite limited modifications needed.
> be problems. I did try to use the mseconst.pas from the last
> mseide-msegui Github + fpc 3.3.1 for applications that dont use
> "-dmse_dynpo" parameter and it compile + run without problems.
Depends on what specifically you used for testing. I found the need to
adapt a couple areas in "msestockobjects", but probabely mostly just
places where the conditional compilation statements were "misleading".
Vous ecrit au Fri, 3 Jun 2022 11:57:47 +0000:
> I checked your code and there is only very few things to change.
>
> Here your code lightly changed to be compatible with "old" static way
> (that uses units vs po/mo files). The code folows because mailing
> list dont allow attachment:
That's interesting, as I found the two lines nearly incompatible when I
tried to adapt your - probabely meanwhile outdated - "podemo" project
to compile with either version.
But apart from a mild chaos caused by the line break algorithm, what
you sent is exactly what I provided, less a couple commented-out ifdef
statements. But this didn't work for me - I had to make some
adjustments to be able to access all the variables used for
translations, and being about that, I sorted the stuff, at first
putting the statements in two files according to the code line they
belonged to. This resulted in two nicely distinct include files, with
hardly anything in common except the literal strings themselves.
Which made for a dilemma: separating the code lines duplicates the
string constants, while keeping the string constants together requires
a host of conditional compilation statements, i.e. one per array, and
at very different places. Nevertheless, I now decided to single out
the string arrays, using macros for their definition headers that are
defined as required for the code line used. That's the version you can
find on my web site as usual, and it works for me. So now, there's only
an additional include file containing only one version of the strings,
meant to make maintenance easier.
In addition, I also tried to recompile my "extended" version of your
ideU with the new compiler. I succeeded after a few minor adjustments,
and it seems to work correctly, too.
BUT - doing this, I found a flaw in the new fpc compiler: it has
aquired problems with overloaded functions.
I had defined a bunch of such in the "mo4stock" unit, namely the
"addApplicationStrings" functions, three of them, with different
parameter lists and result types. The first two of them have the same
number of parameters, but of differing types, and they differ in result
type. The compiler complained about my usage of the variant defined
first, but accepted (and required) the one defined in second place.
This looks like the compiler writer(s) "simplified" the symbol-mangling
code to a state where it only counts parameters, disregarding their
types, and thus can no longer discern between functions with the same
number of parameters. Strange thing, this, and if that can be
confirmed, it should be reported as a compiler bug.
But anyway, altogehter there are a couple (rather, 3) new files on my
web site for you:
"mseconsts_new.zip", "podemo_formscan.zip" and "ideU_mo.zip",
containing the essence of what I described above.
Additonally, the latter two also contain an again updated version of
the "POtoMO" unit, which should now be able to cope with .po files of
any size without falling into an endless loop, because of an updated
heap size calculation function.
BTW: With the current latest version of mo4stock it could be possible
to do away with the "(modalresulttext)noshortcut" array, as it has a
mechanism to adjust the captions accordingly. To achieve that, the
original ("english") caption (msgid) has to be given _without_ the "&"
and the translation has to contain one at the "right" (intended)
position. That way, if the original contains a shortcut (flagged with
a "&"), the one of the translation is kept. If the original contains
none, the one from the translation is removed too. In addition,
defining the "msgid" wholly in uppercase will be matched with any
original caption independent of case. This could perhaps reduce the
number of neccessary entries to the translation file(s) appreciably.
So, that's it for now, I beg your pardon for the long winded
discussion. I hope that it might still be of use for you and that I
could contribute a little to the continued development of
mseide-msegui.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
