-1

In the DPR file of my Delphi XE2 VCL Form project, I have this code:

CodeSite.Send('DPR Before CreateForm');
Application.CreateForm(TformMain, formMain);

And at the start of the FormCreate event handler this code:

procedure TformMain.FormCreate(Sender: TObject);
begin
  CodeSite.Send('1 FormCreate');

However, BETWEEN these two CodeSite statements (where the controls and components on the form are created), the program crashes. (I can see this in the CodeSite Live Viewer, where DPR Before CreateForm is the last log entry).

So how can I find out which of the controls or components creation makes the program crash?

user1580348
  • 5,721
  • 4
  • 43
  • 105
  • 1
    If by "crashes" you mean you get an exception, if the project is correctly prepared for debugging, the IDE + debugger should take you to exactly where the exception occurs. You might find debugging easier if you copy the Forms unit into your project directory, btw, because then you can safely edit it to add CodeSite calls if you need to. – MartynA Jul 30 '14 at 13:33
  • No, I don't get an exception (which would be easy to solve). I get the Windows crash dialog. – user1580348 Jul 30 '14 at 13:38
  • 2
    Enable Debug DCUs, make sure that the debugger is configured to break on exceptions, and use the interactive debugger – David Heffernan Jul 30 '14 at 13:39
  • @DavidHeffernan I DO NOT get an exception. The Windows crash dialog is displayed ("Would you like to search for a solution..." etc.). – user1580348 Jul 30 '14 at 13:44
  • That's because the top level exception handler has not been reached yet because you've not called `Application.Run`. And so your program leaks an exception, hence the crash dialog. Remember that the crash dialog is presented when your application throws an exception that is not caught. However. the debugger will trap the exception. FWIW, my app's .dpr file catches any such exceptions and presents an error dialog to the user, rather than letting the system crash dialog show. That seems nicer to me. – David Heffernan Jul 30 '14 at 13:50
  • @DavidHeffernan How do you catch any such exceptions in the .dpr file and present an error dialog to the user? – user1580348 Jul 30 '14 at 14:01
  • madExcept is my tool of choice for this (and I believe David's). – Andy_D Jul 30 '14 at 14:02
  • @Andy_D Yes madExcept is great. However, it's real strength is for when the exception occurs remotely. Since the user can debug it, the interactive debugger is the tool of choice. Well, I'm assuming that the user can debug it. Perhaps it really does only happen remotely. – David Heffernan Jul 30 '14 at 14:05
  • @user1580348 With a try/except around the call to `Application.CreateForm`. In my program I have a few other things that I do before calling `Application.Run` and the `try/except` wraps everything that happens before the call to `Application.Run` – David Heffernan Jul 30 '14 at 14:11
  • If you'd like to log unhandled exceptions with CodeSite, you might write `Application.OnException := CodeSite.ExceptionHandler;`. – TLama Jul 30 '14 at 14:13
  • @TLama That will be too late because the exceptions happens before the call to `Application.Run` – David Heffernan Jul 30 '14 at 14:14
  • @David, no, because the `OnException` event is fired even before the `Application.Run` call. – TLama Jul 30 '14 at 14:19
  • Very strange: I have activated EurekaLog and now the program does not crash anymore! (No EurekaLog error message neither). I assume this means that EurekaLog in some way SUPPRESSES the error. But I cannot live with this since I want to find the error. – user1580348 Jul 30 '14 at 14:20
  • @TLama How could it be? It's fired from a call to `HandleException` that is in an exception handler in `TApplication.Run`. Try a vanilla VCL forms app and adding to the .dpr file `raise Exception.Create` before the call to `Application.Run`. Or am I wrong? Could be. – David Heffernan Jul 30 '14 at 14:20
  • @user1580348 Did you consider using the debugger like I suggested? – David Heffernan Jul 30 '14 at 14:21
  • @David, have no clue (and time to investigate). Just tried. I've assigned the `OnException` handler to the CodeSite's one before the `CreateForm` call, removed `Application.Run` call (for being sure) and raised an exception in the form's `OnCreate` event. And the exception has been logged. But yes, if you raise an exception in project file, the event doesn't fire. – TLama Jul 30 '14 at 14:26
  • @DavidHeffernan Unfortunately the Delphi XE2 IDE always crashes when I use the debugger. (That's why I use CodeSite log messages for debugging). So I cannot use the debugger. – user1580348 Jul 30 '14 at 14:27
  • @user1580348 That pretty much sucks! – David Heffernan Jul 30 '14 at 14:34
  • @DavidHeffernan Why could it be that the program does not crash anymore after having activated EurekaLog? – user1580348 Jul 30 '14 at 14:38
  • Try this for XE2 debug crashes: Start Regedit and change the value of comp32x.dll to -1 under HKCU\Software\Embarcadero\BDS\9.0\Debugging\Embarcadero Debuggers\Evaluators In addition it may be necessary to rename the file compx32.dll so it can not be found anymore (it's in your installation directory of delphi inside the bin\ sub folder). Restart Delphi. Thereafter Delphi will work again and you can compile, break and run your projects. Anyway there is a bad side effect: The "Object Inspector" and "Evaluate/Modify" window work now in C style! No Delphi style will be displayed any more – Kanitatlan Jul 30 '14 at 14:41
  • BTW, WHO is the irrational guy who downvoted my question and WHY did he downvote it, without an explanation? – user1580348 Jul 31 '14 at 10:25
  • @Kanitatlan Thanks for the hint! Now debugging works again in XE2! But what exactly do you mean with "bad side effect: The "Object Inspector" and "Evaluate/Modify" window work now in C style!"? I cannot see any difference. – user1580348 Aug 01 '14 at 08:41
  • @Kanitatlan There is one difference I've noticed: The code structure view is empty! – user1580348 Aug 01 '14 at 15:13

1 Answers1

0

Found the cause of the crash/bug: I have a TEmbeddedWB on the main form. In FormCreate I had this statement which caused the crash/bug: 

EmbeddedWB1.SetCharartersSet('_autodetect_all');

By simply moving this statement to FormShow the crash/bug disappeared. Obviously the Ole connection to Internet Explorer is not yet established in FormCreate (while in FormShow it seems it is).

user1580348
  • 5,721
  • 4
  • 43
  • 105