PB9 CrossOver Questions

[Cliff Nichols]

Thank you Kev!!!!!!!
I REALLLLLY did not want to have to fall into my own personal version of "DLL Hell", just because a minor change and recompile would require a new GUID.

Often (although I try to avoid it), I have the need to change code for a situation I had not thought of, and there may be only 1 person that has the change, but then I work on making it part of the standard package (unless its something majorly different)

Knowing the right-click trick, I believe will solve all the problems. Thanks again

[Kev Peel]

For development I don't touch the registry or even create a DLL, but simply use conditional compilation to test the code as a self-contained program. Now that PB supports classes directly, I don't need to build a DLL via a third party.

[jcfuller]

Right click in IDE > Insert GUID. That GUID is a permanent, unique value for you.

You should always use the same GUID for a published object, unless that object has changed significantly (ie. some features were removed instead of added, which should be a rare event). It is simple to update an ActiveX library on a system -- all you have to do is call REGSVR32 again, and as long as the #COM GUID string is the same, Windows will update the registry with the new info. Do not go using a library without calling REGSVR32 on it first, and always unregister it in your uninstall routine (if you are using one).

IMO the only time you are not required to use #COM GUID, is with internal classes (ie. contained and used in one EXE)

I disagree in part.
During development do not beat on the registry. You're just asking for trouble. Use NEWCOM CLSID ClassID$ LIB DLLPath$. See LET in the help file.

James

[Kev Peel]

Right click in IDE > Insert GUID. That GUID is a permanent, unique value for you.

You should always use the same GUID for a published object, unless that object has changed significantly (ie. some features were removed instead of added, which should be a rare event). It is simple to update an ActiveX library on a system -- all you have to do is call REGSVR32 again, and as long as the #COM GUID string is the same, Windows will update the registry with the new info. Do not go using a library without calling REGSVR32 on it first, and always unregister it in your uninstall routine (if you are using one).

IMO the only time you are not required to use #COM GUID, is with internal classes (ie. contained and used in one EXE)

[Cliff Nichols]

As a VB refugee, and corrected in my ways by PB showing me all the things that VB "Hid from me", and now with PB9 (which I just received today (and pouncing on it like I knew I would)

I am looking at older code that was procedural, and how it could intermix with oop, and still keep the 2 playing nice.

So far my 1st test is working, but not sure if I am on the right train of thought, or Really Asking for trouble????

Attached is my 1st trial...but along the way it brought up other questions.

1. According to Doc's I have read, If I do not arbitrarily pick a GUID, then one is picked for me (and hence each compile the number would be different), but what if I don't know what to pick? or if I make a minor change, and publish the changes? If I make a minor change, and publish it to someone, then the old DLL with what was registered with Windows would be the one that got used (or the new dll would not work?).
2. Backup to question 1...Maybe I just misunderstand, but to my knowledge using objects have to be registered with Windows via regsvr32 in order to work?
3. Is there a way to create a Guid that is constant, no matter how many times I recompile (even different versions of the same dll?)
4. All just thinking out-loud, but I am sure I got problems ahead of me