using Windows API in VB.Net?

[Martin Ortiz]

I want to use the Win32 API function : SendMessageToDescendants

I want to use it in a VB.Net app, but I have a few questions.....

1) Can one use Win32 API functions in VB.Net
2) Is doing so a "no no"
3) are VB.Net windows, underneath the covers, Win32 windows? and can be
treated as such?

 

[William Ryan]

You can definitely using the Win32 API in .NET, to perform many tasks you
have to. The framework is still work in process, and there are zillions of
Win32 API's that aren't supported yet.

Is it a no-no? No, not at all. In fact, much of the Framework is merely
API calls wrapped for managed code.

Not sure exactly what you mean by Treated by in the third one...but what are
you trying to do? Just sendmessagetoDescendants or something else?

 

[Martin Ortiz]

VB6 had that Win API function prototype utility, does VS.Net have one? How
do I find the correct prototype to use for my Win32 API function?

 

[Jay B. Harlow [MVP - Outlook]]

Martin,

1) Can one use Win32 API functions in VB.Net

Yes, However I would recommend you make sure you really need to & more
importantly want to. I've seen a number of people decide they need to use
API x, although API x is already part of the framework as feature y, they
use API x instead of feature y. In other words use the Framework if its part
of the Framework. Which means you need to learn the Framework ;-)

2) Is doing so a "no no"

Normally I try to isolate any Win32 API functions to a single module/class,
think Encapsulation. And to a lesser extent Isolation.

3) are VB.Net windows, underneath the covers, Win32 windows? Yes,

and can be treated as such?

Most of the time, Yes! In fact System.Windows.Forms.Control has a Handle
property which is the Win32 HWND.

I want to use the Win32 API function : SendMessageToDescendants

The problem is SendMessageToDescendants is NOT a Win32 API!!

It is a MFC/ATL API (C++ function), you cannot directly call MFC or ATL
functions. The SendMessageToDescendants function uses the GetTopWindow Win32
API followed by the GetNextWindow Win32 API.

Rather then mess with attempting to call a MFC functions, I would find the
Framework method of doing it. The Control.Controls collection represents all
of the controls on the Form or contained Control. While Form.OwnedForms
represents all the owned forms and Form.MdiChildren represent all the owned
MDI Children.

I would enumerate (For Each) one of these collections and 'send the message'
to each of these, using recursion if needed. Where 'send the message' is
probably a member of an interface that each child implements or a member of
a base class that each child inherits from. Which means I am actually
calling a routine on the object! On rare exceptional cases it would be the
SendMessage Win32 API. Note in order to receive a message sent with
SendMessage you normally override the Control.WndProc sub routine.

Remember .NET is all about OOP. ;-)

Hope this helps
Jay

 

[Nice Chap]

Hi Martin, one of the main goals of Dotnet is to provide "platform
independence", but by using Windows API, you are directly impacting upon
your program's portability. It is NOT a good practice to use Windows APIs
unless it is ABSOLUTELY necessary !!

In your case, I would advise you to follow Jay's approach of using
For...Each but instead of using SendMessage see if you can make use of any
Property or Method of the control.

 

[Herfried K. Wagner [MVP]]

I want to use the Win32 API function : SendMessageToDescendants

I want to use it in a VB.Net app, but I have a few questions.....

1) Can one use Win32 API functions in VB.Net
Yes.

2) Is doing so a "no no"

No, you can use them, no problem.

3) are VB.Net windows, underneath the covers, Win32 windows? and can be
treated as such?

They are Win32 windows.

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi all,

You are right - what have been said in the replies is absolutely valid only
until we are talking about the Windows platform. I realize there are no
official .Net releases for other platforms - and they might even never
appear (Mono and dotGNU are amateur projects in no way related to
Microsoft), but if the original poster believes his application has good
chances to be ported - I would at least encapsulate the platform-dependent
stuff as jay Harlow have suggested.

P.S. Putting all flavours of Unix/Linux/FreeBSD aside, one could probably
imagine old-fashion APIs going away in some future Windows release.

 

[Cor]

Hi Martin,

VB6 had that Win API function prototype utility, does VS.Net have one? How
do I find the correct prototype to use for my Win32 API function?

You could not beter shown that Jay B is right in what he wrote than with
this answer.

While I look at the times, I understand that you had, when you wrote this,
not yet read that.

Cor

 

[Martin Ortiz]

I come from a MFC background....and at time of post didn't check how the
SendMessageToDescendants was actually implemented....
I will use the approach you suggested instead, which sounds better, rather
than using a Win32 API function

 

[Martin Ortiz]

Just a little background info on a general problem I'm trying to find a
solution for....(and why SendMessageToDescendants was being looked at)

(in VC 6 and VB6)
On a previous program, I had written an ATL control, this was used in VB
control in VB6, which in turn was part of a composite control, which in turn
was finally on a form.
The recommend to inform the parent of whatever activity was to bubble events
up....
i.e. my ATL control would generate an event, it's host would re-generate the
same event, on and upward.....sounds hunky dory right?
THEN when I had to issue "orders" from the top down, I would do the same in
reverse (but not using events of course), my main form would call a method
on a control, which would in turn call a method on its embedded control,
etc...till it got "bubbled down" to the appropriate call.

All in all, sounds good in theory, but in practice it becomes a maintenance
nightmare, especially when you're changing things around.

In VB.Net an elegant solution to the first issue (bubbling events up), is
easily solved by having on initial event bubbled upward (just once during
init phase), this initial event will contain what ever necessary info that
whom ever is listening can hook into with the AddHandler function, and it's
a loosely coupled arrangement, making maintenance nice and easy

So instead of
Control--- (bubbling event)--->HostControl---(bubbling
event)--->CompositeControl--->--- (bubbling event)--->Form

we get
Control---->Form

(making maintenance a breeze)

The next problem is doing this in reverse, using something similar to
SendMessageToDescendants (an MFC based function)