Multiple projects open causing problems

[LAVA 1.0 Content]

I am working on a application involving three major components, each component is assigned to a different programmer, and each programmer has created there own labview 8 projects. We use GOOP (Endevo flavor) and carefully planned all the classes needed, defined the prototypes for all the methods and went on a merry ways to right code. Another point worth mentioning, we use Microsoft Source Safe for source code control. We created a master GOOP create VI, for lack of better term, that insantiates all the classes we will be using in the Application. The objects created were named objects with the create or look up option selected. The output of the VI is a named cluster with the references to all the objects, the cluster is fed into a shift register in the lower loop of a master slave event queued message state machine ( that was clear ).

Here is the problem, when it came time to start integrating the components, the projects were opened as needed (all on the same machine), but the goop objects were not communicating to each other. Further investigation uncovered that if multiple projects are opene, at the same time, the files under that project are on different execution targets. This is evident also by viewing the lower left corner of the VI instead of just "My Computer" it is "<project name>.lvproj/My Computer". The ramification of this is any techniques used to pass information between VI's running on the same machine (GOOP references) won't work. While I can see situations were this would be desireable, I can see many more were this is a problem. This leaves to options, open all VIs from windows explorer or put all components in the same project. The problem with the later is if all developers use the same project file you will be forced to check in and out .lvproj and the .lvib every time you do anything to the project. The problem with explorer is per NI recomendations I am doing most of my file organazation in the project, not on the hard drive, so things arent easy to find, besides, having all the files at your fingertip in the project explorer is part of its supossed charm.

A solution to this would be the option to enable or disable creating seperate execution targets for each opened project or being able to add a project to a project. I have not found either of these options. Has anybody else come across this, and if so how did you get around it?

Thanks in advance for any and all help provided.

[mdennie]

...

This leaves to options, open all VIs from windows explorer or put all components in the same project. The problem with the later is if all developers use the same project file you will be forced to check in and out .lvproj and the .lvib every time you do anything to the project.

...

I'm very interested in solutions to the problem of multiple developers working in a single project. I've been trying to figure out how NI envisioned this would work.

If LV8 is supposed to provide an environment for large, multi-developer projects, surely someone considered that more than one person would work on a project at one time and that the project would be under source control. I was expecting to see an article from NI somewhere describing a suggested practice, but so far at NITS and in other conversations with NI folks I've gotten nothing but blank stares concerning this issue.

How are changes to a LV project managed when multiple developers are working in the project simultaneously? Has anyone encountered this yet?

-- Matt

[david hoadley]

A solution to this would be the option to enable or disable creating seperate execution targets for each opened project or being able to add a project to a project. I have not found either of these options. Has anybody else come across this, and if so how did you get around it?

Thanks in advance for any and all help provided.

Hey Todd,

The more 'computer science-y' answer is to store a reference to each application instance in your object pointer cluster such that each object's methods know the context in which they are supposed to be running: namely, the application instance that created that object. I just learned a similar lesson, and I actually think I like LV better this way. I think the tools vendors (VIE included) have some catching up to do to thoroughly support 8.0, though.

Just a thought - if you had a 'readme' diagram in a central application reference (project) and instantiated all of your objects from said project, then you might be OK. a) all VIs would be in memory on the 'main' project and b) creating all objects in the main project would put them in the proper memory context. Hmm, no, I think that's not good enough. I presume you have methods of project A called in project B and vice-versa. If those method calls were now made by reference with the main project app reference used, then this method seems sound. Now THAT's a pain - use Call By Reference everywhere instead of VIs on the block diagram. OK, maybe I don't like it better this way. It's really analogous to proxying method calls for GOOP objects between PCs on a network.

The way I think NI envisioned us using a project was to organize the information for an app on a 1-1 basis. Anything different and your mileage may vary.

Dave.

[LAVA 1.0 Content]

Hey Todd,

It's really analogous to proxying method calls for GOOP objects between PCs on a network.

Dave.

I would agree totally with your analogy. Further more, Global VI's (not that I use them) and VIG (labview 2.0 globals) do not work either, queues do however. I have attached an example to illustrate my point. If you open both projects, and run send and recieve VI's, the VIG and global won't work nor would goop, the queue will. If you than open one project and than open the other main VI directly it will work. I also believe that any VI's in common between the two projects will open seperate coppies of the VI in memory. If any one from NI is monitoring this thread, I would be very intrested in hearing from you on this subject.

Download File:post-3882-1142868285.zip