Hi

I partly solved 2 old issues
#942: Mis-Aligned components within GroupBox
and
#7671: Components within GroupBoxes are displaced

by implementing Top coordinate offset with user defined values in Delphi converter.

The value is defined separately for each container type (currently TGroupBox and TPanel). I can implement the left coordinate later. A runtime solution would be needed if the same .dfm form is used in both Delphi and Lazarus. I will see that later.

Now I would need some good default values for Top and Left offsets. I know they depend on widgetset and theme but the user can change them if the default is not good for him. Now there is:
TGroupBox.Top + 10
TPanel.Top + 2
Taken from my hat without measuring much anything.

Juha

Isn't +10 the GroupBox's label/caption height in pixels ?

and the +2, something to do with the bezel or the line-around-groupbox width ?

L.

Lukasz Sokol wrote

Isn't +10 the GroupBox's label/caption height in pixels ?

Yes but it depends on widgetset and theme. There is no absolute correct value, or the absolute value should be inspected at run-time somehow.

and the +2, something to do with the bezel or the line-around-groupbox width ?

Yes, there is a border and the coordinates are relative to ClientWidth and ClientHeight. In Delphi they are relative to the total Width and Height. All TWinControl descendants have this problem I am told.

If you have some good default values, please let me know.

Juha

Zitat von "Juha Manninen (gmail)" :

Yes, all Delphi controls I tested use client coordinates relative to the left, top. That means a label put inside the frame of a TGroupBox with a frame width horizontal of 4 and a title height of 20 needs a Left=4 and Top=20.
When the frame width changes the label must be moved. To move it correctly you need the the frame the VCL does
not store this information in the dfm. This is not a big problem for Delphi apps, because they run only one target platform.

The LCL is meant for cross platform development and the frame width vary greatly, especially under gtk and qt. That's why the LCL uses coords relative to the inner frame. A label put at 0,0 stays at 0,0 under MS Windows, Linux, OS X, ... This allows to edit+run a form under various platforms without storing theme information to the lfm.

If you have some good default values, please let me know.

As this problem only rises when opening a dfm produced by Delphi, the offset depends solely on the theme used by Delphi. AFAIK there are not many combinations and only a few controls have child controls and a notable frame. I guess one offset per class will be sufficient for 99% of all Delphi apps.

Mattias

You are still around here Mattias, good!

Now I understood better the reasoning for differences between the coordinate systems in Delphi and Lazarus.
Rigth, it doesn't depend on Lazarus widgetset theme after all.

The remaining question is if there is need for a run-time adjustment in case the same .dfm file is used for both Delphi and Lazarus. There could be code added to FormCreate, enclosed in {$IFDEF FPC}, to move the controls. I will implement it later if needed.

Juha

Zitat von "Juha Manninen (gmail)" :

Yes, there were some busy weeks. Still reading all the lazarus mails ...

{$IFDEF LCL}

I don't know if there is a need for using one dfm by both.

Mattias

Mattias G?rtner wrote

{$IFDEF LCL}

Ok, right.

I don't know if there is a need for using one dfm by both.

People are maintaining projects to work with both Delphi and Lazarus. In pascal source they can use {IFDEFS} but in dfm form files not. I think this component coord offset problem is one of the biggest obstacles to using the same form file. If this problem is solved and only common properties of common components are used on a form, it becomes very realistic to use one dfm file.

Earlier Lazarus posed another problem when it refused to open and show a form file with .dfm ending. It got fixed when my patch was applied some months ago.

Juha

Juha Manninen wrote

People are maintaining projects to work with both Delphi and Lazarus. In pascal source they can use {IFDEFS} but in dfm form files not.

A solution would be building a software which sinchronizes all your DFM / LFM files between Delphi and Lazarus. Working with both IDEs would following the following procedure:

1> Do some changes in the form using Delphi

2> Run the DFM->LFM program

3> Edit the project with Lazarus

And vice-versa.

This program would likely need a kind of project file to have all info and the list of files to be converted readly available.

Just a suggestion.

Felipe Monteiro de Carvalho wrote

A solution would be building a software which sinchronizes all your DFM / LFM files between Delphi and Lazarus.

Hmmm... what is wrong with using the same form file if the coordinate problem is solved?
I don't see any other problems as long as compatible components are used.

The coordinate problem is difficult though because the run-time solution leaves the components in wrong place at design time. In practice all form editing should be done with Delphi then. Not good.

Need to think of it...

Juha

Juha Manninen wrote

Hmmm... what is wrong with using the same form file if the coordinate problem is solved?

I tryed this some time ago and the main problem was that Lazarus wouldn't load DFM's with properties which don't exist. Has this changed?

Also, probably Delphi will throw a runtime error when running a project with DFM properties that it doesn't know.

How did you solve that?

Many such properties are registered with RegisterPropertyToSkip. If you know more properties which are not yet registered, please add a RegisterPropertyToSkip call for them. (You have write access to lcl, I don't).

The properties are ignored by form loader but they are currently also removed by the converter.

Also, probably Delphi will throw a runtime error when running a project with DFM properties that it doesn't know. How did you solve that?

Do LCL controls have many properties that don't exist in Delphi VCL? I think a common subset of properties must be used then.

Juha