Hello out there...

[Michael L. Barker]

For days now I've been trying to figure out how to use the SendMessage API
in VB.NET. I've searched the net, and posted all over the place. I have yet
to talk to a person who can help me. I don't mean to sound short about this,
but this is really an easy thing. In VB6, it was cake. So I'm going to try
this once again...

The Declares!

Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" (ByVal
lpClassName As String, ByVal lpWindowName As String) As Int32
Declare Function FindWindowEx Lib "user32.dll" Alias "FindWindowExA"
(ByVal hWnd1 As Int32, ByVal hWnd2 As Int32, ByVal lpsz1 As String, ByVal
lpsz2 As String) As Int32
Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA"
(ByVal hwnd As Int32, ByVal wMsg As Int32, ByVal wParam As Int32, ByRef
lParam As Int32) As Int32

Const WM_GETTEXT As Int32 = &HD
Const WM_GETTEXTLENGTH As Int32 = &HE
Const WM_SETTEXT As Int32 = &HC


The Code!

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim NotePad_Win As Int32 = FindWindow("Notepad", vbNullString)
Dim Notepad_Edit As Int32 = FindWindowEx(NotePad_Win, 0, "Edit",
vbNullString)

SendMessage(Notepad_Edit, WM_SETTEXT, 0, ByVal("Testing!!!!!!!"))

MsgBox(Notepad_Edit)
End Sub

I understand that you can't use ByVal in VB.NET, why is this? What else can
I do? I thought "With Visual Studio.NET you code less, and have more time to
do what you do best 'think'" So what is MS trying to do now, forcing us on
that framework? If so, wrap the API already (ALL OF IT).

 

[Ken Tucker [MVP]]

Hi,

Overload the sendmessage to api to accept the types you want to
send.

Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal
hwnd As Int32, ByVal wMsg As Int32, ByVal wParam As Int32, ByRef lParam As
String) As Int32



SendMessage(Notepad_Edit, WM_SETTEXT, 0, ("Testing!!!!!!!"))



Ken

 

[Jeremy Todd]

For days now I've been trying to figure out how to use the SendMessage API
in VB.NET. I've searched the net, and posted all over the place. I have yet
to talk to a person who can help me. I don't mean to sound short about this,
but this is really an easy thing. In VB6, it was cake. So I'm going to try
this once again...

It might be helpful if you told us what problem you're having and what
exception (if any) is being thrown. Just in case it helps, the definition
of SendMessage I am using is:

<DllImport("user32.dll", CharSet:=CharSet.Auto)> _
Public Shared Function SendMessage( _
ByVal handle As IntPtr, _
ByVal message As Integer, _
ByVal wParam As IntPtr, _
ByVal lParam As IntPtr _
) As Integer
End Function

For your purposes, you'd probably just want to change the type of lParam
from IntPtr to String. .NET usually handles type conversions to API calls
very well.

I tend to avoid the Declare syntax, just because it's more or less a
holdover from VB6, and hides what is really going on. The DllImport way
shows how things are really working, and is also in line with how the other
..NET languages do it.

I understand that you can't use ByVal in VB.NET, why is this? What else can
I do? I thought "With Visual Studio.NET you code less, and have more time to
do what you do best 'think'" So what is MS trying to do now, forcing us on
that framework? If so, wrap the API already (ALL OF IT).

The Windows API will be deprecated starting in the next version of
Windows (aka Longhorn). It's probably not a bad idea to stop relying on it
as much as possible.

Jeremy

 

[Michael L. Barker]

Thank you! I love you! Thank you! =) =)

How can I learn more on this DLLImport? So in the next version of windows,
the FindWindow call will be in a class?.... hmmm

 

[Jeremy Todd]

How can I learn more on this DLLImport?

Well, just look it up in the docs (under DllImportAttribute).
There's really not that much to it, and I don't think doing it the DllImport
way magically solved your problem in this case -- it was just a matter of
getting the right parameter types for what you wanted to do with it.
DllImport and using the Declare syntax are really pretty much the same;
Declare is just a shortcut designed to make VB6 users more comfortable.

So in the next version of windows, the FindWindow call will be in a class?

Not exactly. In Longhorn, the whole Windows API will be replaced by a
new system called WinFX, so FindWindow may not even exist in its current
form. Of course, I'm sure the Windows API will continue to function for
many years for backward compatibility, but continuing to use it for new
applications would be like sticking with 16-bit code in Windows 95.

Jeremy

 

[Arshad S]

Hi,
I just how u explained for SendMessage API.
<DllImport("user32.dll", CharSet:=CharSet.Auto)> _
Public Shared Function SendMessage( _
ByVal handle As IntPtr, _
ByVal message As Integer, _
ByVal wParam As IntPtr, _
ByVal lParam As String _
) As Integer
lParamr string giving Windows text not the text in address bar ie URL.
Could u plz help me how to get URL from the address bar
by using any one of the API
Thanks

 

[Trancedified]

With the SendMessage, can you use GETTEXT to retrieve a telephone
number after the phrase:

Telephone#: 111-000-0000

I cannot hardcode.


Chris

 

[Tom Shelton]

With the SendMessage, can you use GETTEXT to retrieve a telephone
number after the phrase:

Telephone#: 111-000-0000

I cannot hardcode.


Chris

 

[Cor Ligthert]

Yes.

Are you sure?

Cor

 

[Tom Shelton]

Are you sure?

Cor

Well, yes... Assuming that the text is contained in a control that has
a window handle I'm assuming you're refering to my short answer -
but I gave a more detailed answer to a similar question by the same OP.
I suppose I should have refered them there

The problem is that they will have to use P/Invoke to do this.

 

[Cor Ligthert]

Hi Tom,

Sorry then I was thinking you where joking and did want to complete it.

I only see what for me seems a question and you answer.

Cor

 

[Herfried K. Wagner [MVP]]

The problem is that they will have to use P/Invoke to do this.

Problem?

;-)

 

[Tom Shelton]

Problem?

;-)

Well, some people feel it is a problem. Personally, it doesn't bother
me a bit... Don't get me wrong, if there is a choice between the
framework and P/Invoke, I take the framework - but I have no qualms
about using the API when I deem it necessary

 

[Tom Shelton]

Hi Tom,

Sorry then I was thinking you where joking and did want to complete it.

I only see what for me seems a question and you answer.

Cor

Quite all right. In hindsight, I should have refered the op to my other
post.

 

[Herfried K. Wagner [MVP]]

Well, some people feel it is a problem. Personally, it doesn't bother
me a bit... Don't get me wrong, if there is a choice between the
framework and P/Invoke, I take the framework - but I have no qualms
about using the API when I deem it necessary

Full ACK, but as the task is stronly related to Windows, I don't see any
reason for not using p/invoke.