dummzeuch

TabControl is a TGradientTabSet, not a TTabControl and it does not descend from TTabControl either (Look at the Hierarchy tab in the IDE explorer), so typecasting it to TTabControl won't work. It doesn't have a Tabs property either, so even RTTI won't help you there. I found a TGradientTabSet on https://github.com/RRUZ/Delphi-IDE-Colorizer/blob/master/IDE PlugIn/Galileo/TGradientTabSet.pas. Not sure this is the one used in the IDE, but it's worth a try since this seems to be an IDE plugin.,

I'm encountering this problem regularly when some component isn't installed in the IDE or is installed but in a different (usually older) version. It would be nice to simply open that dfm as text and be able to make rudimentary changes to it. Most of the time it is enough to remove or change some properties from the dfm to make it load normally. The IDE always offers to delete a property or control, but I don't trust it (and I have reasons for that). Currently I open the dfm in a text editor but that's rather inconvenient.

Since the Visible property is introduced very early in the controls hierarchy, it's more likely to work than the Tabs property. Most likely your "x" is not a TTabControl but something else. Have you checked its ClassName?

No, I can't. I don't have any apple hardware to run any tests. See my comment to the ticket:

The link I posted goes directly to the page that gives you the description and in turn links to the source code. There is no ready built bpl for it. (And it's not part of GExperts.)

Did you try one of the Delphi IDE Explorers? E.g. mine. It might get you better information than Winspector. Multline tabs for the editor window are not possible with Delphi > 7. I don't know about the "new" old style component palette, I never used it.

I understood that you wanted to have an additional window that is shown when the CPU window is visible. Another approach would be to extend the CPU window itself, similar to what GExperts does to the Search Path edit window. It could add a panel to the right of the window which contains additional controls that are filled by GExperts.

Not sure wether it is doable, we'll never know for sure until we try. As for usefulness: I rarely use the CPU view, so for me it would be of very limited use. For others, I don't know. To sum it up: I have no plans to do this, because I have too much to do for my limited time already. But as always, I will accept patches if somebody wants to try. I will also grant write access to svn if somebody thinks he needs it. So, if you want it: Do it. :-)

I my last GExperts related blog post I wrote about the new “Close Exception Notification” expert which I just had added to GExperts. It was a hack that hooked the Exception Notification dialog. This spawned a discussion in the international Delphi Praxis forum and resulted in a rewrite of the expert. It’s now called “Filter Exception” expert and instead of hooking the dialog it directly hooks into the code that shows this dialog. Thus it prevents the dialog from being shown for filtered exceptions. Read on in the blog post.

Sorry, my fault, it's not the exception address (the one where it occurred) but the address which caused the exception.

I tried your code too, but it didn't work (Delphi 10.2.3) The ExceptionAddress was always 0. I'll go with Mahdi Safsafi's code. That worked, for 64 bits as well as 32 bits. But thanks anyway. Every hint is appreciated.

This does work, thanks a lot. Now I only need a readable way to add this to the code...

Thanks for the hints @Mahdi Safsafi and @Kas Ob.. I got it to display the exception address so far and changed the exception name to EAccessViolation. It's too late in the evening to get more work done, but I'll try to get the rest of the information too. It works for the Win32 only IDEs so far, but FDebugEvent is not available for later IDEs, so I need a different way to get the ExceptionInformation array contents for those. Of course the same applies to other hardware exceptions.

You have a point there. I just reverted my change with the constants and added them as comments only.

I might have fixed this in the current sources. But since I have never seen this problem, I can't test it. If it works, the fix was to set StyleElements to [] to the form and all components, so the form doesn't get partially themed. This looked ugly anyway and caused some drawing problems on top of that. If you think that's an eye sore, you are probably right, but I prefer the form to work over having it look "pretty".

The problem(s) should now be fixed. @Stefan Glienke

@Stefan Glienke

Thanks for that. One question that I wanted to ask for a while: What do those "magic numbers" mean: $0EEDFAE6 $0EEDFAE4 $0EEDFADE I googled them and found that the last two are declared as constants in system.pas: const cNonDelphiException = $0EEDFAE4; cDelphiException = $0EEDFADE; Oddly enough the first one does not occur in system.pas, Google found it only once (Warning: This URL might not be save! It should go to a file TXLib.h which is part of "TX Library is a tiny 2D graphics library for MS Windows written in C++. This is a small sandbox for the very beginners to help them to learn basic programming principles. The documentation is in Russian." Copyright: (C) Ded (Ilya Dedinsky, http://txlib.ru) <mail@txlib.ru>" but the repository on Sourceforge to which txlib.ru links contains a different TXLib.h file.) #define EXCEPTION_CPP_BORLAND_BUILDER 0x0EEDFAE6 // Should never occur here <<<--- here #define EXCEPTION_CPP_BORLAND_DELPHI 0x0EEDFADE // Should never occur here So I guess $0EEDFAE6 is an exception number that Delphi / C++ Builder use internally. Am I right? So I could declare them as constants for readability: const cNonDelphiException = $0EEDFAE4; cCppBuilderException = $0EEDFAE6; cDelphiException = $0EEDFADE;

That's because I haven't decided yet how to use this information. I definitely want to.

Thanks that seems to fix the problem. Unfortunately when debugging GExperts itself, this still throws the exception Stefan mentioned. Apparently that's by design: The problem you see with Win64 is caused by the fix. Otherwise this would result in Project GExpertsRS102.exe raised exception class EDbkError with message 'Debug process not initialized'. in the call: Process.ReadProcessMemory(Address, SizeOf(Result), Result); No idea yet, how to solve this.

Is this in a particular Delphi version or in several?

It's the same with email programs: 30 years ago, every Fidonet reader / editor (but in particular GoldEd) was able to follow specific reply threads in echo and netmail. I know of no email program today that does this properly. (Yet another branch -> down Fidonet memory lane. 😉 ) And don't get me started on quoting.

Yes, I know. The problem is that the fix for 10.4 Patch 3 must also be applied to 10.4.1. For that to work, it must detect whether either of those is installed. The released DLL doesn't do that yet, but the current source code does.

Regarding Find-methods: I always make them return a boolean. If I need the index too, I make that an additional out parameter. If it gets too much hassle to always pass a dummy variable, I overload that method with one that does it for me and declare it inline: function TBla.Find(const _Key: TSomeType; out _Data: TSomeOtherType): Boolean; overload; inline; var Idx: Integer; begin Result := Find(_Key, _Data, Idx); end;

--------------------------- Delphi 10.4: bds.exe - Entry Point Not Found --------------------------- The procedure entry point @Deskform@TDesktopForm@AdjustLastLoadedBounds$qqrv could not be located in the dynamic link library D:\source\_Sourceforge\GExperts\Binaries\GExpertsRS104.dll. --------------------------- I just got this error when I tried to load the GExperts DLL compiled with Delphi 10.4.1 into Delphi 10.4(.0). This is probably related to the problems many have experienced when loading IDE desktops that include docked forms from older plugins. Solution: Either get the last GExperts version released for Delphi 10.4, or compile your own DLL using Delphi 10.4.