Cyclic reference of projects not allowed

[DesertChip]

Cyclic reference of projects not allowed.
What is the best way to take over this proplem?

I have two projects (ActiveX DLL) that each one uses other's classes. One of the solutions I thought about is late binding. But, is there a better one?

Regards

[Sam Finch]

Shove them both into the Same Project, You Can't run one without the other so You might as well have them all in the same file anyway so the user doesn't have to load 2 references

[DesertChip]

Well Sam, each one of them should be able to work alone and grouping them together within the same project may complicate the setuation. Let's examin the real propblem.

The first object is cItem, the second is cDepartment. Obviously each one should be able to run alone, and every one goes in different type of transactions. The link between them is cItemDept which represents items that are served (or sold) in specific dept. (you know, many-to-many relationship requires mean objects, one item can be served in many depts, one dept can serve many items). That mean object contains a refrence to both cItem and cDepartment.

Now, cItem should contain a refrence to cItemDept in order to create a collection of departments. cDepartment should also refrence cItemDept for the same purpose. And this is where the error came from.

So as you can see, grouping classes within the same project for every similar case will lend to one huge DLL at the end.

Actually, this was one case, i have a lot of similar cases in my project, and that's why i need a real good solution.

Regards

[Sam Finch]

Ah, I think I see, Why Don't you have a third project with the object that represents both?

[DesertChip]

Actually cItemDept is in a third project. cItemDept needs to refrence cItem and cDepartment, and vice versa. Now this "vice versa " is what is making all this problem.

[Sam Finch]

You're gonna have to put them all in the same Project. If the dlls can't run without eash other then they should all be in the same project, it's as simple as that

[DesertChip]

It is very simple. But that is true if cItem is not part of a big hierarchy like the one I have:
cServices->cGroups->cCategories->cItems

Departments hierarchy is shorter:
cDepartments->cRespCenters

Started to be confused ? ;-)

[Dim A]

Isn't this a perfect case for COM interfaces?
I know of them, but I really don't have a great understanding of them. Your project description seems to mimic most of the examples I've seen for COM interfaces, so that's why I bring it up.

[DesertChip]

Dim A, if you can be more specific please or supply a URL where i can read more about. I read about COM interfaces, but my understanding was different.

[DesertChip]

Any new ideas ??!

[Dim A]

Originally posted by DesertChip

Dim A, if you can be more specific please or supply a URL where i can read more about. I read about COM interfaces, but my understanding was different.

Not really. I've read about them in C++ developers magazines and on vbsquare, but I really don't have a good grasp of them. I think COM interfaces access a database of information by different methods... So you can have a database loaded, and the COM interfaces can read it in different ways, and the database doesn't care how many COM interfaces there are.

Is that the type of thing you're trying to do?
I may be mistaken on COM interfaces, but I've only read a couple of articles on it, and the whole subject is kind of hazy.