I have recently moved from Delphi 7 to 10.1 Berlin.
I am used to being shown the line where an exception is raised in Delphi7 but the new IDE doesn't seem to work the same. I am just getting the exception notification followed by termination of my application when I close the exception box.
I have searched the options for a 'Stop on exception' checkbox (like Delphi 7) but cannot find it.
This is a fire monkey application by the way
Peter
If you are referring to the option called Stop on Delphi Exceptions within Delphi 7, its current equivalent is called Notify on Language Exceptions and is located via Tools > Options > Debugger Options > Embarcadero Debuggers > Language Exceptions.
Futhermore, I found this related question.
Related
At my office we are using Delphi 7.
I notice that in Delphi the "Find Declaration" option doesn't appear in the context menu whilst debugging.
When I forcably invoke the method (by extending the IDE) I receive the exception "Browser is not available while debugging" in "TBrowser.EnsureBrowserSymbols" (in delphipro70.bpl).
Is there a way to make this function available whilst debugging? Perhaps through an extension or a configuration option I am missing?
I am currently having to grep search my entire solution each time.
Thanks for your help.
I have given to maintain a project in delphi for which I don't have a clue :). It was converted to XE8 from D5. So it has a lot of custom things ( I am replacing some custom Object lists with Dictionaries since Dictionaries didn't exist in D5). The main application is extending TForm and in the FormCreate method contains this line
Application.OnException := FormException;
HandleException := Application.HandleException;
The FormException method takes the exception and also prints a detailed window with some info and the call stack.
I want to integrate EurekaLog or madExcept in my project to be able to find more info on unhandled exceptions. But although installed and enabled I don't get the the window with the info I want. It runs the FromException method, although I read that when linking with madExcept this gets ignored. Creating a new project simply throwing an exception from a button click with madExcept or EurekaLog activated works properly. I don't know where to look for the exception handling of delphi, and whether I need to have more settings for 3rd party tools. Any ideas?
I use EurekaLog and there are a couple of cases that it doesn't capture the exceptions.
For example, if your app is multi-threaded and it is closing, threads are shutting down and it may happen that EL will not have the time to capture the exception.
You may also have configured EL to ignore specific exceptions. Check the options in the EL settings window.
Make sure that EL is configured for the type of app you have (VCL/FMX/etc.). This is the first option in the EL options windows.
Make sure that the debugger produces detailed map file (Project>Options>Compiler>Linking>Map file --> Detailed)
The last thing I can think of is EL is not properly installed. Go to Project>View Source. If EL is activated for your project, you should be able to see a number of units (EMemLeak, etc....) before the System.StartUpCopy.
BTW, which version of EL do you have?
Elpizo na boithisa...
EurekaLog see that you have installed Application.OnException event handler and assumes that you want to handle unhandled exceptions by yourself. The similar may be true for madExcept.
If you want to use EurekaLog to handle unhandled exceptions, you can either:
Explicitly call EurekaLog from your FormException by calling HandleException from EBase unit
Move your code from VCL's Application.OnException to EurekaLog's OnExceptionNotify.
See this for more details.
According to System.pas, it is documented as True if compiled as console app. In System.pas, there is also an assignment
{$IFDEF LINUX}
IsConsole := True;
...
I have a strange problem where an app is launched from a Delphi app, using ShellExecute, and then it runs into this code, raising the (unexpected) exception
if System.IsConsole then
raise Exception.Create(Msg)
The application is not compiled with Project/Options/Linking/Generate console application. What else could set IsConsole to true?
Note that in Delphi XE2, OSX applications can not use this variable as it is always true. See QC Entry 98956 and Why Does My OSX FireMonkey App Think It Is a Console App ?
Found it: the executable has been created using dcc32.exe and the dpr / cfg file, the cfg contains a line
-cc
which creates a console application.
The Delphi 2009 Enterprise IDE does not show this setting in the Project/Options/Linking/Generate console application dialog. The application was ported from an older Delphi version and maybe something went wrong over the years.
When an application is run from within the IDE and the debugger is attached the exception 'External exception C0000008' is raised when it tries to connect to an imported ActiveX control.
If the application is ran standalone or the Rad Studio options/ Debugger Options/ Integrated debugging is unchecked, the program works as expected, no exception and the ActiveX control returns the expected result.
There are other ActiveX controls in the project, all of which work fine.
I have tried:
- Reinstalling the ActiveX control
- Re-Importing the ActiveX control
- Removing any software that may be causing conflicts (experts/ plug-ins etc)
- Turning off most running applications and services etc in case they are causing a conflict
Searching Google, It looks like others have been experiencing the same problem, but there is no fix to be found (other than turn off Integrated debugging, but obviously that is not a valid option.
Does any one have any ideas were to look to fix this problem?
I am using Delphi 2007
C0000008 is the status returned for an invalid handle. Make sure that your wrapper when it goes to create the object gives it a proper handle and not nil (assuming it is crashing because of a windows handle).
Since the application runs fine when not attached to the debugger, I'm assuming that the wrapper is handling this condition gracefully so the error is most likely occurring inside a try/except block.
It's a combination of non-obvious function behavior and IDE options.
MSDN CloseHandle
If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice, or if you call CloseHandle on a handle returned by the FindFirstFile function instead of calling the FindClose function.
So there's two options - either check the code for a place where some invalid handle is being closed or turn off IDE's notification of this exception. Go to Tools > Options > Debugger options > Emb debuggers > Native OS exceptions, find Invalid Handle item and change On resume option to Run handled. This worked for me.
Credits for this solution go to _Vasilisk_ from sql.ru forum.
When I'm running my COM Office add-in from within the Delphi 5 IDE (using any of the office applications as the host), breakpoints work fine (when using remote debugging symbols and a properly set output folder), but none of the non-delphi exceptions (like access violations) in my code triggers the IDE to break at that point. In stead, the IDE stops at the manual re-raise in the try...except wrappers in any of my outer safecall methods.
I noticed that for some reason the DebugHook global was set to 0 (while as far as I know it should always be set to 1 when running from within the IDE). Moreover, setting it to 1 manually during the initialization of my DLL actually fixes the issue: the IDE now neatly stops at the line where my experimental (read: crappy) code triggers the exception.
The questions is: why? Why do I need to do this manually? Shouldn't the IDE set this for me? Did I forget a major important setting somewhere triggering this behaviour?
If for some reason the Delphi evaluator is unable to lookup the DebugHook global, it would be unable to set that value. Try to compile/run the DLL from the IDE and set the "host application" in the Run|Parameters dialog to the the Office app you intend to call your DLL from. It is possible that this may be a bug in how the evaluator uses the remote debug symbols.
In recent versions of Delphi there's an Option under Debugger for "Debug spawned processes" or something to that effect. Is that option present in Delphi5, and is it set?
Not sure whether this will help, because I have not encountered the behavior you describe.