Debugging Problem: Recursion?

[Intel_C_Intel]

I'm trying to debug a recursive subroutine in a DLL called by a pointer reference. I can't get the debug to halt at my breakpoints. I've tried debugging from the DLL workspace and from the executable workspace, neither works. I can't step into my routine either. I'm sure I've debugged this code before and don't remeber having any problems.

Would recursion cause such a problem?

(CVF 6.6B Win2KSP4)

[Intel_C_Intel]

Something weird is going on...

My exe is not running the code in the DLL! I've updated my DLL code version to 3, but when I run the model it still reports version 2. I've used Process Explorer and Dependency Walker to confirm that I have loaded the DLL I just rebuilt, it just seems to be running something else....

[Intel_C_Intel]

D'oh! I had another DLL overriding the one I was working with - something I should have checked for since I'm the one who put the 'overidability' in there in the first place!

[Jugoslav_Dujic]

If I may suggest a workspace setup which will save you such problems in the future (e.g. debugging one dll version while looking at other source version):

1) Copy dll's and exe's directories into one, say "Project", so that you have "Project/ExeName" and "Project/DllName" folders.
2) Create a Blank Workspace, say "Project", in "Project" directory
3) Do Project->Insert project into workspace->Browse for .dsp file for both .exe and .dll
4) Switch on "Build" toolbar in CVF so that you have the dropdown list of active project visible
5) Create a "ProjectBin" directory (or, if you like, "ProjectBinDebug" and "ProjectBinRelease")
6) For all configurations, on Project SettingsLink tab, specify "../Bin/whatever.exe(dll)" as "Output file name".

Whenever you build anything, .exe and .dll will end up in the right place (Bin directory). You can debug them together and easily switch from one to another.

Jugoslav

[Intel_C_Intel]

Jugoslav,

Thanks for the suggestion...we pretty much have such a setup already! The problem arose from my stupid testing beahviour! My exe loads two DLLs, one for project specific options and one for updates to core code. The update DLL overrides the project DLL whenever they both contain routines with identical names. At some point (probably to test something) I'd taken my version 2 project DLL, copied it and renamed it with the update DLL name, so it was always running the code in the fake update DLL. Dur! :o)