More info on Project Group needed

[Andrzejek]

vladk

(on Project Group) You said:
Yes, absolutely. I routinely utilize the same module(s), located in some common folder, in several independent projects. The projects share such modules or forms.

Some more questions:

How to call other Projects, other Project’s Forms from the same Projects' Group?

How to create a common folder (to place my common Forms and Modules)?
Is that just another Project in a Group?

What would be the best way to pass parameters between Forms in the same Project/between Forms and Modules in other Projects in the Project Group?

Appreciate any help.

---- Andy

 

[Golom]

How to call other Projects, other Project’s Forms from the same Projects' Group?

A Project Group is a mechanism for displaying multiple VB projects within one VB IDE session. You can use it to, for example, develop an ActiveX Object such as a User Control and run the test program that uses that control. The components within each of the projects do not move from one project to another however. You create a Project Group by
[li]Opening a VB Project (.vbp)[/li]
[li]Selecting "File / Add Project" and selecting the project to be added[/li]

How to create a common folder
Just as you would create any folder. You can save forms, modules, classes, etc. to your common folder by following the prompts and selecting the folder that you created as the place they are to be saved. To use an object from the common folder, select "Project / Add XXX / Existing" (where XXX may be "Form", "Module", "Class", etc.) Then select the common folder that you have created and click on the object that you want to include in the project.

Is that just another Project in a Group?
No. A Project Group is, as I said, a way of viewing multiple projects within the same IDE session. It is not a mechanism for sharing components among different projects.

What would be the best way to pass parameters between Forms in the same Project/between Forms and Modules in other Projects in the Project Group?
Passing parameters among forms, modules, classes, etc. in a project may happen in a variety of ways (e.g. Public Variables, Calling Arguments, Properties) but there is really no way that is "best" for every situation. Generally those same mechanisms are what would be used to pass information to components in different projects provided that there is some connection between them.

If you had a VB EXE project and a VB User Control project and ran them in the same project group then you would call properties and methods of the user control from the EXE project and respond to the User Control's events.

 

[Andrzejek]

Thank you Golom,

That makes it a little easier to understand.

--- Andy

 

[JoeAtWork]

When I work with Project Groups, it is not really to share common code, but to have different code libraries interact with each other.

Each project creates something specific, e.g. an EXE, a DLL, an ActiveX control, etc. Each of these projects is autonomous, but one may use the capabilities of another.

So for example, my main project might be an EXE, but one of it's forms uses an ActiveX control, and it also uses objects provided by the DLL.

You could first create and compile the ActiveX control and DLL, and then reference these compiled versions in your main project. However, it is often more convenient to develop the projects side-by-side, hence the Project Group. But what is important to remember, whether you are referencing the compiled ActiveX and DLL, or using them from within a project group, the code is exactly the same.

You shouldn't think in terms of "sharing a form" between the different projects. Instead, think in terms of the main project using objects provided by the secondary projects. So lets say you want the DLL to hold all functions having to do with customers, including a form that shows summary data for one customer. The DLL would need to provide an object that has a method to show this form. The code in your main project might look something like:

  Dim objCustData As MyDLL.CustInfo

  Set objCustData = New MyDLL.CustInfo
  
  'Display a form provided by the DLL, pass it a
  'customer ID (22) as a parameter
  objCustData.ShowCustInfo 22

Notice you are not writing any code such as frmCustInfo.Show - that piece of code would be in the ShowCustInfo method of the CustInfo class in the DLL.

I hope this makes it a bit clearer on how Project Groups are used.

 

[strongm]

>You shouldn't think in terms of "sharing a form" between the different projects

Trouble is that I believe that thread222-1263726 is where this thread originated, where it seems to me that 'sharing a form' between different projects was exactly what Andrzejek, and that he was misadvised on using Project Groups to solve that aprticular problem.

 

[JoeAtWork]

StrongM - The goal of the original thread was to "break up" a large program into smaller pieces. As you yourself suggested, dividing the code into different libraries would seem the best option.

I think having one project that is responsible for the functionality of a particular form is more maintanable than each project having direct access to the form. This allows for only one place where the business rules will be applied. So I am speaking of dividing up the functionality of the program, which I think was the goal. "Sharing the form" was the OP's suggestion for achieving this goal, which in my opinion is not the best design.

 

[strongm]

I'm not disagreeing with your advice or comments, merely pointing out that I still think that the OP is (or was) looking for something else. Perhaps Andrzejek can clarify