Keep D2006 vs Sydney aligned

[shineworld 73]

Hi all.
I'm moving a big project from D2006 to Sydney.

Required changes are very few after few changes in the original sources D2006 files so I can maintain either version.

 

Why that?

D2006 is a killer, all work perfectly and well tested.
I can't say this for Sydney which crashes often, overall during debug.

 

The reason to move is to add support of Unicode.

The program still remains a 32-bit application.

 

But there is a problem.

With source code and very few $DEFINE, I can manage the differences and keep a clean source code.

With DFM, unfortunately, I've found some differences, for example in TLabel.

 

In BDS2006 the TLabel is for default Transparent = False so for any DFM there is not this property value.

In Sydney, the TLabel is for default Transparent = True so the resulting View is very UGLY and needs to manually fix every time.

 

Other object's properties are different.

How to solve this incompatibility?

There is a document that describes differences?

There is a tool to automate the conversions?

I have about 30 views and 40 frames with related DFM...

 

 

 

[Guest]

Could you inherit from TLabel? To avoid IDE packages (not easy if at all possible to maintain between those versions) use interceptors https://zarko-gajic.iz.hr/delphi-interceptor-classes-tbutton-classtbutton/ to change the default value of one version.

You would probably have to work with the dfm's from one version of the IDE only as the other would write down an "incorrect" default value.

 

HTH

[Stano 143]

Amateur solution: recursively search the entire form and set the required

[Lars Fosdal 1792]

You could do a fixup on the forms at runtime for Sydney, enumerating the controls on the forms/frames and set TLabel.Transparent to false?

Do the frames have a common ancestor? 

[shineworld 73]

Frames don't use yet a common ancestor...
This is a very old project grown a lot in years and suffers from my ignorance about Delphi framework features.

Initially converted from an old VB6 program.

I've tried the in-code solution and works.
I already walk the form components in FormCreate to define some properties.
Is ugly, because in view DFM is yet wrong, but during run works.

 

  // sets access levels grid
  AccessLevelsGrid.RowCount := 1 + FSettings.AccessLevelManager.Count;
  AccessLevelsGrid.DoubleBuffered := True;

  // assigns run-time events
  RVSpectraFrame.OnChange := WavelengthChange;
  RZSpectraFrame.OnChange := WavelengthChange;

  // sets components double buffered & transparent
  C := ComponentCount - 1;
  for I := 0 to C do
  begin
    Component := Components[I];
    if Component is TCheckBox then begin TCheckBox(Component).DoubleBuffered := True; Continue; end;
    if Component is TComboBox then begin TComboBox(Component).DoubleBuffered := True; Continue; end;
    if Component is TEdit then begin TEdit(Component).DoubleBuffered := True; Continue; end;
    if Component is TPanel then begin TPanel(Component).DoubleBuffered := True; Continue; end;
    if Component is TTabSheet then begin TTabSheet(Component).DoubleBuffered := True; Continue; end;
{$IFDEF VER340}
    if Component is TLabel then begin TLabel(Component).Transparent := False; Continue; end;
{$ENDIF}
  end;

  // sets custom descriptions grid elements
  UserInputDescriptions.RowCount := I_O.MAX_DIGITAL_INPUTS + 1;
  UserOutputDescriptions.RowCount := I_O.MAX_DIGITAL_OUTPUTS + 1;
  AnalogInputDescriptions.RowCount := I_O.MAX_ANALOG_INPUTS + 1;
  AnalogOutputDescriptions.RowCount := I_O.MAX_ANALOG_OUTPUTS + 1;

I will try with the Interposer class way...

Edited February 19, 2021 by shineworld

[Guest]

Those things (if X is A then, is B then, and so on) are not unseen.

Sure, it does not look shiny because it breaks a lot of principles.

What i mean is there are cases (esp considering legacy stuff) where that solution keeps cropping up and thus one should not categorically avoid it.

 

Good luck!

[Pat Foley 51]

Here is a paper by Marco Microsoft Word - Delphi-and-Unicode_Marco-Cantu.doc (embarcadero.com)

 

What about editing your dfms in a memo.  search for object: TLabel and insert the additional properties with offset.  You just type the control type in one edit box and the offset to insert and property name value pair in additional edit boxes.  when saved makes new improved dfm file. should be able to assign methods  too.  You need to cook your own search and insert coding.       

 

An improvement over the years is the flow panel.  That may help in reducing number of views.     

 

Above is one way to make two way. You edit the dfms and change the objects types to TswLabels  switched when running D10 to set the transparent property.  and just TswLabel = class(TLabel) otherwise.  

Edited February 19, 2021 by Pat Foley
added above

[shineworld 73]

I've made an UGLY program to open programmatically the DFM and apply changes to TLabel, TPanel, and other objects

that changes defaults with some fixed rules linked to my way to design form and seem to works.

The UI result is good, also in grids and panels which was been unviewable before.

Now all works as aspected!

 

Thank you for your suggestions!

 

Edited February 19, 2021 by shineworld

[Pat Foley 51]

Very Good.  I learned something too about default transparency being changed.  I am working on a component that sighs,  moans and grunts when Sydney gives up.

[Attila Kovacs 629]

I'm sure there is a mass property modifier in one of the popular experts.

Worst case, there is always "sed". 🙂

Edited February 19, 2021 by Attila Kovacs

[Fr0sT.Brutal 900]

Hmm, what's the problem in transparent labels? I personally never used non-transparent ones because they look ugly.

14 hours ago, Attila Kovacs said:

Worst case, there is always "sed". 🙂

He has issue with default property value so there's no `Transparent: True` line in DFM; probably sed could handle such nested insert but I suspect the resulting script could summon a daemon in case of any mistake :))

On 2/19/2021 at 10:47 AM, shineworld said:

if Component is TCheckBox then begin TCheckBox(Component).DoubleBuffered := True; Continue; end; if Component is TComboBox then begin TComboBox(Component).DoubleBuffered := True; Continue; end; 

Won't ParentDoubleBuffered help you better?

Edited February 20, 2021 by Fr0sT.Brutal

[shineworld 73]

In D2006 DoubleBuffered is always set to False by default.
Switching between TabSheet there is an ugly flashing paint (for eg).
I've set programmatically the interesting fields to use DoubleBuffered and flash disappears.

I find it bad to program some properties directly on form objects (there are hundreds of objects in a configuration panel someone can be missed).
Also events managers, OnClick, Onxxx, are programmatically added to edit fields, and so on.
My code is a mix of form designer results and code to simplify the design part.

[Attila Kovacs 629]

4 minutes ago, shineworld said:

I find it bad to program some properties directly on form objects (there are hundreds of objects in a configuration panel someone can be missed).

It's not a problem if you use your own TForm descendant as base.

Ofc. it's also a bit work to change everything now.

I did it back to the days to handle some HDPI bugs.

[shineworld 73]

I guess to re-engineering the software after conversion is finished, using templates, more frames to common UI parts...

I was in doubt to move software from D2006 to XE some years ago, then to Rio, and now to Sydney. 

D2006 is a killer environment, with very very few issues, robust and every EXE produced is working without oddities or bugs.

When tried XE I've found a lot of IDE bugs, crashes, etc.

Same with Rio and unfortunately also with Sydney which crashes often during development.

At this point, I need to move to a UNICODE tool, and overall update a lot of used 3rd party libraries that are very old and not keep steps of time.

In these years I have always purchased the outgoing Delphi versions but never used them...

When a thing works why change? was the mainline thought.