FredS

To be clear, I use 'Bash on Ubuntu for Windows' and can access from the Host machine to my Hyper-Vm using that IP.

If your Host machine has a single NIC then you may need to get the IP from the Hyper-V virtual Ethernet adapter to reach your machine. If that is the case the bottom panel has three tabs, the networking tab will have the VMs IP after it has been started.

Believe I did that years ago.. not sure if via email or Google..

Think I tried that before and moving existing documentation failed. Just tried again and same.. It does appear to work when I add new documentation, however there are these caveats:

This breaks at times, has for different releases depending on code and debugging for a long time.

Priceless 🙂

Nothing, but in the past too many directives where bad for the health of Error/Code insight.. sure that's much improved now 🙂

function CompleteEval(const Values: array of Boolean): Boolean;

It won't work without DDevExtensions in a plain IDE, new feature I guess 🙂

I know DDevExtensions has it with a double-click by adding a hidden registry key..

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