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.
Related
I want to disable the dialog (shown below, titled "Processing File") appears each time I compile or build my project, but I failed to find which IDE plugins it's from since I use a lot of productivity plugins (also shown below).
Anybody has any hint :P
The List of IDE plugins I use is shown below - PS, I believe the DKLang is not shown there.
As hinted by Andy Vines the Delphi G+ group user, that's because I somehow have enabled the 'Set Component Properties' expert included in the GExperts IDE plugin.
It searches for and auto-close active database connections, datasets, etc.
Disabling it fixed the problem. Thanks.
Delphi XE+ has a "Search for Usages" option. Is there a similar option in Delphi 7 to find function/procedure callers? I either do a plain text search or place a breakpoint and see who the caller was in the Call Stack during run time. Both are time consuming and very inefficient.
Opening the app in Delphi XE and using "Search for Usages" doesn't work. The app doesn't compile.
There is no equivalent to Search for Usages in Delphi 7. That feature was first introduced in XE.
Even the Find References feature was not introduced until Delphi 2005 (when Delphi switched to the Galileo IDE).
There is an anlternate way of find the callers:
Use a debugger that can show the Call Stack (like MadExcept) and make a "fake" exception in your function like this:
function WhereDoYouCallMe;
begin
raise Exception.Create('Called');
...
...
end;
Now every time the function is called, you will get an error box where you can view the Stack and get where it called. You can continue the program or you can set your breakpoints and so on.
You can also mark the method 'deprecated' and you will get a list of usages in your compiler warnings.
Not ideal but alternatively you could
Rename the method
Compile
Check the compiler errors to find all callers (those that can be resolved at compile time).
As mentioned by dummzeug
Renaming the method is the simplest way to find all uses.
Unfortunately you have to rename all uses in turn to find the next
use. And afterwards revert the changes.
I'm trying to debug my DirectShow source filter. I'm using Delphi Pro 6 on Windows XP along with the DSPACK component library. I'm using Skype as my host application, which I set in the Parameters option in the Run menu, for testing my source filter DLL (ax file extension). Skype runs fine and I see a stream of my OutputDebugString messages in the Event Viewer, but none of my breakpoints are ever hit. In my Project Settings I have optimizations off, stack frames on, debug DCUs on, Range Checking on, and Overflow checking on. Each time I modify my code and run a test I:
Do a full build
Unregister the DirectShow filter (regsvr32 /u)
Register the DirectShow filter (regsvr32)
Run Skype as my Host application from the IDE
When an Exception occurs, the IDE does trap it and pops up an error dialog box with the option to view the assembler code in the CPU window. However none of my breakpoints are being hit. Can anyone tell me how to get breakpoints working?
Thanks.
Along with the debug option indicated by Mason Wheeler, use a full map file. And make sure that there aren't old DCUs and BPLs in the search path.
Also, consider using EurekaLog or MadExcept - even the trial versions should be able to show you what's gong on when it blows up.
Sounds to me like you're building with debug information off, either in the project options or with a $D- switch somewhere in the code or in an include file. Check to make sure you've got debug information available.
I try to debug a COM dll (TAutoObject) in Delphi and my break point are not green.
I put my option like this :
host : c:\Program Files\Internet
Explorer\iexplore.exe
param : c:\software\test.html
My test is well lanched but no breakpoint in Delphi
what is the way to to this ?
You have to run the program which launches the COM+ object and then attach it to the process.
IE launches a sub-process which hosts non-trusted code. this is probably why your debugging settings are not working, and why attaching to the process once launched works.
Since the debugger doesn't start the file, that won't work.
IIRC you can try to "attach to process" to the process running it (iexplorer.exe), but the problem is that that doesn't allow to debug through the start of the component. (since it costs time to manually attach)
I had a different setup where I instantiated a very slightly differently compiled .ocx on a panel of a delphi app, and used that to debug. Which worked fine.d
This link Breakpoint not honored while debugging a DLL helped me debug my com dll in Delphi 5. Go to Project -> Options -> Linker -> check mark "Include remote debug symbols". I couldn't tell you why it worked. Delphi 5's help provided the following description:
Include remote debug symbols Check this if you are using remote debugging.
You also need to have integrated debugging turned on. Its on the general tab of the debugger options.
In the past what I have done is to create a separate program which invoked my COM object and used it as the target for debugging rather than the standard host. This simplifies things and also allows you to create specific repeatable tests of known issues to aid in smoke testing later.
you can also use tools like CodeSite.
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.