dummzeuch

Sh*t I forgot to replace the function name. I guess they have, but that code is from a release a few years old, way before Delphi 10.x. Maybe we should have updated, but given the "fun" I just had with another component update, I decided to simply try and compile the sources.

https://delphi.fandom.com/wiki/Compile_from_Commandline It doesn't explicitly mention anything newer than Delphi 2007, but since the process has not changed, why should it?

Why didn't I think of that?

This is an assertion message in synedit. It only happens if there was another exception before that which prevents that call.

This is awesome! I have tried it with Delphi 10.2 so far (no optOSX64 there) and it worked as advertised. Now I need a break, my head is smoking! (had a bad day on top of that)

By popular request of a single gentleman (*) there is now a button "Ignore All this Session". The exception class name is now also a regex. Empty matches any exception. (* I'm not sure this really carries the meaning of the German joke "Auf vielfachen Wunsch eines einzelnen Herrn ..." )

I'm definitely a bit slow today. I can't make out what the screenshot is supposed to tell me.

From the description I gather that I would have to implement IOTAProcessNotifier90 and hope that CurrentThreadChanged is called often and timely enough to provide the information on time. Might be worth a try.

In that case: Did you file a feature request with Embarcadero? I'm sure I'm not the only one who would vote on it.

If you have got a suggestion on how that could be implemented, I'll give it a try. So far I don't see a way to get information about the thread in which the exception has been raised.

Subclass checks would be very difficult to implement because all the expert knows is the exception name and the message. I know of no way to query the class inheritance in that context. But a regex for the name would be possible.

This particular problem was Delphi 2005 specific. It resulted in an error message on every start of the IDE, when the GExperts DLL was compiled with optimization on. That's why I never encountered it in my tests before, because all my test builds are compiled with optimization turned off. I don't remember why I changed that this time. Maybe I just forgot to uncheck that option. Delphi 2005 did not have separate configurations for Release and Debug builds, that came with Delphi 2007. As for older versions: Those did not support the inline keyword.

You have definitely earned it. Without your help, I wouldn't have been able to add this functionality and track down all those bugs.

I managed to fix the problem with Delphi 2005. It was totally unrelated: Some code when loading the code formatter configuration raised an external exception C000001D ((Illegal Instruction) for an inlined function when optimization was enabled. In the process I added the same exception handling to the editor experts that was already in place for regular experts, so now one faulty editor expert can no longer prevent all others from being loaded and initialized. Also the user gets a better error message in that case.

It works now with Delphi 2006. It also kind of works with Delphi 2005, but there is a different issue that might or might not be related to this. Thanks again for your help. Care to get a free life time license of GExperts? Oh wait, it's free already. 😉 At least I would like to add you to the list of major contributors to the project shown on the about dialog. Please contact me via PM if that's OK with you and whether I should add you as @Mahdi Safsafi or if you prefer an alias.

edit: Stupid me got the ifdef wrong: {$IFNDEF GX_DELPHI2007_UP} function GetParam(Obj: Pointer): Pointer; asm mov eax, [eax + $40] end; {$ELSE} function GetParam(Obj: Pointer): Pointer; asm mov eax, [eax + $3C] end; {$ENDIF} This should of course have been IFDEF rather than IFNDEF. Now it seems to work fine. I have to make some more tests. This seems to work better: Only one AV before the dialog is shown, the second one after it was shown is gone. Also, if I filter the dialog, it works like in the later versions. There is still the AV before the dialog would have been shown though: [4589E8C4]{bds.exe } + $0[20006D23]{rtl100.bpl } System.System.@HandleAnyException (Line 9963, "sys\system.pas" + 13) + $0 + $1AF[77A98E3F]{ntdll.dll } RtlInterlockedCompareExchange64 + $1AF + $21[77A842D1]{ntdll.dll } KiUserExceptionDispatcher + $21 + $5[20A89EB0]{dbkdebugide100.bpl} Debug.Debug.TDebugger.HandleDebugMessage (Line 8569, "Debug.pas" + 😎 + $5 + $1E[20C21189]{coreide100.bpl} DebuggerMgr.DebuggerMgr.TDebuggerMgr.HandleDebugMessage (Line 1942, "DebuggerMgr.pas" + 1) + $1E + $D[00415A1F]{bds.exe } AppMain.AppMain.TAppBuilder.actnDockEditWindowUpdate (Line 6345, "ui\AppMain.pas" + 6) + $D + $6[201406A7]{vcl100.bpl } Controls.Controls.TWinControl.WndProc (Line 7304, "Controls.pas" + 111) + $6 + $5[20159E7F]{vcl100.bpl } Forms.Forms.TCustomForm.WndProc (Line 3512, "Forms.pas" + 136) + $5 + $6[2013FDD0]{vcl100.bpl } Controls.Controls.TWinControl.MainWndProc (Line 7073, "Controls.pas" + 3) + $6 + $0[20040E4C]{rtl100.bpl } Classes.Classes.StdWndProc (Line 11583, "common\Classes.pas" + 😎 + $0 + $49[76F044B9]{user32.dll } AddClipboardFormatListener + $49 + $B27[76EE4FF7]{user32.dll } CallWindowProcW + $B27 + $229[76EE4149]{user32.dll } DispatchMessageW + $229 + $B[76EFE8AB]{user32.dll } DispatchMessageA + $B I'll try to find where it happens.

I know it's $99, I had already found the code in the debugger before you sent me the tool. The problem seems to be something else, maybe it's really different parameters this time. I will send you the bpl via pm anyway, if you like to have a look.

Thanks. Yet again. Apparently it's $99 up to XE and $A1 from XE2 up. Which is a bit odd, because the class name of the debugger changed between 2010 and XE from TWin32Debugger to TNativeDebugger so I would have expected that offset to change at the same time. But that's not the case. I could not get this to work with Delphi 2006. It kind of works but throws access violations internally. I haven't tried Delphi 2005. I guess I'll not bother with these unless somebody else wants to do the debugging work.

That did it! Thanks a lot (again), for your time and effort. It's probably time to brush up on my (dis)assembly skills.

They managed to bungle the fix(es) for StringGrid custom drawing again. I just had to adp my Delphi 10.4 fix in GExperts for that. Did nobody test theses fixes?

I just checked: Yes, it's the same framework code in both versions.

I see. That definitely looks like the code should be correct, unless @Kas Ob. is right and there are more parameters. I dug a bit deeper with the DUnit weirdness: When I enable debug dcus the debugger stops not at the end of the procedure but on an exception handler inside the DUnit code. That makes sense of course: The debugger stops at the position where there is code to display. The test case is simple: type TSomeTestCase = class(TTestCase) [...] procedure TSomeTestCase.TestException; begin raise Exception.Create('bla'); end; (Of course that's not the original code where it happened, but it happens with this too.) Yes, but isn't it still shipped with the current version too? I updated to the latest version of the test framework from source forge though. But that reminds me of something I have to check: Do I use the updated framework code in Delphi 10.2 too? I'll check and come back with the result. This is the code in TestFramework.pas where it stops: procedure TTestCase.RunTest(testResult: TTestResult); begin assert(assigned(FMethod), sMethodNotFound + FTestName + '" '); FExpectedException := nil; try try {$IFDEF CLR} testResult.FMethodPtr := nil; {$ELSE} CheckMethodIsNotEmpty(tMethod(FMethod).Code); testResult.FMethodPtr := tMethod(FMethod).Code; {$ENDIF} FCheckCalled := False; Invoke(FMethod); if FFailsOnNoChecksExecuted and (not FCheckCalled) then Fail(sNoChecksExecuted, testResult.FMethodPtr); StopExpectingException; except on E: ETestFailure do begin raise; end; on E: Exception do // <<<< the debugger stops here begin if not Assigned(FExpectedException) then raise else if not E.ClassType.InheritsFrom(fExpectedException) then FailNotEquals(fExpectedException.ClassName, E.ClassName, sExceptionUnexpected, ExceptAddr); end; end; finally FExpectedException := nil; end; end; It stops on the line with "on E: Exception do". Yes, it definitely only happens when the Filter Exceptions expert is used. If it's disabled (which uninstalls the hooks, now using ddetours btw.) and the IDE shows its original dialog, pressing "Continue" works as expected.

I'm sure that 'nobody got a raise for decade' is wrong. Nobody in IT got a raise, but surely management did. They handled the fallout caused by the mistakes of those stupid IT people after all!

P := GetParam(Obj); P[$A1] := 1; // resume = true. PostDebugMessage(Obj, 1, P); // this will resume the app. How did you come up with this @Mahdi Safsafi ? It works fine on my GExperts development computer, but it doesn't at work, where it skips to the end of the procedure that raised the exception and stops there. So there must be something missing. Both are the same Delphi Version, but different Windows versions (10 vs. 8.1) and (AMD Phenom II X6 1090T vs. Intel Xeon). Edit: It also works fine in a XenServer virtual machine running on a (different) Intel Xeon with Windows 8.1. And also in another XenServer VM with Windows 8.1. (Which probably means that there is something really odd with my work computer.) edit2: This is even weirder: It works with my usual test project (with just a raise exception.Create('bla') in a form's OnCreate event), but fails in a DUnit unit test where it would have been really useful to ignore the expected exceptions. edit3: It's not the computer, it's the Delphi version. Delphi 2007 works with the test project but not with the unit test project. Delphi 10.2 works with both. At least I can now reproduce it on my GExperts development computer, not that it helps much. Any input would be appreciated.

Just asking. Yes, for a newcomer this wouldn't be of much use unless he takes on a job where he has to use older Delphi versions (employer's requirement). With this information he has a chance to decide whether he really wants to work under these restrictions.