Leaderboard

As with any software without a reliable method to reproduce a bug it can be very hard to fix it. Some organizations severely limit how much effort can be put into non-reproducible bugs as they can consume large amounts of time and effort for little to no gain. It is frustrating for both users and developers but acting out on that frustration doesn't really help any. For F2084 Internal Error errors which are often due to the compiler having problems with some source code it is very hard to find the bug and create a way to reproduce it without access to some source that triggers it. Again frustrating for both - it is hard for developers to do much with "compiler chokes on my source" when they can't take a look at the source - but also for the user who has work interrupted when the hit the bug. At least when there is a way to reproduce a problem Embarcadero does work on fixing them. An example was for years I occasionally got a dangling scrollbar in the IDE but never reported it since I was not able to find a reliable way to reproduce it. A while back somebody did report it and after reading some comments others made I finally managed to reliably reproduce the issue and put it in a comment on the bug report. It was fixed in the next release. ([RSP-34111] Editor leaves dangling vertical scrollbar behind - Embarcadero Technologies).

I know what is happening: In MMX settings under Delphi Editor there is a setting Auto toggle Object Inspector and Code Explorer reacting on F12. Try to disable that.

I have another approach: type TSplitter = class(Vcl.ExtCtrls.TSplitter) private FInMoveSplitter: Boolean; FSibling: TSplitter; protected procedure WndProc(var Message: TMessage); override; public procedure MoveSplitter(var aMsg: TMessage); property Sibling: TSplitter read FSibling write FSibling; end; procedure TSplitter.MoveSplitter(var aMsg: TMessage); begin FInMoveSplitter := True; try Perform(aMsg.Msg, aMsg.WParam, aMsg.LParam); finally FInMoveSplitter := False; end; end; procedure TSplitter.WndProc(var Message: TMessage); begin if (Message.Msg >= WM_MOUSEFIRST) and (Message.Msg <= WM_MOUSELAST) and not FInMoveSplitter and (Sibling <> nil) then Sibling.MoveSplitter(Message); inherited WndProc(Message); end; Linking is a two liner: Splitter2.Sibling := Splitter3; Splitter3.Sibling := Splitter2;

I would be interested for sure, any approach to reading the map file is worth posting to save others time and learn the tricky aspects.

You're right for sure, that's why I recently implemented MAP file reading and extracting all the info available for any given address. Besides some tricky aspects, that wasn't too hard. I merged that with built-in stack traces and now I have fully detailed traces with module, function name and LOC. Alas, the code requires some other my routines which are not fully ready for publishing yet (translate & add comments etc). But in case someone is interested I could try to switch to built-in routines

We now live in 2022 - the article dates back to 2004. Things have evolved in the meantime. Mormot is open source and does a good job. There are commercial products too, Aurelius to mention one, I personally know. There is a learning curve, but it´s worth.

This looks very good (and works)! But please note that in the compiled result you will get an instance of this function for every type <T> you use it for - even if it likely does the same for all TObjects which you pass in. If you have a lot of types and a lot of utility functions like this, this will increase your executable file.