Yes, those issues where the excuse needed to move to C# at work. I'm using 1.4.4 to maintain a couple of utilities until a more permanent solution is found. thankfully we are not aggressively replacing everything yet.
So, it was an excuse and there were no real issues. Is that right?
Please switch to Lazarus 1.8.4 for those utilities. Did you even try to solve the Unicode issues? You may be positively surprised if you try.
There where issues, some technical, some marketing, but most of them had to do with hiring new people. The unicode issues were used to demonstrate what happens when you do not follow the main stream and how that affects the bottom line, no support for utf16 was used as an other "off the lines" example since most of the big players are utf16 etc. The technical reasons could be solved but the "off the main stream" taste was too prevalent to be of any help.
Yes I used control as a synonym for object my bad. I don't see the optimization sorry.
I don't know the purpose of that code either. I did not study the code more. Actually this was the first time I noticed that method. It is likely made by Mattias a long time ago.
TControl and its derivatives create lots of private variables. What is the problem with this one particular TFPList?
Its in the wrong place. You never access private variables of other objects, you create a method that will place the control on top of the order and call that, you are not supposed to know anything about the internals of other objects even objects of the same class it is "tight coupling" (sorry can't remember the term at the moment) which is 1) insecure 2) thread problematic (in case of multithreading) 3) hard to track and change in the future. It has so many red flags for me that has me stamped actually.
As far as I remember the only thing I did was to call setbounds at the constructor or onload and the control raised the exception, but better try and find the code before I send you down the wrong path.
Don't do that! Instead override procedure GetPreferredSize() as I told earlier. Your bad again ...
No that's YOUR bad, you mined the constructor with a bad design and even worst implementation, for a feature that is only useful to the IDE. Sorry but that is inappropriate for a library.
For the record, the layout algorith in LCL is more advanced than in Delphi's VCL but it requires more careful coding in some situations.any sort of public guide lines I can consult for what it is expected? I could do a couple of bug reports but I need to know what I'm aiming for.
You suggested Delphi's naming convention yourself which is OK. Otherwise there are no strict guidelines. The public and published interfaces of controls are more or less Delphi compatible. Protected method names may differ because the internals differ from Delphi.
I suggested a clear line, delphi was an example, I was a bit annoyed with the reversed meaning mostly because I dived in blindly and fallen on my face, but that does not mean that there has to be a line let alone compatible with delphi. In any case I will post a request on the bug tracker for a couple of methods I came across and mark it as delphi compatibility and see where that takes us.
You could go with a number of interesting designs (a list of observers that react on the changes of the control) or standard ones (list of event handlers on the OnResize /onmove just like application handlers (Application.AddOnActivateHandler and friends) or even better have a controller reacting on the events that can be replaced for different layouts reducing the executed code to only the pieces needed by the application, you chose the worst, directly call the parent methods.
Any way, I'm off the gui programming for the time being and it will take me some time before I'll be able to spend some serious time on it again.