By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,262 Members | 1,125 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,262 IT Pros & Developers. It's quick & easy.

Specify System::Windows::Forms::KeyEventArgs gets error

P: n/a
If I try to reference System::Windows::Forms::KeyEventArgs in a header file
I get the error:

MyHeader.h(236) : error C2039: 'Windows' : is not a member of 'System'

Any ideas why this is happening ? Can I not reference a name using its full
path in MC++ or is this just a bug in the compiler ?
Nov 17 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Edward Diener wrote:
If I try to reference System::Windows::Forms::KeyEventArgs in a
header file I get the error:

MyHeader.h(236) : error C2039: 'Windows' : is not a member of 'System'

Any ideas why this is happening ? Can I not reference a name using
its full path in MC++ or is this just a bug in the compiler ?


Please ignore. The problem went away once I chose to do a build rather than
just compile a single file. After the build, compiling works just fine
again.
Nov 17 '05 #2

P: n/a
You get this error if you aren't importing the assembly that these classes
reside in (by either having them in a #using statement or as an argument to
the /FU command line option).

The scenario you describe should happen. If you can get it to reproduce by
scorching all intermediate files and trying to build the single file again,
I would be interested in getting a copy of your project to see what is
happening.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Edward Diener wrote:
If I try to reference System::Windows::Forms::KeyEventArgs in a
header file I get the error:

MyHeader.h(236) : error C2039: 'Windows' : is not a member of 'System'

Any ideas why this is happening ? Can I not reference a name using
its full path in MC++ or is this just a bug in the compiler ?
Please ignore. The problem went away once I chose to do a build rather

than just compile a single file. After the build, compiling works just fine
again.

Nov 17 '05 #3

P: n/a
Ronald Laeremans [MSFT] wrote:
You get this error if you aren't importing the assembly that these
classes reside in (by either having them in a #using statement or as
an argument to the /FU command line option).

The scenario you describe should happen.
I think you meant to say "The scenario you describe shouldn't happen.";
If you can get it to
reproduce by scorching all intermediate files and trying to build the
single file again, I would be interested in getting a copy of your
project to see what is happening.
I reported this as SRX031226602826. The reason it was happening was because
I had failed to compile stdafx.cpp before compiling the single file. This is
an old problem, going back to VC6 at least, which has to do with getting the
precompiled headers compiled first. Once I compiled stdafx.cpp, everything
worked fine. My suggestion to the support person to whom I was reporting
this is that when the precompiled header hasn't been compiled yet, the IDE
should be smart enough to realize this and report this to a user if one
attempts to compile a source file which depends on the precompiled header.

Ronald Laeremans
Visual C++ team

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Edward Diener wrote:
If I try to reference System::Windows::Forms::KeyEventArgs in a
header file I get the error:

MyHeader.h(236) : error C2039: 'Windows' : is not a member of
'System'

Any ideas why this is happening ? Can I not reference a name using
its full path in MC++ or is this just a bug in the compiler ?


Please ignore. The problem went away once I chose to do a build
rather than just compile a single file. After the build, compiling
works just fine again.

Nov 17 '05 #4

P: n/a
> From: "Edward Diener" <ed******@tropicsoft.com>

I reported this as SRX031226602826. The reason it was happening was because I had failed to compile stdafx.cpp before compiling the single file. This is an old problem, going back to VC6 at least, which has to do with getting the precompiled headers compiled first. Once I compiled stdafx.cpp, everything
worked fine. My suggestion to the support person to whom I was reporting
this is that when the precompiled header hasn't been compiled yet, the IDE
should be smart enough to realize this and report this to a user if one
attempts to compile a source file which depends on the precompiled header.


The "Compile <file>" command is intended to perform only a file compilation
(with no smarts or automatic dependency checking or anything).

I agree that a "Build <file>" command would be a useful one. It would
perform a dependency check and build all related files as well (build PCH,
run midl, etc. if necessary). However, this would be a new command not a
replacement of "Compile <file> since I am weary of changing the behavior of
the existing command which behaved that way since at least VC6.

Thanks,
--
Tarek Madkour, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #5

P: n/a
"Tarek Madkour [MSFT]" wrote:
From: "Edward Diener" <ed******@tropicsoft.com>

I reported this as SRX031226602826. The reason it was happening was
because I had failed to compile stdafx.cpp before compiling the
single file. This is an old problem, going back to VC6 at least,
which has to do with getting the precompiled headers compiled first.
Once I compiled stdafx.cpp, everything worked fine. My suggestion to
the support person to whom I was reporting this is that when the
precompiled header hasn't been compiled yet, the IDE should be smart
enough to realize this and report this to a user if one attempts to
compile a source file which depends on the precompiled header.


The "Compile <file>" command is intended to perform only a file
compilation (with no smarts or automatic dependency checking or
anything).

I agree that a "Build <file>" command would be a useful one. It would
perform a dependency check and build all related files as well (build
PCH, run midl, etc. if necessary). However, this would be a new
command not a replacement of "Compile <file> since I am weary of
changing the behavior of the existing command which behaved that way
since at least VC6.


Are you really weary of changing the behavior ? If so, you must have done it
many times in the past already to be so tired. I believe you might have
meant the word "wary" instead.

Simply because something has "behaved that way since at least VC6" doesn't
mean that it is the best way to behave. My suggestion, when a Compile is
being done, is simply to check if pre-compiled headers are being used, then
check if pre-compiled headers have been created, and if the answer to the
first is yes and the answer to the second is no, tell the user about it in a
nice little message box which allows the user to either stop the compile or
go ahead with it anyway. I am not interested in any other dependency check
nor in a Build file which compiles related files as well. The only change
you make to the Compile command is to do something which must benefit the
programmer. There is no downside to it since when this is not done in the
situation mentioned, ridiculous compilers errors almost always inevitably
occur. At least if you take the action I have suggested, the programmer is
alerted to the situation if he chooses to go ahead with the compile, and
therefore shouldn't be too surprised when errors do occur.

I am sorry your notion of programming in this matter seems to be that
nothing can ever be changed because it might be different than the way
Compile worked before. Try to realize that you are allowed to change things
for the better for your users, in order to make programming easier for them.
I am sure you know this, especially since the Visual Studio .NET IDE changed
many things, generally for the better IMHO, from the VC6 IDE. So it really
is allowed.

It is your product and your call to change something. I believe others have
encountered this error before and wasted time trying to figure out what it
was about, given some of the really odd compiler errors that ensue in the
situation mentioned, before realizing once again that they made the mistake
of forgetting to compile the pre-compiled header file first. Since in this
case the program ( Visual Studio IDE ) can be even smarter than the
programmer, I see nothing wrong with the IDE catching my error immediately
and telling me about it.

Thanks !

Edward Diener
Nov 17 '05 #6

P: n/a
> From: "Edward Diener" <ed******@tropicsoft.com>

Are you really weary of changing the behavior ? If so, you must have done it many times in the past already to be so tired. I believe you might have
meant the word "wary" instead.

Yes, that's what I meant :)
Simply because something has "behaved that way since at least VC6" doesn't
mean that it is the best way to behave. My suggestion, when a Compile is
being done, is simply to check if pre-compiled headers are being used, then check if pre-compiled headers have been created, and if the answer to the
first is yes and the answer to the second is no, tell the user about it in a nice little message box which allows the user to either stop the compile or go ahead with it anyway. I am not interested in any other dependency check
nor in a Build file which compiles related files as well. The only change
you make to the Compile command is to do something which must benefit the
programmer. There is no downside to it since when this is not done in the
situation mentioned, ridiculous compilers errors almost always inevitably
occur. At least if you take the action I have suggested, the programmer is
alerted to the situation if he chooses to go ahead with the compile, and
therefore shouldn't be too surprised when errors do occur.

I am sorry your notion of programming in this matter seems to be that
nothing can ever be changed because it might be different than the way
Compile worked before. Try to realize that you are allowed to change things for the better for your users, in order to make programming easier for them. I am sure you know this, especially since the Visual Studio .NET IDE changed many things, generally for the better IMHO, from the VC6 IDE. So it really
is allowed.

It is your product and your call to change something. I believe others have encountered this error before and wasted time trying to figure out what it
was about, given some of the really odd compiler errors that ensue in the
situation mentioned, before realizing once again that they made the mistake of forgetting to compile the pre-compiled header file first. Since in this
case the program ( Visual Studio IDE ) can be even smarter than the
programmer, I see nothing wrong with the IDE catching my error immediately
and telling me about it.


Thanks for your feedback Ed.

We are definitely not against change. We have done it a lot in the past :)
However, assessing the impact of any change is essential to make sure it's
a positive one.

There are arguments against always performing a dependency check. Consider
someone who knows that the change made to the PCH does not affect the file
they just edited and they don't want to spend the many minutes it would
take for the PCH to be rebuilt just to recompile the current file. This
person was happy with the VC6/VC7/VC71 behavior. If we start forcing a PCH
recompile in our next release that could upset someone who already relied
on the IDE not doing that.

I still see the point of needing someway to compile the file along with the
PCH if you need to.

Your post has triggered a discussion of this issue inside the team as well
as on MVP newsgroups (and here as well if you wish) which will certainly
cause some change in the positive direction. So thank you again for your
valuable feedback :)

--
Tarek Madkour, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #7

P: n/a
"Tarek Madkour [MSFT]" wrote:
From: "Edward Diener" <ed******@tropicsoft.com>

Are you really weary of changing the behavior ? If so, you must have
done it many times in the past already to be so tired. I believe you
might have meant the word "wary" instead.

Yes, that's what I meant :)
Simply because something has "behaved that way since at least VC6"
doesn't mean that it is the best way to behave. My suggestion, when
a Compile is being done, is simply to check if pre-compiled headers
are being used, then check if pre-compiled headers have been
created, and if the answer to the first is yes and the answer to the
second is no, tell the user about it in a nice little message box
which allows the user to either stop the compile or go ahead with it
anyway. I am not interested in any other dependency check nor in a
Build file which compiles related files as well. The only change you
make to the Compile command is to do something which must benefit
the programmer. There is no downside to it since when this is not
done in the situation mentioned, ridiculous compilers errors almost
always inevitably occur. At least if you take the action I have
suggested, the programmer is alerted to the situation if he chooses
to go ahead with the compile, and therefore shouldn't be too
surprised when errors do occur.

I am sorry your notion of programming in this matter seems to be that
nothing can ever be changed because it might be different than the
way Compile worked before. Try to realize that you are allowed to
change things for the better for your users, in order to make
programming easier for them. I am sure you know this, especially
since the Visual Studio .NET IDE changed many things, generally for
the better IMHO, from the VC6 IDE. So it really is allowed.

It is your product and your call to change something. I believe
others have encountered this error before and wasted time trying to
figure out what it was about, given some of the really odd compiler
errors that ensue in the situation mentioned, before realizing once
again that they made the mistake of forgetting to compile the
pre-compiled header file first. Since in this case the program (
Visual Studio IDE ) can be even smarter than the programmer, I see
nothing wrong with the IDE catching my error immediately and telling
me about it.


Thanks for your feedback Ed.

We are definitely not against change. We have done it a lot in the
past :) However, assessing the impact of any change is essential to
make sure it's a positive one.

There are arguments against always performing a dependency check.
Consider someone who knows that the change made to the PCH does not
affect the file they just edited and they don't want to spend the
many minutes it would take for the PCH to be rebuilt just to
recompile the current file. This person was happy with the
VC6/VC7/VC71 behavior. If we start forcing a PCH recompile in our
next release that could upset someone who already relied on the IDE
not doing that.


If the PCH isn't built properly to begin with, which is the case I am
specifying, then forcing a build is necessary for correct compilation. But I
wasn't saying to force it, just give the end-user a message that it hasn't
been built yet and let him/her decide what to do. That surely must be better
than error messages based on no valid PCH file.

I still see the point of needing someway to compile the file along
with the PCH if you need to.

Your post has triggered a discussion of this issue inside the team as
well as on MVP newsgroups (and here as well if you wish) which will
certainly cause some change in the positive direction. So thank you
again for your valuable feedback :)

Nov 17 '05 #8

P: n/a
> From: "Edward Diener" <ed******@tropicsoft.com>

If the PCH isn't built properly to begin with, which is the case I am
specifying, then forcing a build is necessary for correct compilation. But I wasn't saying to force it, just give the end-user a message that it hasn't
been built yet and let him/her decide what to do. That surely must be better than error messages based on no valid PCH file.


That's a possible design alternative. I'd also add Tools.Options switches
to default this dialog to Yes or No and not show it if so desired.

Thanks for the suggestion.
--
Tarek Madkour, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.