Problem with LCL definition

[Kirill]

Hi. I use Lazarus 2.0.10 with FPC 3.2.0. I've encountered a very strange issue. When I don't install ZComponentDesign package all is OK. But when I install it LCL definition is absent in Zeos modules. I have attached screenshot from ZDbcDbLib module. It is not the problem of highlighting because codepage is wrong in this case. I've solved this problem by adding {$DEFINE LCL} into ZeosLazarus.inc. Maybe there is a better solution.

[EgonHugeist]

Hmmmpppff,
nice catch! But yet i have no answer how to resolve what you are reporting. Even if i add the define, the code will never be executed. The IDE just visualizes it would do. If i set a breakpoint to the line, you mentioned, i don't get an halt on the line. On my side the debugger always uses the code which i don't expect. Do you have other findings? Wondering..

[Kirill]

Hi again.

I have expected behaviour (a halt on the line with UTF-8) after the following actions:

1) Adding {$DEFINE LCL} into ZeosLazarus.inc.
2) Manually clearing all lib folders (.PPU and .O files).
3) Compiling ZComponent.lpk
4) Installing ZComponentDesign.lpk

If I do only (1) I’ll obtain your behaviour (only highlighting without executing).

[Fr0sT]

Don't you guys forget that changing components in Lazarus involves rebuilding of the whole IDE? Of course it has its own build options which could use quick compile instead of full rebuild. That's why changed code isn't used in resulting binary

[marsupilami]

Hi. I use Lazarus 2.0.10 with FPC 3.2.0. I've encountered a very strange issue. When I don't install ZComponentDesign package all is OK. But when I install it LCL definition is absent in Zeos modules. I have attached screenshot from ZDbcDbLib module. It is not the problem of highlighting because codepage is wrong in this case. I've solved this problem by adding {$DEFINE LCL} into ZeosLazarus.inc. Maybe there is a better solution.

I might be wrong. But checking for the LCL define is wrong on the DBC layer because we explicitly want it to work without the LCL being present. We explixitly removed the dependency on the LCL from all runtime packages and only kept it in the design time package.

[marsupilami]

I suggest the following change - old:

Code: Select all

    {$IF defined(UNICODE) or defined(LCL)}
    Info.Values[ConnProps_CodePage] := 'UTF-8';
    {$ELSE}
    Info.Values[ConnProps_CodePage] := 'ISO-8859-1'; //this is the default CP of free-tds
    {$IFEND}

new:

Code: Select all

    Info.Values[ConnProps_CodePage] := 'UTF-8';

Reason: It is very very very unlikely to meet a system that really uses ISO-8859-1. Windows never does. WIN1252 isn't ISO-8859-1. It only is very similar. And even if some system would use an ISO codepage, it would be likely using ISO-8859-15 which was introduced for the EURO symbol - 20 years ago.

[Kirill]

I might be wrong. But checking for the LCL define is wrong on the DBC layer because we explicitly want it to work without the LCL being present. We explixitly removed the dependency on the LCL from all runtime packages and only kept it in the design time package.

I suggest the following change ...

Checking LCL definition is currently used in many DBC units. So correcting only my example will not solve the problem. LCL definition is absent after installing ZComponentDesign package. It is present when I don't install it. Adding {$DEFINE LCL} into ZeosLazarus.inc helped me. Let's wait for Michael response if manual clearing of old PPU files helped him too.

[marsupilami]

Checking LCL definition is currently used in many DBC units.

Yes - and it is an error in all these cases. We explicitly removed this dependency. See the corresponding ticket on SourceForge.

So correcting only my example will not solve the problem.

Yes - we need to correct all instances.

LCL definition is absent after installing ZComponentDesign package. It is present when I don't install it. Adding {$DEFINE LCL} into ZeosLazarus.inc helped me. Let's wait for Michael response if manual clearing of old PPU files helped him too.

All this doesn't change the design decision we made: The runtime packages (Core, ParseSQL, Plain, DBC, Component) are to not have a dependency on the LCL. For me this also means that their behavior should not depend on the LCL define. We tried to distinguish between LCL GUI programs and pure Freepascal programs this way in the past. What we really should do is check the DefaultSystemCodePage variable because it will tell us the current codepage in use - even if SetMultiByteConversionCodePage has been called without the LCL being present. A good reason to call SetMultiByteConversionCodePage would be to have an all UTF8 program - even on Windows. The Zeos DBC Proxy Server does exactly that.

[EgonHugeist]

Hi Kirill,

i've been testing various ways last days, so sorry for the late answer. Yet i didn't found a way to catch the lcl define except we would create an extra component package for Lazarus only. Also adding

-dLCL

to the designtime package did not help.

Why i use the define:
1. Lazarus wrongly overrides the DefaultSystemCodePage of FPC. Even if it's nice to have the universal UTF8 available on ever OS's it's neither task of a FrameWork nor a Compiler-IDE to overwrite this variable. That's programmers task. It's a bug from my POV. Of course there a loads of fans of this decision. I'm not in that group. It's getting time for the UTF16 leap of FPC, which in practice make life much more easy (UpperCase/LowerCase, Lengthes etc. just to name some usecases which frequently pop up on the LCL forums), 80% of the LCL downloaders are Windows users. Debugging on Windows (even it's getting better and better) is still a painfull experience. If Windows would ever decide to use UTF8 an A-Codepage LCL+FPC would be the great winner. But that won't happen.
2. There are some encoding/decoding methods missing on FPC 2.6(no WideStringManager iirc).

So i've been trying to cirumvent the LCL bug by using the defines. Now i can't test it anymory because we removed all LCL dependencies. Which was a good decision. Hardly adding the define isn't the solution @all, but removing and let the LCL users alone with the IDE problems, feels not correct too.

@Jan "everything is UTF8" as suggested isn't the solution. The more it's the same bug as LCL did. FPC without Lazarus is doing the job correct.

Yet i didn't touch the keyboard to remove the define tests. I would like to hear what others do think about. Or if others have different findings/ideas.

[marsupilami]

1. Lazarus wrongly overrides the DefaultSystemCodePage of FPC. Even if it's nice to have the universal UTF8 available on ever OS's it's neither task of a FrameWork nor a Compiler-IDE to overwrite this variable. That's programmers task. It's a bug from my POV.

I will not start a discussion what is right and what is wrong here. Programmers still have a choice: Go to -> Project -> Project Options -> Compiler Options -> Additions and Overrides. There you can activate "Use system encoding".

Of course there a loads of fans of this decision. I'm not in that group.

Yes - that is obvious. But I think that we have enough technical reasons for how to go on about this decision rather than needing to be a fan of any decision.

It's getting time for the UTF16 leap of FPC, which in practice make life much more easy (UpperCase/LowerCase, Lengthes etc. just to name some usecases which frequently pop up on the LCL forums),

Please let's discuss this over a beer or something like that. Currently we simply don't have the FPC that you would like to see. Se we have to do with what we have.

80% of the LCL downloaders are Windows users.

Honestly I don't understand how that fact should influence our decision?

Debugging on Windows (even it's getting better and better) is still a painfull experience. If Windows would ever decide to use UTF8 an A-Codepage LCL+FPC would be the great winner. But that won't happen.

Sorry, but I don't understand how this part helps in the decision we have to make.

2. There are some encoding/decoding methods missing on FPC 2.6(no WideStringManager iirc).

Why do we have to support FPC 2.6 on a brand new Zeos? FPC 3.0 is out for more than fife (5) years now. FPC 2.6 has a widestring manager. But I assume the conversion functions are missing because FPC 2.6 didn't worry so much about String encodings. Also FPC 3.0 and 3.2 are mot probably mostly used by now. I think we should focus our supoprt on them first before we think about the support of FPC 2.6.

So i've been trying to cirumvent the LCL bug by using the defines. Now i can't test it anymory because we removed all LCL dependencies. Which was a good decision. Hardly adding the define isn't the solution @all, but removing and let the LCL users alone with the IDE problems, feels not correct too.

We don't need to leave anybody alone. FPC decided to have the DefaultSystemCodePage variable - wether we like that or not. It is around for more than fife years now. We can do good decisions based on that variable. So we don't need to leave anybody alone. Also we don't need to care why the variable has its value. If we really have to support FPC 2.6 (which is 9 years old) why don't we have a failsafe decision there and document it?
This way we can do good support on the compilers that get used by the majority by now (95% of the FPC for Windows downloads are FPC 3.0 and above). We don't need to leave anybody alone.

@Jan "everything is UTF8" as suggested isn't the solution. The more it's the same bug as LCL did. FPC without Lazarus is doing the job correct.

Erm - I didn't suggest to have UTF8 everywhere. I suggested to have the dblib driver use UTF8 as its default. With FreeTDS we can decide to have ISO8859-1 or UTF8. With all other encodings we don't know if they are supported because it is a compile time decison. If we want to preserve user data as much as possible, I simply don't see any system where choosing ISO8859-1 as a default makes sense. ISO8859-1 is meant to be used for western european languages. But there most probably is no OS left that uses it. Windows uses WIN1252. WIN1252 is close to ISO8859-1 but it isn't ISO8859-1. We definitly would loose data in the conversion because WIN1252 supports more characters than ISO8859-1. Most notably the Euro symbol. UTF8 on the other hand gets widely used. If we use it, we preserve user data. It doesn't even matter on which OS the program runs or in which country. The decision is good for Germany as well as for Russia as well as for China. So UTF8 is the choice that is most likely to not break anything. This is why I suggested to use UTF8 in that one place. If you think about unnecessary character set conversions, we should implement support for UTF16 because according to its user guide FreeTDS supports UTF16. If that diesn't work, we should talk to Frediano. I got a change to their UTF8 conversion this way.

For other places in the code we might need other solutions. I didn't check them.

[Kirill]

I have an idea. We can convert LCL define to FPC define in all these places. Seems that it will work fine for FPC greater than 3.0.