FredS

Start with this, I pulled that out of more complex code but haven't tested it: //MMWIN:MEMBERSCOPY unit _MM_Copy_Buffer_; interface type TThreadHelper = class helper for TThread public /// <summary> /// Will handle all Wait Key, Mouse and Message Inputs, also calls Synchronize as needed. /// </summary> function StartAsync: TWaitResult; end; implementation function TThreadHelper.StartAsync: TWaitResult; var LHandles: TArray<THandle>; Rsl : Cardinal; const cObjects = 2; begin Assert(TThread.CurrentThread.ThreadID = MainThreadID, 'Must be called from Main Thread'); Self.FreeOnTerminate := False; SetLength(LHandles, cObjects); LHandles[0] := Self.Handle; LHandles[1] := SyncEvent; self.Start(); try repeat Rsl := MsgWaitForMultipleObjects(cObjects, LHandles[0], False, INFINITE, QS_ALLINPUT); case Rsl of WAIT_FAILED: Exit(TWaitResult.wrError); WAIT_TIMEOUT: Exit(TWaitResult.wrTimeOut); WAIT_ABANDONED_0 .. WAIT_ABANDONED_0 + cObjects: Exit(TWaitResult.wrAbandoned); WAIT_OBJECT_0 : Result := TWaitResult.wrSignaled; WAIT_OBJECT_0 + 1: CheckSynchronize(0); WAIT_OBJECT_0 + cObjects: Application.ProcessMessages; end; until (Rsl = 0); finally self.Free; end; end; end.

Either write a method which uses MsgWaitForMultipleObjects and also calls synchronize `WaitAsync` or something like that, or just use a short timeout for `TTask.Wait` and call `Application.ProcessMessages` while not terminated..

@Mahdi Safsafi Might be simpler to just redirect System.GetMemory instead of the memory manager's GetMem which is called by other methods doing a reOutOfMemory check themselves.

Unfortunately this means that in the next delivery no one will tell me if my shirt, a critical part of the outfit, has changed functionality 🙂

That should be doable by August 1st.. /s

I believe that falls under the 'new feature' category 🙂 Can connect, but have a valid cookie. I've had issues before with the login server they use/share..

One has to appreciate that the DOS installation of 'Patch 2' truly 'empowers application developers' 🙂 All that's missing is deployment via floppy disks..

How could they know you where going to do that 🙂 Sorry, couldn't help myself..

Developing Delphi with Delphi was a reasonably good guarantee of that..

Could be, certainly there was a window of opportunity with the Community Edition.. however that dimmed quickly as bug reports spiked and waited.. still waiting..

Pretty simple answer on SO `{.*?}`.. looks good to me unless Lazy and Greedy become a Feature: https://quality.embarcadero.com/browse/RSP-15402

Yet a good chunk of users with subscriptions are sticking with Berlin or even earlier.. certainly since 2015 debugging and related issues are worse/dangerous.. just a few days ago I saw `ReportMemoryLeaksOnShutdown` fails in 10.4 with Patch.. surprise.. never mind the ongoing saga of users unable to move their paid versions to new hardware..

You're like Superman.. faster than a speeding bullet 🙂 Thanks. Perfect!

Thanks, Works for me.. Unfortunately when I turn on MadExcept 'Instantly Crash on Over/Under-Run' I still get exceptions: DUnitX - [DUnitX.TestDFX.exe] - Starting Tests. .E.E.E.E.....E.E.E.E.. Tests Found : 11 Tests Ignored : 0 Tests Passed : 3 Tests Leaked : 0 Tests Failed : 0 Tests Errored : 8 Tests With Errors uTest.TDDetours.Test1 Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 uTest.TDDetours.Test2 Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 uTest.TDDetours.Test3 Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 uTest.TDDetours.Test4 Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 DFX.Win.Hooks.DUnitX.Tests.THooksTests.TestHookPublicMethod Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 DFX.Win.Hooks.DUnitX.Tests.THooksTests.TestHookPublicVirtualMethod.UseRtti Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 DFX.Win.Hooks.DUnitX.Tests.THooksTests.TestHookPublicVirtualMethod.UseMockup Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000 DFX.Win.Hooks.DUnitX.Tests.THooksTests.TestHookPrivateVirtualMethod Message: Access violation at address 0000000067104A2F in module 'madExcept64.dll'. Read of address 0000000000000000

Hi, After implementing v2.2 and executing my own DUnitX tests I get a Memory Leak in Berlin. I can reproduce this with Sydney and MadExcept, oddly no Memory Leak by simply setting `ReportMemoryLeaksOnShutdown := True` in Sydney.. In addition, turning on MadExcept Leak Test causes exceptions.. These changes where made to uTest to duplicate the issue: var TDDetoursTrampolineAdd: TAdd = nil; procedure TDDetours.Setup; var LTransaction : THandle; begin ReportMemoryLeaksOnShutdown := True; LTransaction := DDetours.BeginTransaction; TDDetoursTrampolineAdd := InterceptCreate(@Add, @InterceptAdd); DDetours.EndTransaction(LTransaction); end; procedure TDDetours.TearDown; var LTransaction : THandle; begin LTransaction := DDetours.BeginTransaction; InterceptRemove(@TDDetoursTrampolineAdd); DDetours.EndTransaction(LTransaction); end; allocation number: 11072 program up time: 1.07 s type: GetMem address: $2c9f820 size: 24 access rights: read/write main thread ($b74): 671a5da7 madExcept32.dll madExceptDbg 1743 GetMemCallback 0041463e Test.exe System 39806 GetMemory 006e4ce1 Test.exe DDetours 2595 BeginTransaction 006ab856 Test.exe DUnitX.TestRunner TDUnitXTestRunner.Loggers_TeardownTest 006e5836 Test.exe uTest 100 TDDetours.TearDown 006ab0ca Test.exe DUnitX.TestRunner TDUnitXTestRunner.ExecuteTestTearDown 006aadc7 Test.exe DUnitX.TestRunner TDUnitXTestRunner.ExecuteTests 006aa37e Test.exe DUnitX.TestRunner TDUnitXTestRunner.ExecuteFixtures 006aa3ab Test.exe DUnitX.TestRunner TDUnitXTestRunner.ExecuteFixtures 006aa010 Test.exe DUnitX.TestRunner TDUnitXTestRunner.Execute 006ee2ca Test.exe Test 48 initialization 7507343b kernel32.dll BaseThreadInitThunk memory dump: 02c9f820 34 0c 00 00 30 0e 00 00 - 9b 9e 73 f3 50 f8 f2 e9 4...0.....s.P... 02c9f830 9a 53 61 bd 93 e4 94 be

I did, but I don't actually know what TWaitFor does.. I can tell you that the code you posted has a chance of being stuck not synchronizing.

For a quick test replace that with `CheckSynchronize(10)`. Optimal would be a MsgWaitForMultipleObjects waiting on Thread or Process Termination and the SyncEvent while handling messages.

What does that do?

@Anders Melander Yup, certainly no issues not already reported except maybe that the History list box is all black and can't be used.. since I haven't seen this reported I'm not sure if its W7 or RDP.. All in all RDP'ing is better out of the box in 10.4, 10.3 was useless without a fix from Andreas..

It's faster especially when you are only enumerating folders.. To do a real test one would have to access remote ADMIN$ shares, something like a 2012 server or newer with a huge directory tree.. Run a few of those on Azure and run them simultaneously (multi-threaded).. but not in 10.4 .. being able to retrieve the data in large chunks makes enough of a difference..

That would work if bugs found where actually fixed instead of disappearing into the internal pool of darkness..

After a couple of clicks on components the structure window no longer follows your selection. Right about then I realized that the structure window 'Find' control comes from DDevExtensions (@AndyHTech).. 🙂

I've seen it as a hint 'LSP has stopped working' or something similar. Only in one unit so far.. apparently new declarations in Winapi.Windows for some structures duplicated JwaWindows and that did it. ErrorInsight fails when you alter something and Codeinsight breaks after a couple of debug sessions.. But the most annoying is the keyboard.. maybe its because I'm trial running on an Unsupported OS (Windows 7) 🙂

This works fine, and I also use a home rolled method using FindFirstFileEx. As for multiple threads, I did that test a while back and it didn't show any better time.

That part sounds fair enough to me.. More troubling is that the New Embarcadero Licenses and Download Portal still has no method of handling license bumps as outlined by the post above yours. As it sits now I can be responsible and burn an ISO or make backups but I can't find a legal way to move my installation..