Javier Tarí

I don't want to use the automatic scaling; eventually I'll use a customized scaling, so the PixelsPerInch and TextHeight properties are useless to me, and right now they just give fake changes on source control

That's why I'd like to get rid of them

1 hour ago, David Heffernan said:

If you remove PixelsPerInch from the DFM then you'll find that your form layouts break different devs modify forms if their machines use different font scaling (i.e. DPI) settings.

In fact, in my case it doesn't ; I've tried removing it and reopening, and the result was the same. I forgot telling that we have "scaled=false" in all forms

1 hour ago, David Heffernan said:

In my workplace we handle this by requiring all modifications of forms to be made using a common font scaling setting.  

We have 1920x1080 in all monitors (27" to 32" monitors); before it had different font scaling i.e. W7 = 100% , W10=150%; tried changing the W7 to 150% as well, and the result was no visible changes, and no changed either on the PixelPerInch and TextHeight saved values 

Hello,

When you save a form, there are two fake properties saved,  PixelsPerInch and TextHeight. That would be fine, but when making changes on two different systems, one with W7 and other with W10, each saves a different set of values, and that generates false Git differences on the DFMs

We never use TForm in any of our projects, but rather an own descendant, so we can change it if that's needed to remove those fake properties

Both are not true properties; TCustomForm saves them the DFM using this method:

procedure TCustomForm.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer);
  Filer.DefineProperty('PixelsPerInch', nil, WritePixelsPerInch, not IsControl);
  Filer.DefineProperty('TextHeight', ReadTextHeight, WriteTextHeight, not IsControl);
  Filer.DefineProperty('IgnoreFontProperty', ReadIgnoreFontProperty, nil, False);
end;

I can't find any way of avoiding them to be saved on the DFM

Can you help me?

Thank you

1 hour ago, Anders Melander said:

In fact COM explicitly states that (...)

We're missing a main point: COM rules doesn't apply here

The proposal is not about changing the current interface implementation; that one is fine for COM, and for that same reason is not as good as it should be just for decoupling under Delphi, as it just can't implement some every-day features we do have on real life code (ej. Event methods)

The proposal is about having a new and independent breed of interfaces, able to implement the needs of current Delphi

So we forget all and every bit related to COM, and keep the concept and how we Delphians would expect it to work

So we expect using it with generics, and be able to use interface methods as class methods

42 minutes ago, Stefan Glienke said:

Yes! In the COM implementation and it was carried over to Delphi as a feature to make it work.

And that's why in a COM-free world we need more capable interfaces:

1. Developed  for Delphi
2. With true and working inheritance (or call it extension, if you wish)
3. Always implemented by a Delphi Class and aware of it
4. With methods that can be used anywhere a class method can be  used

I don't know if anything else is needed

38 minutes ago, Stefan Glienke said:

"Native Interface" is a terrible name tbh - what exactly would be "native" about it that current interfaces are not.

It's just a name, any name would do. This starting name aludes to the fact that such interface would be implemented by Delphi native classes, and that means a lot, as this way the compiler does not just know a method address, but the object instance. And that gives us full compatibility with anything currently implemented that works with class methods.

On the other side, there is already an embarcadero answer on Quality portal, acknowledging this is feasable, and would work as expected

My knowledge on interface-kind features on other languages is zero, so I wonder if there is something really useful that could improve the kind of interfaces we're suggesting, without making it overly difficult to implement and derailing this train

Does anyone knows of any implementation in Delphi?

Client or server?

Free or commercial?

Thanks in advance

On 1/15/2020 at 11:12 PM, Stefan Glienke said:

I gave up on some MVVM-ish approach for Delphi.

I'm quite convinced to go the MVVM way, but your affirmation stopped me dead. Could you please tell why, so I can also abandon all hope?