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

[Edward Diener]

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 ?

 

[Edward Diener]

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.

 

[Ronald Laeremans [MSFT]]

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]

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.

 

[Tarek Madkour [MSFT]]

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,

 

[Edward Diener]

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

 

[Tarek Madkour [MSFT]]

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

 

[Edward Diener]

Yes, that's what I meant


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.

 

[Tarek Madkour [MSFT]]

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.