@Thaddy,
Can you justify it?
Michal
The code is a mess. There are many (100'ths) of places where during compilation there are unsolved warnings, some of which are very, very nasty to solve afterwards by third party developers that just work with the PPU's. That goes from range checks to string conversions with data loss. If these were just in the visual components as side effect I maybe could live with that but at least the engine and middleware non-visual parts should be completely free of warnings that could be errors. That's because it is database software and I don't want corruption. To summarize: the sourcecode is not very re-assuring to say the least.
Also, the error handling is crude or even missing in places where it matters most: the checks and versioning of some of the third party engines lacks, so everything has the possibility to grind to a halt from which it can not recover. (The above code is a good example if the sqlite dll is wrong 32/64 or 2 vs 3) Causes a permanent hang, even crashed Lazarus during debugging.
Since there is a lot of potential, every now and then I still try it out, but nothing seems to change in the code quality. The authors should start with solving all warnings. Then solve the problems when the third party shared libraries/dll's are not what is expected and make it possible to recover gracefully on the low level side, not my exception handling way up my high-level code.
There's *a lot* more, but these are the most demonstrable and both the main issues have to do with lazy and sloppy coding.
Summary: code quality is bad, exception handling is bad. Ideas are good, execution is sloppy.
And this easy to verify:
By just recompiling the zeos packages. Count the warnings. Count the warnings you don't want to see in database software...
Try to load a wrong dll in the above code by OP and compile ... (save everything first, it can crash Lazarus as well as the exe)
[edit]
Note those range checks should really be solved and are easy to solve:
Most of them are either a variable of the wrong type, but with the same width:
*must* be solved
because of the sign bit. Either adapt the variable type, use an intermediate assignment or typecast.
The string types must be examined and when proven harmless also solved with an explicit typecast or the string type should be changed. Or better: the string types should be explicit. Not "string".
All of this won't affect Delphi compatibility.
The exception handling and subsequent recovery probably requires a re-design.
And please do not use unit wide {$rangechecks off} or {$R-}. I'd like to do that myself, thank you, on a program wide basis.
Although I would allow
{$ifdef fpc}{$push}{$R-}<the code><{$pop}{$endif}
in some rare but not all cases.
As it stands it is feature rich but poorly written software. I like the features. I don't like the code.
It is poorly written because the programmers most certainly are very good.
They just fall into the "I am a programming God, so I know better than the compiler" trap.
Warnings should be solved. If only to make sure the developer has taken a look at what the compiler thinks could potentially be wrong.
And in this particular case the compiler is right most of the time.
[edit2]
Read my later posting on the component editors...
http://forum.lazarus.freepascal.org/index.php/topic,36869.msg246159.html#msg246159 That's a pretty serious deployment issue!.