1

I'm playing around with C++/CLI and WPF because I'm bored. I'm attempting to target .net 3.0 for this playing around. I want to handle a System.Windows.Window's Closing event; cl.exe complains about CancelEventHandler and CancelEventArgs if I try.

Here's a simple reproduction:

// 24 november 2015
#using <WindowsBase.dll>
#using <PresentationCore.dll>
#using <PresentationFramework.dll>
using namespace System;
using namespace System::ComponentModel;

int main(void)
{
    CancelEventArgs ^e;

    e = gcnew CancelEventArgs();
    e->Cancel = true;
    System::Console::WriteLine(e->Cancel);
    return 0;
}

Compiling with

cl /clr /AI "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0" xtest.cpp

in the x86 build tools command line, I get

xtest.cpp(10) : error C2065: 'CancelEventArgs' : undeclared identifier
xtest.cpp(12) : error C2061: syntax error : identifier 'CancelEventArgs'

(among other errors that result from e being left undeclared as a result). If I change

    CancelEventArgs ^e;

to

    System::ComponentModel::CancelEventArgs ^e;

then I also get

xtest.cpp(10) : error C2039: 'CancelEventArgs' : is not a member of 'System::ComponentModel'

So what's going on? Every search I've done says that these two types are definitely in System.ComponentModel...

This is with Visual Studio 2013 on Windows 7 64-bit. The version preamble from the compiler is

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723
for Microsoft (R) .NET Framework version 4.00.30319.18444
Copyright (C) Microsoft Corporation.  All rights reserved.

(I'm probably also not doing .net versions right...) Thanks.

andlabs
  • 11,290
  • 1
  • 31
  • 52
  • 1
    You must be very bored if you want to do this by hand. Just add the /showIncludes option. You'll now see why you cannot target .NET 3.0 with VS2013. And you'll see the reason why the compiler can't find the type, you didn't tell it to reference System.dll. – Hans Passant Nov 24 '15 at 18:47
  • All right, thanks. Changing the `/AI` path to `(same except without v3.0)\.NETFramework\v4.0` and adding `#using ` does fix it, but I have a feeling I'm still not doing this properly, especially since I get a warning about conflicting ICommand (that I thought was fixed by NOT having `#using `). What is the better way to do this? (I was considering using a makefile for this playing around; if that's not feasible then that's fine too.) – andlabs Nov 24 '15 at 18:57
  • 1
    An IDE project is of course the better way to do it. It will for one not make the mistake of using the wrong reference assemblies, the reason you got the ICommand issue. The correct ones live in the c:\program files (x86)\reference assemblies directory. – Hans Passant Nov 24 '15 at 19:01
  • All right; thanks again! – andlabs Nov 24 '15 at 19:58

0 Answers0