Hi folks,

I am new to Lazarus, and still learning the ropes, so I am probably missing something. I am porting a component suite, and I while the runtime packages migration went very smooth the design time packages, no surprise, have to be largely rewritten from scratch.

I am trying to figure out how to obtain TIDesigner from TPersistent? If the TPersistent is component it is straight forward:

  Temp := GetPersistentReference;
  if Temp is TComponent then begin
    AComponent:=TComponent(Temp);
    Designer:=FindRootDesigner(AComponent);

However I am writing editor for a class type property, and need to obtain the designer for it. In Delphi the designers are always available in the property editor. How to get the designer in Lazarus for a TPersistent inherited class properties. How to do that?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080621/d22a370d/attachment.html

Designer:=FindRootDesigner(PropertyHook.LookupRoot);

Keep in mind that there is not always a designer.

Mattias

Hi Mattias,

Thank you! I have also found another work around in my properties, but this will help. What are the reasons for so many differences in the Design time interfaces from Delphi ? Are those legal or technical issues? I also notice that there is practically no usage of Interfaces. Is this because of the strange way FPC works with interfaces (what they call "optimization"), or some other reason?

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Delphi changed their design time API often and the IDE works different than Delphi. IDE compatibility was never the goal.

Are those legal or technical issues?

Both.

I also notice that there is practically no usage of Interfaces. Is this because of the strange way FPC works with interfaces (what they call "optimization"), or some other reason?

There were no interfaces when lazarus was started. There are a few candidates, where interfaces could be more useful than classes. Maybe they will change eventually.
IMO Delphi used interfaces mainly because of licensing issues, closed source, patents, dll hell.

About "FPC optimization":
I'm happy that the FPC team does not do Delphi compatibility at any cost.

Mattias

Boian Mitov wrote

Thank you! I have also found another work around in my properties, but this will help. What are the reasons for so many differences in the Design time interfaces from Delphi ? Are those legal or technical issues? I also notice that there is practically no usage of Interfaces.

Interfaces came later. Both in Delphi (D4) and FPC (2.0)

Is this because of the strange way FPC works with interfaces (what they call "optimization"), or some other reason?

Interfaces work fine. Even horrible interface abusing stuff like DECAL has worked for ages.

However your problems touch one of the cores of Delphi compability, if somebody abuses something in _one_ delphi version, and it works, does that mean that FPC has to carry that Delphi bug indefinitely, and let performance suffer? I think not.

Hi Mattias,

Thank you! A bit closer IDE integration will surely help us maintain components both for Delphi and Lazarus ;-) . We do support D5-2007 and we are aware of the changes overtime.

Unfortunately the "optimization", I have renders the Interfaces virtually useless in Lazarus :-( . The lifespan of the interfaces is now unpredictable and left for the optimization to decide, and that allows for only limited types of objects to be maintained trough Interfaces. Anything that relies on resources other than memory practically will be dangerous to be used trough interfaces similar to the issues in the GC environments :-( . Sad, considering the enormous power interfaces offer in Delphi.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I still stand by my statement that this so called "optimization" is a design bug in FPC. Of course this is just my opinion, and you guys can disagree. That is no problem, as long as there are work around etc ;-) . Only the time will tell who is right. My prediction is that the so called "optimization" will lead to so many problems overtime that at some point it will be removed, and the interfaces will start working as they in all other languages I have used, or nobody will use Interfaces in FPC, but I may be wrong ;-) . We will see :-D .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

I mean a bit more Delphi similar implementation.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Boian Mitov wrote

I still stand by my statement that this so called "optimization" is a design bug in FPC.

For which you provided no prove than a non applicable statement in the C++ spec (which dealt with compiler generated temps)

Of course this is just my opinion, and you guys can disagree.

Which in itself would be ok, but then please don't try to bring it up in each and every unrelated discussion.

That is no problem, as long as there are work around etc ;-) .

Move the relevant code to a local procedure.

Another failure in providing some evidence. We can't change behaviour like this on emotion.

Since there is a simple workaround (move the relevant block to a local procedure that declares the interface reference), I think this is a _little_ bit exaggerated.

The lifespan of the interfaces is now unpredictable

"implementation defined" is the word you are looking for.

Sad, considering the enormous power interfaces offer in Delphi.

Hmm, I never was that happy with the ref counted interfaces. An interface and pseudo garbage collection are two different things IMHO.

What did you use so far? DOS batch files? Maybe listen to things people tell you.

Something to cheer you up guys ;-) . Here is a snapshot of our current progress. You can see that all the runtime libraries are already ported and recompiled, and the OpenWire design time basic functionality is mostly operational:

http://www.mitov.com/LazarusProgress.jpg

The PlotLab and SignalLab are fully 100% functional ;-) . AudioLab and VideoLab are ~80% ready too, missing only the platform specific capture and recording/playback components. We are looking at GStreamer for the Linux side, but we will see...

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Outdated, but shows some of the history. Sorry, haven't updated it in the last few years ;-) .

http://www.mitov.com/My_Resume/my_resume.html

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

The list of platforms we currently support:
a.. Delphi 5
b.. Delphi 6
c.. Delphi 7
d.. Delphi 2005
e.. C++ Builder 5
f.. C++ Builder 6
g.. BDS 2006 / Delphi 2006 / C++ Builder 2006
h.. Turbo Delphi 2006
i.. Turbo C++ 2006
j.. Delphi 2007
k.. C++ Builder 2007
l.. RAD Studio 2007
http://www.mitov.com/html/videolab.html

Probably I do have a bit of experience with different environments after all :-D .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Sorry, this is the full list:
a.. Visual C# 2005
b.. Visual Basic 2005
c.. Visual C++/CLI 2005
d.. Visual J# 2005
e.. Delphi 5
f.. Delphi 6
g.. Delphi 7
h.. Delphi 2005
i.. C++ Builder 5
j.. C++ Builder 6
k.. BDS 2006 / Delphi 2006 / C++ Builder 2006
l.. Turbo Delphi 2006
m.. Turbo C++ 2006
n.. Delphi 2007
o.. C++ Builder 2007
p.. RAD Studio 2007
q.. Visual C++ 6.0 (MFC)/Win32
r.. Visual C++ 2003 (MFC)/Win32
s.. Visual C++ 2005 (MFC)/Win32

t.. Lazarus is comming (Win32/Win64/Linux)
With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Outdated, but shows some of the history.

Everybody is free to post any page on the web.

I guess, you don't believe it ;-) . Everybody is free to believe or not. Our products however are real and available for download, and are free for non commercial purposes. If you have any doubt, you can always check, and see that they do exist. And they use interfaces to both work with the Delphi OTA, and to control DirectShow graphs, and other Windows API interfaces. We also have a library for OPC, but it is not officially released. OPC is also COM based. The libraries also employ interfaces heavily to deliver buffers, and perform thread synchronization.

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Interfaces are used extensive in MSEide+MSEgui - the non reference counted Free Pascal "Corba" interfaces which Delphi does not provide. There were many workarounds necessary to let MSEgui compile and work with Delphi...

Martin

2008/6/22 Boian Mitov :

Unfortunately the "optimization", I have renders the Interfaces virtually useless in Lazarus :-( . The lifespan of the interfaces is now unpredictable and left for the optimization to decide, and that allows for only limited

Could you elaborate on this 'optimization' difference between FPC and Delphi's Interfaces? I thought they work the same, but then I don't use Interfaces much yet, but plan too.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Check bug report 0011503

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

Please read Jonas's explanation on fpc-devel:
http://lists.freepascal.org/lists/fpc-devel/2008-June/014005.html

Vincent