Compilation problem after CONST translation

All announcements, questions and issues related to the TsiLang Components Suite.
Post Reply
MainSoft
Posts: 52
Joined: Mon Feb 14, 2005 9:18 am
Contact:

Compilation problem after CONST translation

Post by MainSoft »

Hi again,

Sorry but I have another one to report.

I have a unit A with no form containing a big CONST section. Only a part of the strings declared there have to be translated. So I deleted the non translatable strings in the editor and generated the code from TsiLang Expert. Since the unit has no form, I used my main form as a target.

In unit A, declarations like
scLangId = 'langid';
were changed to
scLangId : string = '';
while the following code was added to my main form

scLangId := siLang.GetTextOrDefault('strscLangId');

However, this didn't compile because in unit A, these declarations were still residing in the CONST section. So the statement above could not compile because the left member cannot be assigned (it's a CONST).

The problem was solved by manually moving the offending declarations in unit A from the CONST section to a VAR section. However, this should be done automatically

Regards.
Patrick Philippot
www.mainsoft.fr
isiticov
Site Admin
Posts: 2383
Joined: Thu Nov 21, 2002 3:17 pm

Post by isiticov »

Thank you for your report.
If we would move automatically strings from declration places this may cause a lot of problem for all of us. Adding {$J+} compiler directive at the beginning of the unit or activating "Assignable typed constants" compiler option for project would solve the problem without moving anything.
MainSoft
Posts: 52
Joined: Mon Feb 14, 2005 9:18 am
Contact:

Post by MainSoft »

isiticov wrote:If we would move automatically strings from declration places this may cause a lot of problem for all of us. Adding {$J+} compiler directive at the beginning of the unit
Correct. Actually, it is just necessary to bracket the modified declarations with a {J+} / {J-} pair, which could be done automatically. However, the current state of the $J directive should be taken into account, which might complicate matters somewhat.

Thanks.
Patrick Philippot
www.mainsoft.fr
Post Reply