Anders Melander

It actually does but since the installation process is a bit confusing it's easy to miss. After the patch has been downloaded patch2-readme.txt is opened in notepad. The readme states: Yeah. How difficult would it have been to create a simple InnoSetup installer that automated the process completely? Including registering the fact that the patch had been installed: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\InstalledUpdates] "Patch 1"="Patch1 for RAD Studio 10.4 (build 9797)" "Patch 2"="Patch2 for RAD Studio 10.4" Not impressed

Spotted a copy/paste bug in CompilersDecl.inc : const RAD_Rio = 32; RAD_10_3 = 33; RAD_Tokyo = 32; RAD_10_2 = 32 Of course it can't detect capabilities that were introduced after it was written but if you are using those then you must be already using a newer version of Delphi and thus be aware that you need to update the file. I guess it depends on how and what you use it for. Contrary to many other similar version include files this one appears to be forward compatible if you use the capability or XXX_UP symbols; For example even though it doesn't explicitly contain defines for Delphi 10.4 it will define the RAD_10_3_UP correctly on Delphi 10.3 and later: {$IF CompilerVersion >= 33} {$DEFINE RAD_10_3_UP} {$DEFINE RAD_RIO_UP} {$IFEND} Many libraries still use the practice of testing directly against the VERXXX defines, with no fallback, and thus break when a new version of Delphi is released, for no other reason that the shortsightedness of the authors. For example the following is from a well know charting library: {$IFDEF VER330} // RAD Studio XE v12.0 Rio (Carnival) 2018 (v 20.0) 32bit / 64bit / OSX / iOS 32-64 FMX / Android & C++ / Linux 64bit {$DEFINE D3} {$DEFINE D4} {$DEFINE D5} {$DEFINE D6} {$DEFINE D7} {$DEFINE D8} {$DEFINE D9} {$DEFINE D10} {$DEFINE D105} {$DEFINE D11} {$DEFINE D12} {$DEFINE D14} {$DEFINE D15} {$DEFINE D16} {$DEFINE D17} {$DEFINE D18} {$DEFINE D19} {$DEFINE D20} {$DEFINE D21} {$DEFINE D22} {$DEFINE D23} {$DEFINE D24} {$DEFINE D25} {$DEFINE D26} {$ENDIF}

I wouldn't say the future looks good when you're on life support. Naturally Cobol will die for good some day, when the systems using it are finally retired, but I'm pretty sure it will outlive for example JavaScript. Of course this doesn't mean that we should all drop what we're doing and learn Cobol instead. What I meant was that this statement: appears to assume that it's the popularity among "young people" that decides if a language thrives. There's some truth in that, but it's not the whole story. It's ultimately "the grown ups" that decides what tools to use to get the job done. That's why we don't have to rewrite EVERYTHING every few years when a new shiny toy appears.

So I'm guessing the asm it generates uses indexed addressing rather that indirect addressing. Right?

I'm curious; Why would you need that information?

My experience is that in some cases indexed access can be much faster than incrementing a pointer, so I guess "it depends". I'm afraid I can't remember any specific cases.

There are more developers than there are developer jobs. Some will have to take what they can get and use the tools that the job require. That's just the way the world works. Otherwise we would all be astronauts or firemen.

And the only one that knows what it does left ages ago... So it's not even possible to test if the new implementation works the same as the old because nobody knows exactly what or why the old did. Yup. That's what I deal with. Every. Single. Day.

That's just nonsense. I've written plenty of applications in Delphi that applied the MVC or MVP patterns. True, there's no wizard that can, clickety-click, write your template code for you, but it's really not that hard to do yourself once you've decided how to apply the pattern. It makes no sense to insist that one tool should be good for all problems or that Delphi should support all patterns. There are patterns that work well in Delphi but which doesn't fit for example JavaScript. That doesn't mean there's something wrong with JS. It just means you need to use a different pattern.

Nothing is stopping you from doing DI. Why do you need that "in the box"? As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

The book has many (good) points. One of them is that you can't naively solve a deadline problem by throwing more manpower at it; Time=Work/Resources is a meaningless equation. I assume this is what you allude to. However it also points out that you can solve a 2000 man-hour job in less that 2000 hours by allocating more manpower if the job can be split into separate, largely independent, tasks. I think that applies here.

Sure, but how is that relevant? Are you saying that they have enough resources or that more resources will lead to more problems? I'm sure that they have plenty of problems besides resources but surely their ability to solve them isn't improved by this shortage?

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.