Hi,

Michael Van Canneyt marked my bugreport 10465 with "won't fix", I would like to discuss the issue in a broader forum.
With fixes_2_2 rev. 9006 FPC does not stream published component properties where the component has CsSubComponent set if the property component is not owned by the streamed component.
Delphi streams CsSubComponent properties independent of ownership. Caused by this change some properties of MSEgui components will be deleted if MSEide is compiled with fixes_2_2 >= rev 9006, the users will loose data. Sometimes I use in MSEgui components as worker objects in other components which should behave as simple TPersistent descendants and not be integrated in the ownership system. I achieve the wanted behaviour by creating them with a NIL AOwner parameter.
An example is tsocketclientiochannel where I use a tifisocketclient component with CsSubComponent set in order to implement the socket functionality and to allow the user to do the socket settings by the object inspector of MSEide. Michaels change now forbid this method although it is completely legal in Delphi.

Now I have several possibilities:

1. I can accept Michaels verdict and surrender to use my programming method and rewrite the affected MSEgui pieces and introduce an incompatibility with current MSEgui projects.

2. I can spend some hours or days and try to convince Michael that he should allow some more freedom how to use his components.

3. I can fork on classes.pp level. No problem for me but no fun for MSEgui users who want to combine MSEgui components with foreign components.

What shall I do?

Martin

What was the reason for the change?

The reason is that Delphi-compatible cannot handle references to subcomponents. This 'bug' was fixed during systems by me and Mattias Gaertner.

In particular:

Consider the ActiveControl property of TForm.
The Lazarus TButtonPanel component has buttons as subcomponents (OKButton, CancelButton etc).

When the ActiveControl property of the form is set to one of these buttons, then the old, delphi-compatible code would stream the whole OKButton as ActiveControl.

This is of course wrong, only a reference to OKButton should be streamed. This is a bug in the Delphi streaming mechanism: it cannot correctly handle references to subcomponents.

The OKButton should only be streamed as part of TButtonPanel, not when some other component references it. The bugfix makes sure this is so, by checking the owner of the subcomponent: if this is the same as the instance being streamed (the ButtonPanel instance in this case), then the subcomponent is streamed, otherwise a reference is streamed.

All Martin has to do is make sure his subcomponent is owned by the component it is a subcomponent of, and his code will function correctly. Since his sample code uses nil as owner, this is a minor
- and Delphi-compatible - change IMHO.

Michael.

There is no incompatibility:
Just replace the Nil with the owner. Your code will function as it was.

The Owner-Owned relation is in no other location used during streaming, so you should not worry about that.

Michael.

BTW.

I have Delphi code that shows the bug, if you want, so maybe Martin can submit a bugreport at Codegear for a change :-)

Michael.

This is a misuse of csSubComponent.

Suggestion:
Check for (owner=nil) and stream the properties of csSubComponent's if the check returns true.
So Lazarus and MSEide+MSEgui are happy! :-)

Martin

:-)
And that is the reason why I *have* to worry about. MSEide+MSEgui depends on the streaming mechanism. There are some issues with IDE property streaming you can't know until you tried to develop something like MSEide your self. I wish you were more constructive on solving problems of your "customers" or you risk that your library will be forked.

Martin

What is the misuse? That you may not set a reference to a csSubcomponent?

Vincent

Vincent Snijders wrote

What is the misuse? That you may not set a reference to a csSubcomponent?

Yes.

Martin Schreiber wrote

On Monday 24 December 2007 09.29:24 Vincent Snijders wrote: > What is the misuse? That you may not set a reference to a csSubcomponent? > Yes.

You cannot do that in Delphi?

Or can you do that in Delphi, but it has been documented you cannot do that?

Or can you do that in Delphi, but there has been an aknowledged bug report that it should be disallowed?

Vincent

A question of design style.
No problem, simply add the NIL check and all are happy.

Martin

I have Delphi code that shows the bug, if you want, so maybe Martin can submit a bugreport at Codegear for a change :-)

It's a dilemma. Though scientifically Delphi's mechanism is wrong but we can't just 'fix' it, especially if there are lot of codes that depend on it, or if Borland/CodeGear let the bug exists on purpose (backward compatibility?). The fix will break the Delphi 'compatibility'.

I suggest FPC to keep the Delphi compatibility to be as much as possible, or even 100% if possible. BUT, keep those compatibilities on Delphi mode only. That's what Delphi mode is all about, right? FPC could use the better/correct mechanism on and only on FPC mode.

This should make everybody happy. User wants to use the 'wrong' Delphi mechanism? Fine, but please use Delphi mode. User wants to use the correct mechanism? Please use FPC mode.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

What's the option? Keeping a bug forever?

Please add the suggested NIL check.
"
{ Subcomponents are streamed the same way as persistents } if ObjValue.InheritsFrom(TComponent)
and ((not (csSubComponent in TComponent(ObjValue).ComponentStyle)) or
(TComponent(ObjValue).OwnerInstance) and
(TComponent(ObjValue).Owner nil)) then //23.12.07 mse

            begin

"

Martin

That can only work for language issues, not for rtl issues (especially since units compiled in different modes can be linked in the same program).

Jonas

That can only work for language issues, not for rtl issues (especially since units compiled in different modes can be linked in the same program).

IFDEF? If IFDEF is not possible, then we should make it possible. ;)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

That does not change anything to what I wrote above.

Jonas

Or add a check for NIL owner. So if the owner of the component property is the streamed component or NIL, the component properties are streamed, otherwise the reference is streamed.

"
procedure TWriter.WriteProperty(Instance: TPersistent; PropInfo: Pointer); [...]
          { Subcomponents are streamed the same way as persistents }           if ObjValue.InheritsFrom(TComponent)             and ((not (csSubComponent in TComponent(ObjValue).ComponentStyle)) or
                 (TComponent(ObjValue).OwnerInstance) and                  (TComponent(ObjValue).Owner nil)) then //23.12.07 mse             begin
"

Martin

This I can live with. It will solve your problem.
I'll implement it as soon as we have the SVN server working again.

Michael.

Doh! This is true for any library's functionality.

I wish you were more constructive on solving problems of your "customers" or you risk that your library will be forked.

Threatening us doesn't really improve your chances of being helped.

I still don't see why you can't assign Owner? You will have to free that tifisocketclient in tsocketclientiochannel anyway.

Micha

I seem to have missed the original mail from Martin, probably due to the crash of idefix. (the Free Pascal main server)

Let me just reply that we are being very constructive, in my opinion, for the following 3 reasons:

1. The "problem" is in Delphi, not in FPC. I have code to demonstrate this. We could just take that position and do nothing. We did in other areas.

2. I have at once proposed a solution to your problem. I have not seen you giving a reason as to why you didn't want to use this solution, the answer from Micha seems to imply that there wasn't any reason given. But I seem to have missed mails, so I'll leave have solved the problem in a way that should satisfy your needs, as soon as this was possible.

But being constructive doesn't mean that the FPC team just should instantly accept any proposal from any bozo out there. Each proposal is judged on its merits, without regard to its origin. Yours included.

Seeing also that I (and others) sacrificed my (our) christmas days fixing the crashed FPC server, and having fixed the "bug" as soon as that was done, I think that any accusation of "not being constructive" is highly misplaced, and doesn't do anyone credit.

Nevertheless, I wish you a happy new year, and many new users for a bugfree MSEide+MSEgui in 2008.

Michael.

Micha Nelissen wrote

I still don't see why you can't assign Owner? You will have to free that tifisocketclient in tsocketclientiochannel anyway.

Because it should not be integrated into the ownership/loading/loaded system in this case. There are other reasons for other components I don't remember exactly at the Moment. There was something with inherited submodules (MSEgui TFrame equivalent) and restreaming of inherited forms IIRC. I think the suggested and now implemented NIL check is a good solution and we don't need to argue further. :-)

Martin

Thanks, I wish you and the FPC team the same for FPC/Lazarus. :-))

Martin