Carlos Tré

On 1/29/2020 at 2:02 PM, pcplayer99 said:

Abstract classes is not for interface. If you have another reason to using abstract classes you just use it but not for interface.

For example, the framework of Delphi WebService is based on interface, and Delphi DataSnap framework is based on class. I like WebService framework but DataSnap framework.

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.

1 hour ago, Stefan Glienke said:

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem.

Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

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.

Dear fellow programmers,

I'm trying to stick to Nick Hodges advice and keep the code loosely coupled, separating business from presentation, and observing oop principles. In order to accomplish this I:

1) code against interfaces;

2) adopted a sort of MVVM design pattern. Sort of because i don't really understand the difference among MVVM, MVC, MVP, etc. I thought that if I have business logic, view logic and persistence logic in separated units, apart from the views, and fully testable, I'd would be Ok to go;

3) I use Spring4D all around because in the future I want to take advantage of it's dependency injection capabilities.

When it came to implement LiveBindings I stumbled into a problem: in order to create the adapters I need the actual classes, and to make the class implementation details visible in the module I call ViewModel would defeat all the isolation I accomplished so far. The solution I came up with is to keep interfaces in one module, implement them with abstract classes in another codeless module, and inherit from them and writing all the code in a third unit. I could keep the interface and it's abstract implementation in the same unit, both have no code, or separated and add another level of organization.

That said, I kindly ask for your input on the solution I came up with. My goal is to keep Nick happy with interfaces, keep Delphi happy with classes, and myself happy with Spring4D. Is this the way to go or is there a better solution?

Thank you so very much in advance .

Best regards,

Carlos Tré

On 10/8/2019 at 9:52 AM, Jacek Laskowski said:

I'm not sure it's a good lead, but I have an observation related to the MMX suspension.
If just before ctrl+E (entity edition) I press ctrl+S (save changes in files) I have no suspension, and every time MMX suspends Delphi I forget to press ctrl+S.

This may be some kind of key 😉

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

17 hours ago, Uwe Raabe said:

The parsed modules with the types declared are stored per IDE and MMX version in %LOCALAPPDATA%\Raabe Software\MMX Code Explorer\15.0\BDS20_known_modules.xml (for MMX15 in  Delphi Rio). You can inspect that file for the missing type identifiers.

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

On 8/9/2019 at 6:20 PM, Uwe Raabe said:

Can you enable Pre-parse Editor Files and Pre-parse Project Files in General options and see if that helps?

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

1 hour ago, Uwe Raabe said:

In case standard Paypal works, you can send money to my account (use may name or email address) with a quick note and I will add that to the MMX Icon pool.

Done!

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

On 7/21/2019 at 11:53 AM, Uwe Raabe said:

Thanks! There will be some more small tweaks, though. Some things are only visible in context.

 

For all who missed it: The MoneyPool is still open to donations for the icon work. Thanks a lot to all who already spent some money and helped to get where we are now. 

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é

On 12/9/2018 at 3:52 PM, Uwe Raabe said:

Of course: File bugs and feature requests.

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.