Anders Melander

I acknowledge that this is a point of personal preference and I'm not challenging yours but FWIW of all the applications that I happen to have running right now only one does not navigate in tab order: SQL Server Management Studio The remaining all navigate in tab order. Firefox Excel Adobe Acrobat SourceTree ThunderBird Windows PowerShell ISE Delphi

My guess is that you're keeping a reference to one of the outlook items but that doesn't explain why you get the same attachments when you create a new message. Try starting without Outlook running. When you do GetActiveOleObject('Outlook.Application') Outlook should start and when you do VarClear( Outlook ) it should terminate again. Use taskmanager or something like it to verify that the Outlook process has terminated. if everything else fails you could also just empty the Attachments collection after you have sent the message. Ie while (vMailItem.Attachments.Count > 0) do vMailItem.Attachments.Remove(0)

I think they are primarily meant to be used when you're working with COM. For non-COM interfaces I agree that there's little point. Let's say your inner object is itself a wrapper of an external COM object. In order to have the inner object aggregate the external object, using implements, the inner object must implement IUnknown but delegate it's methods to the containing object and this is where I can see a purpose for TAggregatedObject.

Okay but do you create a new mail item for each mail or do you reuse the first one you create?

You've answered the question yourself with your example: Use TAggregatedObject when the inner object is reference counted.

Please show us your code (minimal example). I'm mainly interested in how/when you create vMailItem.

You should probably read some literature on COM in general first. Then the documentation will make more sense: https://docs.microsoft.com/da-dk/windows/win32/com/containment-delegation https://docs.microsoft.com/da-dk/windows/win32/com/aggregation ...but maybe this can help: https://stackoverflow.com/questions/3483680/delphi-how-delegate-interface-implementation-to-child-object FWIW, without having a clue about what problem you are trying to solve, my bet is that you should just concentrate on TAggregatedObject. You very seldom need to deal with TContainedObject.

Yes. That was what I meant. My brain was in Delphi 3 mode You fix it I have nothing to do with that fork. I just wrote the original code. I think that is a problem with Unix vs DOS line endings. I've seen that kind of problem when a file contains Unix line endings. One of the contributors probably has their Git client misconfigured. Or maybe it's your client. The client needs to do implicit LF->CR/LF conversion.

Yes I understood that. What I mean is that you need the other methods from TInterfacedObject to protect against early release. Notably: AfterConstruction and NewInstance. One step closer. This is why you should start with a minimal example so you can eliminate possible sources. Next try to just register the interface/implementation in Spring (without any of the supporting code) and instantiate an instance of IMainDMTEST. Make sure you release the instance before termination (like the unnecessary nilling in my example). You want to make sure Spring isn't holding on to a reference. I can see from your code that you mark IMainDMTEST as a singleton. I don't use Spring but my guess is that Spring holds a reference so it can return the same instance (i.e. singleton) if asked for it. Try with and without AsSingleton.

No. You need those too. They have a purpose. I think you need to start with a much simpler test case. Does it leak if you leave out all the Spring stuff and just do this: var Test: IMainDMTEST; begin Test:= TDMSimulation.Create(nil); Test := nil; end;

As far as I can tell they don't use a package suffix (hence the "103" in the package name)

I think I can count the FMX application I've made on one finger, so I have no expertise in that area, but if FMX controls on Windows have a Windows handle then it could be made to work. My guess is they do not. It could still be made to work without a Windows handle on individual controls but that would require a emulation layer between FMX and the DD components. Not something I have time to write at the moment.

Not tested but I think you need to: Open DragDropDR103R.dpk (the run-time package) Save as DragDropDR104S.dpk Compile Open dclDragDropDR103R (the design-time package) Remove DragDropDR103R from requires and add DragDropDR104S instead. Save as dclDragDropDR104S Compile and Install. Personally I would just get rid of the run time package (and the requires).

That implementation is a bit over-engineered because it tries to handle mixing interface and object references. All you need to do reimplement _AddRef and _Release and stick to referencing the datamodule by the interface. Use TInterfacedObject as an example. There was a thread here earlier this week on that exact topic but apparently it was deleted or maybe got lost when the server went down.

Close enough.