Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RC1015: cannot open afxres.h; file open in another editor

10 views
Skip to first unread message

jlea

unread,
Feb 10, 2003, 12:57:50 PM2/10/03
to
I receive a RC1015 error message when trying to view resources in VC++.NET.
It says that it can't open afxres.h because it is open in another editor. I
do have VS v6.0 installed - could that be causing me any grief or is there
some setting I need to twiddle with? Jon.


Kevin Frei [MSFT]

unread,
Feb 13, 2003, 2:11:58 PM2/13/03
to
> From: "jlea" <j...@leapsoft.com>
> Subject: RC1015: cannot open afxres.h; file open in another editor
> Message-ID: <#P7$T2S0CHA.2296@TK2MSFTNGP10>
If the debugger crashes, or if devenv crashes, they could keep the files
open. You might check to see if either mdm (the debug manager) or devenv
(VC7 IDE) are still running, and if so, kill them. It's probably not due
to your VS6 installation.
--
Kevin Frei & Charles Park
Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

jlea

unread,
Feb 13, 2003, 6:17:34 PM2/13/03
to
Thanks for the info. mdm.exe doesn't go away after I close down VS.NET. I
stopped the mdm.exe process, then fired up VS.NET and it is back there (and
I still can't get to the resources), along with devenv.exe and something
called devldr32.exe. I am running XP-Pro btw. If I fire up VS.NET by itself
and then close it down (not double clicking the solution project file),
mdm.exe doesn't go away. Is it supposed to go away when VS.NET exits? I can
view the resource file in VS v6.0 with no problems.

"Kevin Frei [MSFT]" <kf...@online.microsoft.com> wrote in message
news:qfI08O50CHA.2136@cpmsftngxa08...

Kevin Frei [MSFT]

unread,
Feb 14, 2003, 1:34:39 PM2/14/03
to
> From: "jlea" <j...@leapsoft.com>
> Date: Thu, 13 Feb 2003 15:17:34 -0800
> Message-ID: <e77u8W70CHA.1768@TK2MSFTNGP12>

>
> Thanks for the info. mdm.exe doesn't go away after I close down VS.NET. I
> stopped the mdm.exe process, then fired up VS.NET and it is back there
(and
> I still can't get to the resources), along with devenv.exe and something
> called devldr32.exe. I am running XP-Pro btw. If I fire up VS.NET by
itself
> and then close it down (not double clicking the solution project file),
> mdm.exe doesn't go away. Is it supposed to go away when VS.NET exits? I
can
> view the resource file in VS v6.0 with no problems.
>

MDM isn't supposed to go away (I got bogus info from elsewhere) but it was
possible that it could have kept a file open. I'm stuck, at this point -
I'd need a lot more information (can you give me your project? Can you
rebuild your project manually and still repro the problem?) Also, this is
my last day of official newsgroup responses, so if you'd like to keep me
informed of what's going on, remove the 'online' from my e-mail address and
shoot me mail directly.

--
Kevin Frei

jlea

unread,
Feb 14, 2003, 3:27:54 PM2/14/03
to
I appreciate your time with this. This seems to come and go for one project
and is always the case for another. Unfortunately, the projects are very
large so I don't think you would want one of them. I'll try to duplicate it
with a small project. All my projects started in v6.0 and were converted to
.NET. Another guy in the office (using Win 2000) has no problems with the
same projects on his machine?? If I figure out anything I'll let you know.
Thanks. Jon.

"Kevin Frei [MSFT]" <kf...@online.microsoft.com> wrote in message

news:N3fTzeF1CHA.2116@cpmsftngxa08...

Dan Harner

unread,
Mar 18, 2003, 4:07:14 PM3/18/03
to
This sounds like MS KB 326987 to me - if the total length of your include
paths is greater than 512 bytes you cannot use the resource editor and will
instead see an RC1015 error.

We have seen that error since starting to use .NET. Supposedly the only
workaround is to remove directories from your include path until the length
is less then 512. The problem with that approach is that once you remove the
include paths, you can't compile anything, because the compiler can't find
anything. I can't believe that more people aren't complaining about this
glaring bug, unless we're the only people trying to use .NET for a
large-scale C++ project.

A potential workaround that we've found that seems to work is create
multiple VCComponents.dat files and swap them around as needed. You can find
this file in the C:\Documents and Settings\[your name here]\Local
Settings\Application Data\Microsoft\VisualStudio\7.0 folder. It contains the
various directories defined in the .NET IDE at Tools-Options-Projects-VC++
Directories.

As far as I know, this is the only way to make a C++ project usable under
.NET if you have a lot of include paths _and_ resources that you want to
edit. If there's a better way to go about this, I'd like to know...

Dan Harner
Sr. Software Engineer
Standard Register

"jlea" <j...@leapsoft.com> wrote in message
news:OjgbycG1CHA.2552@TK2MSFTNGP12...

Scott Jones

unread,
Aug 20, 2003, 7:26:04 PM8/20/03
to
I had this problem too, and found that the advice offered in the KB 326987
article did not help at all. After some trial and error, I finally found
the culprit. It is indeed an include path length limitation, but it is not
just Tools.Options.Projects.VC++Directories. If your project's
C/C++.General.Additional Include Directories entry is too long, that will
also cause the RC1015 ... afxres.h error. The workaround I found was to
copy all the /I compile options generated by the C/C++.General.Additional
Include Directories entry and move them into the C/C++.Command
Line.Additional Options entry. This will allow the project to compile
normally without breaking the resource editor.

Good luck!


0 new messages