replacement for #include?

[Michael Roper]

I'd like have a file with all of my Win32API stuff in it:

namespace myStuff.Interop Types
{
using HBITMAP = System.IntPtr;
using HWND = System.IntPtr;

public struct POINT
{
public int x;
public int y;
}
}

and then be able to do something like this in another file:

using myStuff.Interop Types;
namespace myStuff.myProje ct
{
[DllImport( "user32.dll " )]
static extern bool SomeFunc( HWND hWnd, HBITMAP hBitmap, POINT point );
[...]
}

which doesn't work since the 'using' aliases from the first file aren't
visible outside that compilation unit. Is there another way to do this?

Michael Roper

[Michael Roper]

> namespace myStuff.myProje ct

Not that it matters for the question at hand, but that should instead be
"public class myClass" or some such.

Michael Roper

[Daniel O'Connell]

The only thing I can think of is rather ugly, but it should work, it uses an
implicit conversion, just directly using IntPtr would probably be far
better:
public struct HWND
{
HWND(IntPtr p)
{
ptr = p;
}
System.IntPtr ptr;
public static implicit operator HWND(IntPtr p)
{
return new HWND(p);
}
}

Maybe someone else has a better solution?
"Michael Roper" <mi******@encra ft.com> wrote in message
news:bk******** ****@ID-160215.news.uni-berlin.de...

I'd like have a file with all of my Win32API stuff in it:

namespace myStuff.Interop Types
{
using HBITMAP = System.IntPtr;
using HWND = System.IntPtr;

public struct POINT
{
public int x;
public int y;
}
}

and then be able to do something like this in another file:

using myStuff.Interop Types;
namespace myStuff.myProje ct
{
[DllImport( "user32.dll " )]
static extern bool SomeFunc( HWND hWnd, HBITMAP hBitmap, POINT point );
[...]
}

which doesn't work since the 'using' aliases from the first file aren't
visible outside that compilation unit. Is there another way to do this?

Michael Roper

[Michael Roper]

Daniel O'Connell writes:

The only thing I can think of is rather ugly, but it
should work, it uses an implicit conversion, just
directly using IntPtr would probably be far better:

Thanks Daniel, I'll play with it and see how it looks in IL. You're right
though, it is ugly! Guess I was hoping for a "oh, here's how you do a text
include..."

I guess I don't understand why (since text includes are disallowed) the
"using <namespace>" and especially the "using =" statements can't actually
be compiled into a namespace (you know...so I could do what I want :).
Where's the harm?

Michael Roper

[Daniel O'Connell]

"Michael Roper" <mi******@encra ft.com> wrote in message
news:bk******** ****@ID-160215.news.uni-berlin.de...

Daniel O'Connell writes:

The only thing I can think of is rather ugly, but it
should work, it uses an implicit conversion, just
directly using IntPtr would probably be far better:
Thanks Daniel, I'll play with it and see how it looks in IL. You're right
though, it is ugly! Guess I was hoping for a "oh, here's how you do a

text include..."

I guess I don't understand why (since text includes are disallowed) the
"using <namespace>" and especially the "using =" statements can't actually
be compiled into a namespace (you know...so I could do what I want :).
Where's the harm?
Don't know if there is a specific harm, it just doesn't seem to be an
apparent usage. I don't know if the design team ever even thought that
someone may want to alias a type to another type within a specific
namespace(which , IMHO, is much better than a typedef or #define that applies
globally).
One thing I could see is its a bit confusing. I HATED C\C++ code where I'd
see declarations like this(hopefully correct, its been a while):

typedef DWORD unsigned int;
typedef UINT DWORD;
typedef MYHANDLE UINT;
typedef YOURHANDLE MYHANDLE;
//then to throw some really oddities in, what if they did this?
//is this even allowed...its been so long I can't remember..think it is.
#define YOURHANDLE unsigned char

I would then find a reference to YOURHANDLE somewhere, and not really have a
clue as to what it was. Having an exact type name can save alot of
frustration in the long run. Which is also a good part of why that code I
posted earlier is ugly as well, you still don't really know that HWND is
actually an IntPtr, or if looking at a method without intellisense or the
docs, that the method doesn't take a IntPtr anyway.

Michael Roper

[Michael Roper]

Daniel O'Connell writes:

Which is also a good part of why that code I
posted earlier is ugly as well, you still don't
really know that HWND is actually an IntPtr,
or if looking at a method without intellisense
or the docs, that the method doesn't take a
IntPtr anyway.

Right, that's why I'd have a clear preference for the 'using =' construct if
it worked. It's really nice (especially as an old, old WinAPI guy) to be
able to see my PInvoke imports defined the way I've always used them, and
get the "truth" from Intellisense if I need it.

Michael Roper

[Daniel O'Connell]

"Michael Roper" <mi******@encra ft.com> wrote in message
news:bk******** ****@ID-160215.news.uni-berlin.de...

Daniel O'Connell writes:

Which is also a good part of why that code I
posted earlier is ugly as well, you still don't
really know that HWND is actually an IntPtr,
or if looking at a method without intellisense
or the docs, that the method doesn't take a
IntPtr anyway.
Right, that's why I'd have a clear preference for the 'using =' construct

if it worked. It's really nice (especially as an old, old WinAPI guy) to be
able to see my PInvoke imports defined the way I've always used them, and
get the "truth" from Intellisense if I need it.
It seems your options are pretty restricted, I can see that the type is of
use(and this is a situation where I would use hungarian notation, marking
variables with h or hwnd). However, such a feature would probably be abused
commonly for less useful reasons, similarly to how C libs often used extra
typedefs simply to change the name, it got annoying and started to really
get ridiculous Michael Roper