binary compatibility

[manofprayer]

how do you use the binary compatibility option?

'coz when you use it, it prompts you to specify the file it needs to be 'binary compatible' with. does it mean that I use it only when I recompile?

thanks

[simonm]

Every time you compile an ActiveX DLL, EXE or OCX each public class is assigned a GUID. And this is what any client project (that uses the component) uses to identify it.

If a project references a component class with a particular GUID, re-compiling the component project will assign a new GUID thus making it incompatable with the client project.

You can avoid this by selecting the binary compatability option to preserve the previously used GUID. That is why you have to point to a file; the file you point to is the file that you wish to remain compatable with (usually the previous version).

There are some limits though as you may not modify the public interface of a class (but you may add to it).

[mike34]

When I compile my code I get the message box stating that I have a class module that has arguments and/or a return type that is incompatible with a similar declaration in the version compatible component. The 2 options are break compatibility or Preserve compatibility but it seems confusing. I want to override the previous version because some of the code it is no longer valid. Also,

To change or update user controls that will be different from what was previously complied with the client application, am I suppose to have no compatibility set, project compatibility set or binary compatibility set in the project properties box for components. I am trying to avoid getting these break compatibility message boxes and the user defined type is not valid messages. I am new at this.

Thanks in advance

[manofprayer]

Since I have been working with this, I have a 'lil experience with this.

You get this error, if I'm not mistaken, is because previously you have used the DLL that you have created. Correct?

A rule of thumb with creating DLL's and COM is that you do not change the Interfaces (the Function and Sub headers). You do not take away any parameters, nor do you add to them. You can change the internal implementation of the function/procedure, but you are not allowed change the headers. This is because the purpose of DLL's is for simpler upgrades, and at the same time you would want to maintain the compatibility to other projects that previously used this.

Given that you are the one creating this DLL, then I should say you wouldn't have a problem if you 'broke' compatibility.

With regards to your problem with the User-Defined-Type, I'm not quite sure, but I think you are not allowed to declare your UDT or Enum types as Private and declare some property or public variable using the type of sort as Public.

Hope this helps.

[tumblingdown]

Hehe ;-)


td.

[simonm]

manofprayer,
Whilst it is true that you may not change the interface, you may add to it.

A class module's interface consists of all it's public property, sub and function headers. It also consists of any public Enum's that are declared in the declarations section of the class.

Once you have set binary compatability, you are guaranteeing (to any client projects) that your exposed interfaces will not change. Therefore, when you change a com component, as long as the interface doesn't change, you won't have to re-compile your client projects.

But, you may add public properties, functions and subs without breaking compatability. You may also add parameters to existing functions or enumerator items to enumerator groups as well.

If you can keep binary compatability set it will make your life easier generally but sometimes it is inevitable that you will break it.

[crispin]

If you're going to create and manage enums and UDT's you might be better off creating and managing your interfaces in IDL (interface definition language - sorry if you knew that already) There are some good examples with the platform SDK, and more on MSDN...