Can't use resource view to edit resource in VC8

Question

When I double click the rc file to edit the resource, the IDE will inform me the "fatal error RC1107" message. Even the resoure file of newly created project by VC8 are not able to be edited. These resource files are valid since I can edit them in VC7.

Answer 1

Sorry! I cannot understand this. It seams that the resource compiler starts, when you double click an rc file? The RC1107 is a message from the resource compiler!

Is it possible that the rc file is not associated to the IDE in the registry.

Try a repair installation of your Visual Studio.

Answer 2

Thanks for your reply!

I double click the rc file in the IDE's "Solution Explorer" (not in the Windows Explorer). In the previous version of VC, the IDE will switch to the Resource view, show items such as Menu,accelerator,etc in the Resource view, and I can then edit these resources. But in VC8, it will switch to the Resource view, but it will show the "fatal error RC1107"(invalid usage: use RC /? for help) box, and only "Load Failed" in the resource view.
I think rc.exe is OK because I can successfully compile and run my project.
I once used filemon to monitor the IDE, and I find it does following things when I double click the rc file:
read RC file, load rcdll.dll , load rcxdti.dll, load rcxdtiui.dll, and then show the error box.
Is that because my window's codepage is not English?(My windows  is Chinese Simplified, and my VC8 is English)

Answer 3

I find the problem somewhat!

I monitor the open process of VC7, and find that it will query the corresponding aps file. Then I use VC7 to open the RC file, and it automatedly create the aps file. And then, I use VC8, and it can correctly open the resource now!
It seems that my VC8 can't create the aps file, which cause it fail to open the resource. Do you know how to fix this problem?
thx a lot

Answer 4

I've had the same issue.

It looks like the include path processing is broken in VS8. I disassembled the resource compiler dll and found that the command line being passed to rcdll.dll was corrupted. The last slash on the include path was being replaced with a quote character. There was no starting quote.

To fix the problem, I made a minor change to the include paths in the IDE.

Tools -> Options -> Projects and Solutions -> VC++ Directories

Show directories for: Include files

I Added a slash to my last path, so "P:\" became "P:\\". Ok the changes and the problem went away. :-)

Hope this works for you.

   Andy

Answer 5

That really works, thank you very much!
Could you tell me where the bug happens? When IDE passes the command line to rcdll.dll or when the rcdll.dll parses the command line?

Answer 6

Happy to help.

The bug happens in the IDE. The IDE passes the command line to rcdll.dll when calling the exported functions RC and RCW. Its passed as the 5th parameter. I'm not sure how much of the IDE code is running in .NET, but I couldn't get much call history from the stack. The command line may have originated in resedit.dll.

The command line that cause the problem is below. Note the quote after P: in the middle of the text.

PlatformSDK\bin\rcdll.dll./s./x./I.D:\Program Files\Microsoft Visual Studio 8\VC\include;D:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include;D:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include;D:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\common\include;D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\include;E:\ArmourSoft\SourceSafe2004;P:" /r /FO E:\ArmourSoft\SourceSafe2005\Projects\SmartSafe_5.0\ArmourSoft\FileSafe\ASCipher\ASCipher.aps /L 0x809 E:\ArmourSoft\SourceSafe2005\Projects\SmartSafe_5.0\ArmourSoft\FileSafe\ASCipher\ASCipher.rc

   - Andy

Answer 7

I'm quite curious that when there is aps file in the root directory of the project, the res editor can work normally. Does that mean that the res editor prefer to use the aps file? It can't create one, but can modify it, so strange behavior
That's an interesting issue and maybe I'll spend sometime analysing the rc*.dll files.
Thanks very much for you help ^_^

PS:I think such bugs should be fixed before the release of rtm.

Answer 8

Yes, the resource edditor works on the binary resource not the text file. You can use it to edit the binary resources from .EXE, .DLL, .SYS, files etc. (Which can be quite useful).

It would be nice if all bugs were fixed before shipping, but alas its software. So far its the only bug I've found. Also, I'm the only person on my team that encountered this problem, so it might be rare.

Answer 9

That's a wonderful feature to edit the resource in exe.
I haven't heard of that before. It seems that there're still much features I don't know yet, hehe

Answer 10

Andy Larter wrote:

I Added a slash to my last path, so "P:\" became "P:\\". Ok the changes and the problem went away. :-)

 

You are awesome, just thought you should know :)

Answer 11

Well apart from that.. nice work.. This issue is not on all installtions of visual studio. I wander why some work and some don't... Well maybe the problem lies in the installtion proccess. Well tbh dissasembling isn't illegal :p hehe... Please don't post such things...( at least no on official forums ... ) do it on pm or else big heads will come down...

 

Anyway nice way to go around it.... but i didn't analyse the stack to do that... it seemed wierd that the path was with "/" instead of "//" so by luck i found it...

 

Thanks for the analysis mate!

Answer 12

aka Andr3w Grammenos M.V.P. wrote:

Well apart from that.. nice work.. This issue is not on all installations of Visual Studio. I wander why some work and some don't...

Thanks a lot to all. I just had the same problem and the double backslash trick worked so I can return to my work.

Since this is an official MSDN forum and it is possible that some of the VS developers are monitoring the thread, I'd like to add that I installed the version of "Visual Studio 2005 Professional Edition" Version 8.0.50727.42 (RTM.050727-4200) with compiler version: Microsoft Visual C++ 2005 77626-009-0000007-41485 and  the IDE worked correctly.

Recently I had to upgrade (because of a new corporate licensing scheme) to "Visual Studio 2005 Team Edition for Software Developers" Version 8.0.50727.42 (RTM.050727.4200) with compiler version: "Microsoft Visual C++ 2005 77642-113-3000004-41517" and this version exhibited the bug.

Just in case it helps the developers to find out where the error was introduced between these two versions.

Thanks
gc

 

Answer 13

>Tools -> Options -> Projects and Solutions -> VC++ Directories
>Show directories for: Include files

Thanks, that solved my problem.  It was slightly different, but I had added a directory for boost libraries, which it apparently didn't like.  The libraries were found just fine (source compiled), but the resource editor had this bizzare problem.  In my case an extra "\" on the end of the directory caused this.

 

The bizzare part is that this used to work, and I didn't connect this to changes in the include path.  I had to "google" to find this.

 

Its now 2007, shouldn't this "bug" get fixed?  I use Windows Update...

 

Thanks!

Answer 14

I was encountering the same problem.

Thanks for the solution, works a treat.

 

Its just another bug that convinces me VS2005 has not been developed or tested with C++ development in mind.

Answer 15

Better way to resolve this issue is not to add slash, but to remove the last one, so "P:\" will became "P:". =)

Answer 16

I've just encountered the same problem, and added a ficticious drive P: to my includes.

 

I can't believe that this problem still exists in VS2005, even after having applied the latest service pack.  Sounds like a unit test might be missing.

Answer 17

Maybe this bug is not very easy to repro, but I think it is better for Microsoft to fix such annoying bug.

Answer 18

I just had this problem too.

Turned out to be a '\' at the end of a folder name on the last include directory. I removed the '\' and now I can edit the resources in the IDE.

After a little test is looks like a bug in VC8 IDE.

If you last include directory ends in a '\' the .aps file can not be created and throws an error. Also if your last include directory is a root of a drive you need to add a second '\' (as posted above)

Answer 19

I am convinced too,

besides the workaround does not work for me, I dont know why, poking a " into memory before the arguments works, but I can not do that every time, when I want to open the resource-editor.

 

I installed SP1, it's still the same bug.

 

 

 

 

Answer 20

I had the same problem, removing "\" at the end of the directory path solved the problem

- Thanks

Answer 21

I did had the same problem, too. Installing MDAC 2.8 SDK gifted me with the last include path as
C:\Program Files\Microsoft Data Access SDK 2.8\Inc\
(notice the final \ character) and the same dreaded RC1107 occured. After removing it, all is ok.

(Environment: XP 32-bit SP2, Visual Studio 2005 SP1, Windows Vista SDK).

* * *
This could be related to another thing that I found last days regarding PathRemoveBackslash.
Accordingly to MSDN:
"Returns the address of the NULL that replaced the backslash, or the address of the last character if it's not a backslash."

There is also an example on MSDN page, quote (the end):

OUTPUT:
==================
Path before calling "PathRemoveBackslash": c:\a\b\File\
Path after calling "PathRemoveBackslash": c:\a\b\File

I was in the need to pass the C:\ (again, notice the end \) to QueryDosDevice in form of C: (without ending backslash) because QueryDosDevice does not work with C:\.

Strangely, the call (with szPath being _T("C:\\") )
  LPTSTR lp = :athRemoveBackslash(szPath);
returns
  _T("\\")
so returns the address of the last character (which is backslash) if it's not a backslash.
Practically, it does return the backslash character in this particular case.

(So I had to add special code to handle the X:\ case - I don't know if there are also other cases as well; I hope not, otherwise this will render PathRemoveBackslash as unusable).

I wonder if a similar thing happens also to RC when the last include path ends with a \ ?

Answer 22

Thanks Andy!

Your post helped me