Carlos Tré

It was past time I'd come back and share my conclusion. I'm not well versed in OOP, I'm just an old dog — *very* old, btw — and lack the mind sharpness I used to have back in the day. The best I could come up with in order to make the implementation independent was to drop the interface approach completely and go the abstract class way. That better implementation tool or technology waiting around the corner will pose no problem. Also, they tend to be simple classes since they model data entry controls, so they don't require exhaustive testing. Thank you all for the input provided. Best, Carlols

Hi @pcplayer99 Thank you very much for your input. I went on with it just for the sake of my overdoing things impetus, and it worked all right. But, in the end, I think it's just not worth it, a lot of extra coding to get a hell of a kludge. On the bright side I now have a better understanding of the border separating "creatables" and "injectables". -- Carlos

@David Champion Thank you very much, I'll look into it right away. -- Carlos

I've failed to mention it is for a FMX application, so dataware is not possible. Once again, than you very much for your input, I'll try not to overdo things which, unfortunately, I only notice way down the road.

Hello Stefan. Yes, there is. And I remember you've told so some time ago, when I was toying with REST DataSnap and run into a similar situation. What bothers me is that if I need to create objects for every UI class a great deal of decoupling will be gone. In your opinion, the use of an intermediate abstract class is too much of a kludge or a time bomb just waiting for the worst possible moment to explode in face? On the other hand, thinking while typing this reply, if I skip the interface declaration for UI objects, and stick to abstract classes to hide the implementation details, I'll be as good as, right? Well, they joy of old dogs insisting in learning new tricks, senile moments get in the way mora and more. 🙂 Thank you so much for your time.

I used to have the same problem, but it seems to have gone away after I uninstalled Mitov run time, which I did to solve a problem I was having with TListView in FMX projects - it rendered that component unusable, crashing Delphi IDE every single time I tried. -- Carlos

Thank you very much, Uwe. It did the trick.

Thanks Uwe. Unfortunately it did not. Pre-parse Editor Files was already checked, the only one unchecked was Pre-parse Project Files, now all four boxes in that group are checked. Best, Carlos

MMX 15.0.0.0 Build 2345: When using the add class expert I can no longer have TInterfacedObject auto completed, I'm required to type the ancestor class full name because it isn't listed in the dropdown list. I've noticed this behavior in previous betas as well, and some inconsistency in V14. There I used to get Spring's TInterfacedObjectEx auto completed, and then, I can't pinpoint why, it started offering TInterfacedObject as the first choice. I'm wondering if there's something I could tweak in order to fix that, it'd would save me a lot of time. 🙂 Since we're at tweaks, a suggestion: my OCD compels me to align ":" and ":=" almost everywhere. It would be nice if the checked boxes could be remembered between sessions - at least optionally. Thank you. My best, Carlos

Done! BTW, PayPal didn't accept Uwe Raabe as the recipient, I had to inform the email address.

I've just tried, but couldn't because MoneyPool isn't available in Brazil yet. Any other way I could chip in? Again, thank you very much for your contributions.

Thank you very much for your invaluable service for the Delphi community.

@Uwe RaabeIf you ever come to São Paulo, please let me know. Ifeel like I have to, at the very least, buy you dinner. Thank you very much for all the problems your input has put me back in business. -- Carlos Tré

A feature request then: the align code dialog could allow persistence of the code elements between sessions. I use it a lot, my COBOL OCD compels me to, and almost always the elements are the same. In case you opt to accept donations to fund development, please just let me know. Thank you very much, Carlos

There are no words that can express how thankful I am for your effort, I've always waited for MMX's availability before starting with a new version. So, for now, a big thank you, @Uwe Raabe. Is there any way I can support future developments? Best, Carlos

Thank you very much Uwe Raabe.