issue with changing projects

[Wolfgang]

Hello NI,

I have been running the debug version of project 'A', and in the IDE I've got some open windows (Find Results, Resource Tracking) because I was searching and also have a memory leak in this project (yes, I'll fix it...).

When I switch to another project 'B' via menu File / 'B'.cws, the new source file is opened, but the old Find Results and Resource Tracking windows are still there. This does not really make sense and I would suggest fixing it in the next release

Wolfgang

PS: just upgraded to CVI2010

[malczan]

Hello Wolfgang,

thank you very much for contacting National Instruments.

I could reproduce your Problem, that the old windows are still there, if you open a new project.

But i think for many customer it´s a really good tool, because they want to proof a big project or something else and if the old windows are not still there they have to reopen it with every opening of a project. It´s easier to close a few windows, then reopen it. And in some applications you have to jump between two projects and look at some difference between the variables or something else and so its desirable from some customer that the windows are still there. 

It´s difficult to make the best for every application from each customer, because the applications are very different.

I hope it´s traceable for you.

Best regards,

Maria

[Wolfgang]

Hi Maria,

Thanks for your reply.

I partially disagree because the Resource Tracking Window should only show up if there is a memory leak... In that sense I find it confusing to see an open RTW without a leak...

What I would suggest (probably I will have to submit it to the Idea Exchange) is to have projects remember open windows...

[vix]

---

malczan wrote: 

But i think for many customer it´s a really good tool, because they want to proof a big project or something else and if the old windows are not still there they have to reopen it with every opening of a project.

---

I think that the list of opened windows, together with their position and other settings like these should be included in the workspace.

If the user loads a new workspace, he will see other opened windows.

If he loads a different project in the same workspace the windows aren't closed.

Many other IDEs work in this way.

The problem is that CVI makes a lot of mess between the project and the workspace: as a matter of fact, if  you open a *.prj and a *.cws with the same name exists, the workspace is opened too, and I think this is an undesirable behaviour.

[malczan]

Hello,

i show what i can do for you and submit it as suggestion for the next version.

Thank you very much!

Best regards,

Maria

[ngay528]

I agree with what was mentioned above that some of the Windows should be retained in the cws file.

I have also noticed that when opening other projects that the CVI XML instrument will get loaded automatically somehow and files that are not attached to the previous project stay opened when changing to a new cws.  This may be by default but to me changing a project should retain this, not a workspace.

[vix]

Let me summarize what settings, workspace and project are for a lot of common IDE:

• settings = the list of options related to the IDE (i.e. coloring, ...). They can be saved into registry or configuration file
• project = a file that lists all the files needed by the current job, and all the settings needed to recompile the job (i.e. include paths, compiler defines, ...). A different user, on a different PC should be able to recompile the project simply loading the *.prj file
• workspace = list of options and configurations related to the specific project, but only "cosmetic" (i.e. window position, list of watches, variables, ...) A different user can recompile the project with a different workspace.

I think that CVI should implement the described situation, too.

Does anybody agree with this suggestion?

[Wolfgang]

There is a variety of posts on the workspace topic, I found one contribution of Luis here 

---

The workspace file was introduced in CVI 6.0 precisely as a result of adding source code control integration to CVI. Previously there were only project files, and everything was saved in them. The reason for the split was to remove those things which tend to be strictly user preferences (window positions, breakpoints, debug vs. release, etc.) and that typically do not need to be shared. Those were moved to the workspace file, and the idea is that workspace files would therefore not need to be archived in a source code repository. Project files, on the other hand, contain information that is necessary in order to be able to build the project, so those would need to be shared by multiple users.

---

This sounds very similar to the summary of vix.

Unfortunately, CVI does not behave like this: as outlined in the first contribution of this thread, loading a new workspace does not take care of the types of open windows... I wish it would...

[vix]

I think that Wolfgang is completely right!

The explanation of Luis is exactly how CVI should work, but it doesn't.

Moreover, if you read the message #7 (by Mert) in the thread linked from Wolfgang's post you can read that the list of *.cds files is stored into *.cws, but I think this is wrong.

As a matter of fact Mert wrote

---

The .cds file does contain all the settings needed to build a distribution.

---

and so I think the list of these files should be stored into *.prj.

I think that the prj/cws/cds files should be revised (even if this break the backward compatibility), because now they create a lot of problems.

For this reason I've already posted some suggestions in CVI Idea Exchange

[Mert_A.]

Regarding the .cds files being tied to the workspace rather than the project, this is necessary in order to properly support a distribution that includes the output from multiple projects in the workspace. If your application is componentized across multiple projects in your workspace, then it is important that distributions are not tied to a single project. Making them workspace-assicated facilitates things like rebuilding all out-of-date projects and detecting project dependencies on drivers.

Mert A.

National Instruments