dummzeuch

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.

Simple Curiosity. Also, sometimes it would be helpful when targeting multiple Delphi versions without having them around to check whether the code compiles.

Does it also cover when (which Delphi version) a particular syntax extension was introduced?

The installer has a repair option, but I wouldn't bother and just tell Windows to open all Delphi files with bds.exe in the Delphi installation's bin directory. That takes less time than the installer needs to even start.

What about https://github.com/danieleteti/delphimvcframework ? I don't know it, I just googled because I remember reading about an MVC framework for Delphi. There are also quite a few hits on "delphi MVVM" but I didn't investigate any further.

No. I'll check out ddetours when i find the time, but I'm reluctant to add another third party library. There is only one hook though.

Yes

Unfortunately neither a rebuild nor restarting the IDE worked in this case. Even a command line compile with DCC failed. I'm not that interested in Delphi 6 support, so I give up.

Not necessarily. The compiler could generate a set of overloaded procedures for this.

The good news is that it compiles for Delphi XE2 and later (and the Demo works). Older versions need changes. I have added issues with proposed fixes on Github for them. Unfortunately I didn't get it to compile with Delphi 6. I get an internal compiler error and I have no idea what to do about it.

Doesn't compile with Delphi 7, 2005, 2006 and 2007. I have added issues with fixes to github for these. It's mostly that PNativeInt isn't declared for these older Delphi versions. Also doesn't compile with Delphi 2009 due to a different issue, but I have not yet found a fix.

You mean it's a bad thing that, instead of fixing the bug in 4-5 applications and compile them, you now have to fix the bug only once and still compile 4-5 applications?

It's usually simply money. Delphi updates nowadays cost an arm and a leg and on top of that you also need to upgrade the 3rd party tools and components. (I just bought 3 TeeChart licenses and accounting was having a fit. 😉 ) Others don't want to go through the trouble of updating because they can't see the advantage. And of course, it takes time and there is a certain amount of laziness involved. In my (the company I work for) case it's a mix of all the above. We are now in the process of upgrading to Delphi 10.2 + latest update (the last version that didn't annoy the hell out of me) after staying with Delphi 2007 for a long time due to the Unicode change. And I hope that one of the 10.4 upgrades will fix all those annoying bugs so maybe we will even upgrade to that version. That process proves painful as we still need to keep compatibility to Delphi 2007 with our internal libraries because we will probably never finish upgrading all those internally used tools. There are just too many of them. Oh, and then there are those who - for years - have been phasing out Delphi (because it's so 1990ies and nobody uses it nowadays) and porting their software to a different development platform, so they keep the old Delphi version around to maintain the programs that work until (in some far far way future 😉 ) the new software is actually ready.

That would be really nice. If you need any help testing, please give me a shout.