In Visual Studio 2010 I am trying to make a copy of a dialog template resource with a condition in order to have two different versions of the dialog in two different build configurations.
I have a header file that the .rc file includes which contains this:
#ifdef BUILD_CONFIG1
#define RES_DEFINE_1
#else
#define RES_DEFINE_2
#endif
So, I go to the Resource View in Visual Studio, right-click on the dialog template and choose "Insert copy..." The Insert Resource Copy dialog pops up and I set the condition: RES_DEFINE_2 and click OK.
At this point, everything looks good. I see both the original dialog and the copy with the condition in brackets [RES_DEFINE_2]. I save everything and I'm good to go.
Here is where the problem seems to be. Our version control system is ancient, and based on locking single files. In previous versions of Visual Studio, we've only archived the *.rc files, and made sure that resources were up-to-date by deleting the *.aps files that the resource editor creates. Whenever we needed to edit a resource, Visual Studio would simply regenerate the *.aps file from the *.rc file
But, when I delete the *.aps file in VC2010, and then reload the resource in the editor I'm now missing the conditional resource that I just added. Instead, I see only the original IDD_DIALOGNAME entry. I look in the *.rc file and see what I'm supposed to:
Original dialog:
#if defined(APSTUDIO_INVOKED) || !defined(RES_DEFINE_2)
IDD_DIALOGNAME DIALOGEX 0, 0, 301, 190
...
Copied dialog:
#if defined(APSTUDIO_INVOKED) || defined(RES_DEFINE_2)
#if defined(APSTUDIO_INVOKED)
IDD_DIALOGNAME$(RES_DEFINE_2) DIALOGEX 0, 0, 301, 190
#else
IDD_DIALOGNAME DIALOGEX 0, 0, 301, 190
#endif
...
If I go through adding another copy, I get another template in the resource with no #if at all:
IDD_DIALOGNAME$() DIALOGEX 0, 0, 301, 190
...
Is the *.aps file no longer completely generated from the .rc file? Has anybody else run into this and have a workaround, or will I be forced to start storing the *.aps files in our version control system?
Update: Yesterday, I could get this bad behavior at will. This morning I showed my boss and he duplicated it. Now, everything seems to just magically work on both my machine and the machine we originally discovered this on. Haven't heard yet if my boss can still get it to happen.
Now nobody can duplicate this issue. We weren't able to find any difference in the steps we took. Lacking any steps to duplicate this, I'm answering it to remove it from the list of outstanding questions.
Related
I have a Clear Case VOB mapped on my Z: drive in Windows 7 and checked out 2 files. All the other files are shown as read only in Visual Studio 2013 but these checked out files seem to be editable (no lock symbol like on the others), but when I try to save the file it only allows shows a "Save As" dialog and when I try to overwrite the file I get a message "Access to 'Z:...\khmwdkwdmx.d0c' is denied" (which I suppose must be some kind of generated temp file, because every time I try to save it always has a different name). If I edit the file in Notepad++ it can be saved as normal, no errors in that case.
Additional info: The problem seems to be that as I can't create new files in a clear case dynamic view only change the files I have checked out, so VS cannot create it's temp files while saving (like m4s1c0nk.swt, jl0lb2ob.255 and other random generated ones) so the file saving always fails. Is there any possible way to turn these file generations off or to generate them somewhere else?
First, make sure of the state of the files within the parent folder of Z:\...\khmwdkwdmx, to check if those two files are indeed checked out.
Second, verify is there is no other processes keeping an handle of those files, preventing Visual Studio to update the actual files.
You can also fall back to a Visual Studio session opening your view using the full path of the dynamic view (M:\MyView\MyVob\...) instead of the subst Z:\MyVob
The problem seems to be that as I can't create new files in a clear case dynamic view only change the files I have checked out,
Check if you can at least check out the parent folder, or check is associated right:
cleartool descr -l parentfolder##
(the ## are for describing the element, not the version, of the parent folder).
Try a:
cleartool protect -chmod 777 parentfolder
More generally, write issues are described in "About the error Checked out version, but could not copy data to <some-file.txt> in view", and are following "About ClearCase permissions on Windows".
I've run into a problem with VS2010 (it also exists in the latest version, SP1 (10.0.40219.1)):
Add an existing Word file to the "Solution Items" and check this new file in.
Check the file out for editing
Double click on the file and edit it in Word (just make some minor changes)
Save the file (CTRL-S)
Now the file is removed from the "Solution Items" in Visual Studio (you may have to repeat the editing and saving a couple of times)
Update: I'm using Visual SourceSafe 2005.
Despite my research efforts I haven't really found anything on this issue apart from this Microsoft page, and I'd like to know whether there is a way to prevent this problem from happening.
Any ideas are more than welcome, thanks in advance.
G.
After further investigation I think I found the reason behind this behaviour and a workaround.
Please also note that the behaviour described in the original question only occurs for files that are added directly underneath a solution or to a folder that is directly underneath a solution.
The reason
I'm not sure whether the following is 100% correct, but the main point is how Word (and probably other MS Office apps as well) saves an existing file:
Save the current version of the file to a temporary file
Rename the original file so it can be used later in case something goes wrong
Copy the temporary file to the location of the original file, using the original file's name
Delete the original file (that was renamed in step 2)
Visual Studio picks up that the file doesn't exist (for a very short time though) and removes it from its tree and the .sln file. This can also be reproduced by manually adding any kind of file, checking it out (if not checked out), renaming it to a different name and then back to its original name => file is no longer shown in Visual Studio.
The workaround
I've created an empty project template following the steps on Microsoft's site. I also set the output to "Class Library" so that the project would compile even if no static main method exists. This template can be used to add a "Documentation" project to an existing solution. Underneath this project you can add files and edit them as you wish, as Visual Studio behaves differently and does not remove the file when it is saved in this constellation.
Obviously this approach is still not very satisfying or elegant, but I hope that it may be helpful for others who might run into the same problem.
G.
I've run into the same issue. I simply undo changes for the solution after I've closed the document file and the solution files will be as they originally were before your document changes.
Occasionally (usually after having updated my .sln file in source control) I get a strange Visual Studio error wherein I'm unable to open some of my files. The files in question show up in the appropriate project, but trying to open them results in an error dialog saying "A file of that name is already open."
This is virtually identical to Why does it say "Project with that name already opened in the solution"?, except for files, not projects. The solution given there was does not fix this.
Visual Studio internally maintains a list of currently opened files, to avoid problems caused by opening files more than once. Any number of things (crashes, reboots, updating files in source control outside of VS) can cause this list to become corrupted.
In any case, the problem can be fixed by deleting the hidden Solution.suo file which is in the same directory as your Solution.sln file. This will cause you to lose your current workspace state (open files, window layout, etc.), but it won't have any other adverse affects on your solution.
This is a hidden file, so to see or delete it you either have to enable viewing hidden files in Explorer or use del /AH Solution.suo on the command-line.
Delete the hidden .suo file and edit the .csproj file to remove the lines below:
<SccProjectName>Svn</SccProjectName>
<SccLocalPath>Svn</SccLocalPath>
<SccAuxPath>Svn</SccAuxPath>
<SccProvider>SubversionScc</SccProvider>
Now, reopen the solution to solve the issue.
Do you have any linked files in the solution?
Visual Studio has an invariant that only a single file of a given path can be open at one time. This invariant is hit most often when you have a linked file in your project / solution and attempt to open both the original and one of it's linked references.
Open csproj file of the project and delete following lines:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
These lines are most probably created due to project is added to visual svn i.e. when project/solution is added to source control project/solution files are updated to include source control integration info and these lines are added which causes issues.
Delete these lines and just reload your project (or solution), this should fix issue.
I've got two branches of code. 1 has a dialog box that the other doesn't, but because of politics the dialog box wasn't moved into the newest branch. Now they want it in...
So is it possible to copy a dialog box from one project to another.
There apears to be an export and import feature however it's greyed out.
.RC files are simple text files. You can simply copy/paste the DIALOG text from one .RC file to the other. Make sure that you copy the corresponding RESOURCE.H entries as well.
Alternatively, you might be able to open both .RC files and then simply drag-and-drop the dialog from one to the other.
Update for Visual Studio 2010 - 2013:
You can still drag-drop and copy-paste, but only outside of your project / solution.
Close solution, open both RC as files without any open solution, and go. For drag, "Hold down the CTRL key and drag the resource to the second .rc file. For example, drag IDD_DIALOG1 from Source1.rc to Source2.rc."
Microsoft - How to Copy Resources
Drag and drop doesn't work in Visual Studio 2010. Editing the .RC file does work but be careful. For me the ID for the dialog showed up with *ID_etc*. I copied it and removed the *'s and it seemed to fix the problem.
I finally figure it out how to copy a Dialog from one solution to another.
Steps:
Open both solutions in separte windows.
Add a new Blank Dialog -Add Resources-> add->newDialog
Open Both Dialogs Open Binary data.
Copy the Binary data from source solution dialog to Destination Dialog
This is just to add some visual detail to the accepted answer (by Roger Lipscombe) along with its steps.
In order to copy a resource such as a Dialog from one project another project, below steps can be followed.
Start a new instance of Visual Studio.
Open both source and destination .RC file as files, as shown in the picture.
From the source RC file, copy required dialog.
Switch to the destination RC file tab and simply paste it.
Please note that this operation would have updated the resource.h file. That is an excellent help by Visual Studio.
One will have to make sure that no duplicate resource IDs are present in the resource.h file. When working with some legacy projects, it is found that there came some duplicate resource Ids that had to be manually corrected. It looks like such an effort is worth considering the mammoth task required otherwise.
I'm programming in C++ on Visual Studio 2005. My question deals with .rc files. You can manually place include directives like (#include "blah.h"), at the top of an .rc file. But that's bad news since the first time someone opens the .rc file in the resource editor, it gets overwritten. I know there is a place to make these defines so that they don't get trashed but I can't find it and googling hasn't helped. Anyone know?
Add your #include to the file in the normal way, but also add it to one the three "TEXTINCLUDE" sections in the file, like so:
2 TEXTINCLUDE
BEGIN
"#include ""windows.h""\r\n"
"#include ""blah.h\r\n"
"\0"
END
Note the following details:
Each line is contained in quotes
Use pairs of quotes, e.g., "" to place a quote character inline
End each line with \r\n
End the TEXTINCLUDE block with "\0"
Statements placed in the "1 TEXTINCLUDE" block will be written to the beginning of the .rc file when the file is re-written by the resource editor. Statements placed in the 2 and 3 blocks follow, so you can guarantee relative include file order by using the appropriately numbered block.
If your existing rc file does not already include TEXTINCLUDE blocks, use the new file wizard from the Solution Explorer pane to add a new rc file, then use that as a template.
You want to Include Resources at Compile Time (MSDN).
Within Visual Studio IDE, right-click on the .rc file (in the Resource View panel), and select "Resource includes" from the shortcut menu. When the dialog opens, use its "Compile-time directives" area to enter whatever you want to include in the .rc file. For example, if you want your 64-bit and 32-bit builds to use different icons, you could include the appropriate resource file for each build as follows:
#ifdef WIN64
#include "Icons64.rc"
#else
#include "Icons32.rc"
#endif
It's worth noting that these defines are not set in the resource compiler by default, so for your 64 bit build make sure you add /DWIN64 to the rc build.
All the gory details can be found in MFC Technote #35.
-Ron
I'm not completely sure why you're trying to do, but modifying the resource files manually probably isn't a good idea.
I believe general practice for VC++ for globally-accessible values is to define them in stdafx.h (at least that's how I've seen it done), or to create something like a "globals.h" header file and include that wherever you need it. It really depends on what you're trying to accomplish though.