Debugging multi-project groups (VB6)
Forgive me but, although VB6 was my bread and butter once,I have not touched it in over 10 years and I have never dealt with groups that contain multiple projects. Nor have I ever been much of an "object orientated" man so I have little experience with classes.
I have been asked to investigate some problems with such a project group. I have successfully added all the projects (which, when compiled, generate a number of DLLs and EXEs) to a group and I can certainly trap issues within the development environment by setting debug break points in some of the projects but not all.
I have sucessfully added code that sends progress messages to a log file and here is an example as to where I'm getting a problem.
Code:
Public Sub TriggerMaster()
On Error GoTo ErrorTriggerMaster
GmsLog ("Pre class")
Set fred = New clsFred
GmsLog ("Pre object")
Set RunNow = CreateObject("projJohn.clsJohn")
GmsLog ("Pre execute")
RunNow.Execute False, fred
GmsLog ("Complete")
This code is debuggable interactively step by step and a type mismatch error is triggered after the "Pre execute" message has been successfully logged suggesting that the mismatch is in the RunNow.Execute. What I am pondering now is whether that is a problem with the line itself or with The RunNow execution (ie logiv within its Execute method)? RunNow is within the project group and is an EXE. It does not seem to be accessible for debugging when running interactively and even if I add message logging and recompile the EXE, it does not generate any of the messages I might have expected to see.
Can anyone offer any tips as to what the problem might be and/or how I might debug this more productively? Might removing the RunNow exe trigger interactive debugging in the RunNow project?
Any help would be greatly appreciated, thank you.
Re: Debugging multi-project groups (VB6)
In what project is defined clsFred? And What is the prototype of the method Execute?.
I think you have the clsFred class defined in the main project and in the projJohn project, and although both are identical, they have exactly the same code, they are not of the same type.
But without more information it is impossible to confirm this.
Re: Debugging multi-project groups (VB6)
i would debug just the project file causing the error and add error or log messsges into the next component down. project groups can be nice, but i'm not sure i would want to deal with big big project groups. maybe make another group of just the two components and then you can't step through the code from one to the other in the same ide instance. hopefully the dll functions don't cascade into other dlls.
sometimes things can get hairy if dll A returns or exposes a class from dll B. then you have be super careful about compilation order and com compatibility. everything can look right logically but you get a type mismatch because the hidden clsid it's expecting behind the scenes no longer matches what it was originally compiled against. there is not a great way to determine if this is the case.
debug in small concise blocks i guess. it's hard to say without seeing it.
Re: Debugging multi-project groups (VB6)
I never use project groups.
I just open and run each part I want to analyze in it's own instance of VB6 and then run the main project.
Code:
Main EXE --------------------------+
| |
CalculationWrapper --------------- GenericDLL
/ | \ | | |
/ | \ | | |
CalcEngine1 CalcEngine2 CalcEngine3 -----+ | |
| | | |
| +-------------------------------+ |
+------------------------------------------------+
If I want to debug the Main Exe with CalcEngine1, I just load both projects and run them
If I think the problem can also be in GenericDLL then I also load this project and run the 3 instances of VB6
Re: Debugging multi-project groups (VB6)
> Might removing the RunNow exe trigger interactive debugging in the RunNow project?
So you have RunNow project in your project group and expect on RunNow.Execute False, fred to be able to Step Into (F8) into Execute method but instead you get a type mismatch error on F8?
Try passing Nothing instead of fred variable i.e. try stepping into RunNow.Execute False, Nothing -- there is no conversion happening at callsite so any type mismatch error must originate from Execute method.
Edit: Using project groups is super convenient but requires some preparation and engineering discipline to be able to take advantage of the IDE conveniences.
1. You must forget on using cross-project types. What this means is that if you have projJohn project with public clsJohn class you just cannot use this data-type on public methods of projRunNow or any other one i.e. Execute method cannot have second parameter declared as Info As projJohn.clsJohn but should be "relaxed" to Info As Object. You can cast the param to any strongly typed reference inside the method though but just keep the projRunNow typelib from using external data-types other than VBA (e.g. Collection, etc.), ADODB (e.g. Recordset, etc.) or any other reference you will use only in binary and which will rarely be recompiled if at all.
2. You must compile your project in binary compatibility mode in topological order. This means that although public typlibs are not intermingled (can be browsed/viewed/used/referenced as stand-alone typelibs) the projects have to be kept in layers so that bottom layers do not reference upper ones to be able to compile the whole solution (eventually).
3. For the IDE to not crawl to a halt you have to open your group with projects in project compatibility mode and immediately run it to finish symbol tables population. This reduces IDE intellisense population time and generally might be the only option to use the code editor in bigger projects (with lots of classes) and to be able to even run it without getting out of memory errors.
cheers,
</wqw>
Re: Debugging multi-project groups (VB6)
OMG I just lost a lengthy reply I typed because I wasn't logged in. How frustrating! I will type another version if I can find time over the weekend. Thanks for all the feedback.
