Jump to content

Javier Tarí

Members
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Javier Tarí

    Are we just "Cash Cows"?

    Funny enough, LiveBindings seem to fit MVVM or just MVx We didn't had it before, and they seem overkill just to avoid having DBaware components
  2. Javier Tarí

    Are we just "Cash Cows"?

    I found this forum searching for anything related to MVVM and Delphi; there is a Stefan post here where he says something on the line of Delphi MVVM won't work together I have the book; I've read most or perhaps all that is written about MV* and Delphi I'm working with some friends towards MVVM, but time is scarce Delphi programming makes way too easy writing messy code, with iron-clad coupling between interface code and business rules That's a big point against Delphi
  3. Javier Tarí

    Are we just "Cash Cows"?

    No, that's a REST framework; quite good, but not related to MVC UI implementations I don't know where the MVC in the name it comes from And about MVVM, zero Just old posts and such; no working solution at all
  4. Javier Tarí

    Are we just "Cash Cows"?

    You provided a good example of what I'm arguing... Do you mean that in Delphi we don't need MVC, MVP, MVVM and so on? Or perhaps is just that in Delphi we don't have anything like that?
  5. Javier Tarí

    Are we just "Cash Cows"?

    It doesn't matter if you like MVx or not, because with Delphi you can not use ANY of the MVx patterns It does not exist any Delphi framework for MVVM, nor MVC, nor MVP... Zero, zilch, Nil Delphi developer base is... Quite senior And seems between us there is not much interest in these kind of tools
  6. Javier Tarí

    Are we just "Cash Cows"?

    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
  7. Javier Tarí

    Need to Remove the PixelsPerInch and TextHeight fake properties

    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
  8. Javier Tarí

    Need to Remove the PixelsPerInch and TextHeight fake properties

    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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Does anyone knows of any implementation in Delphi? Client or server? Free or commercial? Thanks in advance
  14. 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?
×