Javier Tarí

Everywhere but in Delphi, we see MVVM, MC, MVP architectural patterns Everywhere but in Delphi, many techniques as Dependency Injection are common About DI, there is some work out there, but MVVM and such, just doesn't exist All that should come in the box IMO, Delphi programming hasn't changed so much on the latest 25 years. Yes, I program since D1, and before that, since Turbo Pascal 3

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

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

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 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

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

And that's why in a COM-free world we need more capable interfaces: Developed for Delphi With true and working inheritance (or call it extension, if you wish) Always implemented by a Delphi Class and aware of it With methods that can be used anywhere a class method can be used I don't know if anything else is needed

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

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?