calling win32 api from C++ forms project

  • Thread starter Thread starter Steve Richter
  • Start date Start date
S

Steve Richter

using vs2005, the wizard created a c++ forms project for me. Now in
the form1.h file I have a menu item click handler that I would like to
add some win32 api code to:

private: System::Void
tapeToolStripMenuItem_Click( System::Object^ sender,
System::EventArgs^ e)
{

HANDLE hTape = CreateFile( "\\\\.\\TAPE0", GENERIC_READ |
GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL);

}

What header file do I use for the HANDLE and DWORD macros? Where do I
place the #include stmts in the form1.h file?

I need to use other win32 APIs like SetTapePosition and I got the
function declaration to be accepted in the main project .cpp file.
But linkage failed because of "unresolved externals
SetTapePosition". How do I add kernel32 to my project?

( I actually used to code Visual C++ for a number of years. The
executable code in the form1.h file is what is confusing me the
most. )

thanks,

-Steve
 
Steve said:
using vs2005, the wizard created a c++ forms project for me. Now in
the form1.h file I have a menu item click handler that I would like to
add some win32 api code to:

private: System::Void
tapeToolStripMenuItem_Click( System::Object^ sender,
System::EventArgs^ e)
{

HANDLE hTape = CreateFile( "\\\\.\\TAPE0", GENERIC_READ |
GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL);

}

What header file do I use for the HANDLE and DWORD macros? Where do I
place the #include stmts in the form1.h file?
Click to expand...

Same as always: said:
I need to use other win32 APIs like SetTapePosition and I got the
function declaration to be accepted in the main project .cpp file.
But linkage failed because of "unresolved externals
SetTapePosition". How do I add kernel32 to my project?
Click to expand...

Just add it to the list of libraries on the linker input settings page.
( I actually used to code Visual C++ for a number of years. The
executable code in the form1.h file is what is confusing me the
most. )
Click to expand...

IMO, it's best to keep your managed and unmanaged code in separate files,
using self contained header files as the linkage between them (i.e. header
files that don't depend on windows.h or the C++ standard library - the fewer
dependencies that need to cross the managed/unmanaged boundary - both at
runtime and at compile time - the better).

Surround the #include of your native header files with pragmas to control
the managed/unmanaged settings:

#pragma managed(push,off)
#include "mynativeheader.h"
#pragma managed(pop)

-cd
 
Back
Top