SendDlgItemMessage overflow

Hello,

I'm using the following code to automatically print a file to some other file:

Call ShellExecute(0, "print", sFile, "", "", SW_HIDE)

hwnd = FindWindow(vbNullString, "Print To File")
Do While hwnd = 0
hwnd = FindWindow(vbNullString, "Print To File")
DoEvents
Loop
If hwnd <> 0 Then
iii = SendDlgItemMessage(hwnd, 1152, WM_SETTEXT, 0, aFile)
iii = SendMessage(hwnd, WM_SHOWWINDOW, 0, 0)
lObjhWnd = FindWindowEx(hwnd, 0, "Button", "OK")
iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)
DoEvents
End If

aFile is the file I want to print to. So basically what I do is that I send a file to the printer with the ShellExecute command, the files application opens, and then I wait until the "Print to File" dialog box appears (I'm using a file printer) and then the program should write the outputfile name and press the OK button on that dialog box. That's the idea though...but it doesn't work :(
I get an "Run time error 6 - Overflow" on the SendDlgItemMessage line. Any idea on what it might be?

Thanks in advance!

What have you declared your iii variable as?

If the variable type isn't big enough to store the data then it will give you overflow.

Try dim iii as long, if it returns a number as I think it does

Hi,

Thanks for your reply. It is already declared as long :S
I saw before, by searching on Google, that the same question has appeared on this forum. I think it was in 2001 or so hehe. But I didn't see any answer to it :S

It would be really nice to resolve this. In that post the author said it works perfectly well in Windows 95, but on later versions it crashes with the same error message that I got :S

Maybe you dont have the correct window handle because your using "hwnd" which is a default property of the owner form. Also What is the contenets of the aFile variable? That is the lParam and should be passed ByVal if your wanting the actual value passed and not the pointer to the variable in memory. When you shellexecute the "print" it processes immediatly and does not wait for a user input. But then perhaps your running a different OS from mine (XP Pro SP2)?


This is what I set up and it doesnt fo into the SendDlgItemMessage block because the handle is Null because of the shellexecute issue.

VB Code:

Option Explicit
 
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, _
ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
 
Private Declare Function FindWindow Lib "user32.dll" Alias "FindWindowA" (ByVal lpClassName As String, _
ByVal lpWindowName As String) As Long
 
Private Declare Function SendDlgItemMessage Lib "user32.dll" Alias "SendDlgItemMessageA" (ByVal hDlg As Long, _
ByVal nIDDlgItem As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
 
Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, _
ByVal wParam As Long, ByRef lParam As Any) As Long
 
Private Declare Function FindWindowEx Lib "user32.dll" Alias "FindWindowExA" (ByVal hWnd1 As Long, ByVal hWnd2 As Long, _
ByVal lpsz1 As String, ByVal lpsz2 As String) As Long
 
Private Const SW_HIDE As Long = 0
Private Const WM_SETTEXT As Long = &HC
Private Const WM_SHOWWINDOW As Long = &H18
Private Const BM_CLICK As Long = &HF5&
 
Private Sub Form_Load()
    Dim aFile As String
    Dim sFile As String
    Dim lObjhWnd As Long
    Dim lHwnd As Long
    Dim iii As Integer
    
    aFile = "C:\Test.txt"
    sFile = "C:\Test2.txt"
    
    Call ShellExecute(0, "print", sFile, "", "", SW_HIDE)
    
    lHwnd = FindWindow(vbNullString, "Print To File")
    Do While hwnd = 0
        lHwnd = FindWindow(vbNullString, "Print To File")
        DoEvents
    Loop
    If lHwnd <> 0 Then
        iii = SendDlgItemMessage(lHwnd, 1152, WM_SETTEXT, 0, ByVal aFile)
        iii = SendMessage(lHwnd, WM_SHOWWINDOW, 0, 0)
        lObjhWnd = FindWindowEx(lHwnd, 0, "Button", "OK")
        iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)
        DoEvents
    End If
 
End Sub

Thanks a lot for your help. aFile is a String variable, and yeah it's probably sent as a reference.
Also, I'm using Windows 2000. I will try out your code, and hopefully it will work :)
"This is what I set up and it doesnt fo into the SendDlgItemMessage block because the handle is Null because of the shellexecute issue." Don't know quite what you mean with that? :blush:
So you say it works for you?

No, it only prints the shellexecute file immediatly and the FindWindow api cant get the dialog handle since its already destroyed. This is why I was wondering what print dialog comes up for you as I only get a small "printing" dialog for a milisecond.

Wouldnt it be easier to just do a FileCopy of the printed file and rename it as a way of duplicating what file and contents were shellexecuted (printd)?

Interesting :)
That is exactly what I wanted! For the dialog box not to appear and the file to be printer immediately :) Or did I misunderstand you?

I am using the printer that prints to a file. So "Print to File" dialog box appears with a textbox in which you should write an output file name.

The thing is, I can't even print the file automatically, because of that dialog box. That's why I want to catch it and write a file name into it's textbox so that it prints the file to the file I specified in the textbox.

Hmm, let me fire up my 2000 pro system and test.

First of all, if you're sending a string as the last argument to SendDlgItemMessage you should declare that argument as ByVal lParam As String or possibly as lParam As Any and specify ByVal in the call.

Secondly what is 1152 which you pass as the second argument? Are you sure that is the identifier of the control you're after? Where did you come up with that number?

Yes, I have ByVal in my test code but the 1152 may be the dlgctlitem number? I wasnt able to test it because my 2000 system is not on my network and I'm having an issue getting my printer shared across domains. :(

That's a good question hehe. I don't know what that number should mean hehe...I got this code from Google when I searched on how to solve my problem. It's from a page called something like "freeVBcode"...something like that...I'll check it up tomorrow.

The dialog item ID is something very different from a hWnd, it's different for different controls, even for controls of the same type. For example the ID for a OK button is IDOK while it's IDCANCEL for a Cancel button even though both are CommandButtons. So a suggestion, instead of using FindWindowEx to get the handle of the OK button, use GetDlgItem with the ID of IDOK. That way you'll get the hWnd of the OK button regardless of what text it might have (not all languages use "OK", you know :)).

Aha..thx a lot :)

I'll look it up on Google, on how to use GetDlgItem...sometimes I find it hard to find good explanations of API functions...do you have any nice links to a collection (and good explanation of the syntax) of API functions?

This is a good one - http://www.allapi.net/

AllAPI.net is a good place. However to get the hWnd of the OK button in a dialog using GetDlgItem the code would look like this:

VB Code:

'Declaration:
Private Declare Function GetDlgItem Lib "user32.dll" ( _
    ByVal hDlg As Long, _
    ByVal nIDDlgItem As Long
) As Long
Private Const IDOK As Long = 1
 
'in some sub or function:
'The hDlg argument of GetDlgItem is the same thing as the hWnd of the dialog box
'This example already assumes you have the hWnd of the dialog
Dim hButton As Long 'the hWnd of the button
hButton = GetDlgItem(hWnd, IDOK)
'hButton now contains the hWnd of the OK button.
Call SendMessage(hButton, BM_CLICK, 0&, ByVal 0&) 'click it

Thx a lot. But I still need to send the output file name to the text box. Which function should be used then?

Also, I have this code for the moment:

Call ShellExecute(0, "print", sFile, "", "", SW_HIDE)

lHwnd = FindWindow(vbNullString, "Print to file")
Do While lHwnd = 0
lHwnd = FindWindow(vbNullString, "Print to file")
DoEvents
Loop

The thing is, this opens Word (because sFile is a .doc file), but the program stops at the ShellExecute line and after I close the window lHwnd is 0...so it waits until I end Word and then it can't find the dialog box of course...so how could one make the program to continue...use some other function than ShellExecute?

Maybe you could simply try to automate Word instead? RobDog is the expert on VBA automation so he can probably show you some sample code of that quicker then I can :)

Thanks Joacim but the doc extension is handled differently then a textfile. It starts a instance of word and automates a print call through it to the default printer. We can duplicate this by opening an instance of Word and calling the print command but also after that we could invoke a .SaveAs call and specify a txt document type with a specified filename etc. Does this sound like what you want/need?

Here is one possible solution:
Automate Word, open the document, print it, print to file.

Note: You can do the .SaveAs instead if you need a different fileformat.

VB Code:

Option Explicit
'Add a reference to MS Word xx.0 Object Library
Private Sub Command1_Click()
    Dim oApp As Word.Application
    Dim oDoc As Word.Document
        
    Set oApp = New Word.Application
    oApp.Visible = False
    Set oDoc = oApp.Documents.Open("C:\Test.doc")
    oDoc.PrintOut Background:=True
    oDoc.PrintOut Background:=True, OutputFileName:="C:\Test2.doc", PrintToFile:=True
    oDoc.Close SaveChanges:=False
    Set oDoc = Nothing
    oApp.Quit
    Set oApp = Nothing
End Sub

Yeah that's great. I have written same code before in some other programs where I used Word. But now actually, the file that I am printing is from an application called Design Capture, so not Word. And I don't know if it's possible to somehow have a reference in Basic to that application?

Hmm, ok then that changes allot. You could look under the references in VB to see if there is an entry for your 3rd party program but if it supports any automation only you would know as we dont have whatever program it is.

Yeah of course. I'll find out if I can use it immediately in Basic.

I'm very grateful for your interest in my problem and also for the help u provided me!
Hopefully that will be the case in the future too! :)

If nothing else works, maybe you should use FindWindowEx instead of SendDlgItemMessage to get the handle of the control you want to send text to and use SendMessage to it instead. Simular to what you did to get the handle of the OK button. You would need to know the class name of the control which you can find out using Spy++, or my own Window Finder Tool.

Oh that's great Joacim :)
Thx a lot guys! I'll try out all this tomorrow!

Hi again,

I'm wondering Joacim, the last thing you wrote, how could I use the handle and the class I found with your tool in the code?
I have this code for the moment:

hwnd = FindWindow(vbNullString, "Print To File")
Do While hwnd = 0
hwnd = FindWindow(vbNullString, "Print To File")
DoEvents
Loop
If hwnd <> 0 Then
iii = SendDlgItemMessage(hwnd, 1152, WM_SETTEXT, 0, aFile)
iii = SendMessage(hwnd, WM_SHOWWINDOW, 0, 0)
lObjhWnd = FindWindowEx(hwnd, 0, "Button", "OK")
iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)
DoEvents
End If


So you mean I could skip the FindWindow and SendDlgItemMessage and immediately supply the handle and class in the FindWindowEx and SendMessage? Where should I write in the class? Handle is hwdn in the code right? Thanks in advance!

Dont use "hwnd" as a variable as its the default handle of your form and not your FindWindow call. ;)

OK I changed hwnd to temp now :)
Still, what did Joacim mean in his post? How does the class come in?

I also then need the class and handle of the textbox (that appears in the print to file dialog box), and then send text to it. But how can I use those classes and handles that Joacim's program provides?

I have the following code in the if-statement now:

iii = SendMessage(temp, WM_SHOWWINDOW, 0, 0)
lObjhWnd = FindWindowEx(temp, 0, "Button", "OK")
temp2 = FindWindowEx(temp, 0, "TextBox", "")
iii = SendMessage(temp2, WM_SETTEXT, 0, 5)
iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)

temp is the handle of the "Print to file" window.
I hope that the number 5 will appear in the textbox, but that doesn't happen :(. Also, I would like to send a string argument to SendMessage, but that doesn't seem to be possible because the argument should be of type long (while it's possible with SendDlgItemMessage).

This is the code I have inside the If-statement (the program enters the if-statement, which means that it finds the "Print to file" dialog box):

iii = SendMessage(temp, WM_SHOWWINDOW, 0, 0)
lObjhWnd = FindWindowEx(temp, 0, "Button", "OK")
temp2 = FindWindowEx(temp, 0, "ThunderTextBox", vbNullString)
iii = SendMessage(temp2, WM_SETTEXT, 0, 5)
iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)
DoEvents

Now what happens is that lObjhWnd and temp2 are 0 :(, so probaby it can't find the OK button and textbox (I found out that the class name for the textbox is ThunderTextBox). What could be wrong? Thanks.

Something interesting happens now :)

When I hold up the "Print to file" dialog box and run the VB program again it manages to find the window, the button and the textbox! :)
Now I'm wondering, how can I send some text to the textbox?
I'm using SendMessage, but it doesn't work:

iii = SendMessage(temp2, WM_SETTEXT, 5, 0)

That should display number 5 in the textbox no? temp2 is the handle for the textbox. Thanks in advance!

IT WOOOORKS!! :)

I used the SendKey API instead and sent the text with it. Now one problem that I think can appear is that the same text would be sent to all applications with textboxes, wouldn't it? Is there some way to send text only to that textbox on the "Print to file" dialog box? Must I then use SendMessage, which didn't work for some reason?

Quote:

---

Originally Posted by RobDog888

Dont use "hwnd" as a variable as its the default handle of your form and not your FindWindow call. ;)

---

That doesn't matter. You can locally declare a variable inside a Sub or Function and name it hWnd if you like. Whenever you then use hWnd within that procedure the local variable is used and you would need to use Me.hWnd (or for example Form1.hWnd) to be able to use the property of the Form. It's always the closest scope that is used.

Quote:

---

Originally Posted by Striver

This is the code I have inside the If-statement (the program enters the if-statement, which means that it finds the "Print to file" dialog box):

iii = SendMessage(temp, WM_SHOWWINDOW, 0, 0)
lObjhWnd = FindWindowEx(temp, 0, "Button", "OK")
temp2 = FindWindowEx(temp, 0, "ThunderTextBox", vbNullString)
iii = SendMessage(temp2, WM_SETTEXT, 0, 5)
iii = SendMessage(lObjhWnd, BM_CLICK, 0, 0)
DoEvents

Now what happens is that lObjhWnd and temp2 are 0 :(, so probaby it can't find the OK button and textbox (I found out that the class name for the textbox is ThunderTextBox). What could be wrong? Thanks.

---

ThunderTextBox is the class name of a VB textbox. However I doubt very much that the "Print to File" dialog box is made in VB. A normal Windows textbox has the class name "Edit" but Word for example uses RichTextBoxes in all of its dialog boxes. However the Print to File dialog is probably a standard dialog and not one of Words own dialogs so I'm not sure what the class name of this is. That's what you should use the Window Finder Tool (or Spy++) for. If you manually would bring up this dialog on the screen and then drag the small magnifying glass icon from the Window Finder Tool to the textbox in this dialog you will see the class name (you will also see the current hWnd this textbox has but you can't use that number since it will be different each time the application runs).

So with the exception of the class name in your code above the FindWindowEx call looks correct. Provided that you change the class name to the correct one you should get the handle (the hWnd) of the first available textbox in the dialog.

However the SendMessage call is wrong. SendMessage is declared in this fashion (with our without the linebreaks :)):

VB Code:

Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" ( _
    ByVal hWnd As Long, _
    ByVal wMsg As Long, _
    ByVal wParam As Long, _
    ByRef lParam As Any _
) As Long

If you look at the arguments of SendMessage the first 3 accepts a Long which is passed "by value" while the fourth argument is declared as Any and is passed "by reference" (the ByRef keyword above is actually redundant since that is the default in VB, but I left it there for clarity). The reason for this is that SendMessage can be used for any type of message and different messages accepts different type of arguments. Some expect a string (WM_SETTEXT for example) while others expect an integer (or Long), and some expects more complex data in the form of a structure (or User Defined Type as they are called in VB). In most cases a pointer (or memory address) to the data is expected and that is why you would pass it "by reference". However the different ways VB handles strings and the way the API handles them differs. VB will translate the string you pass to an API so it can be handled correctly but it requires that the string is passed "by value" instead of "by reference". In your code you don't pass a string at all, you pass the number 5 which is an integer. If you would like to set the text to 5 you would do the call in this manner:

VB Code:

iii = SendMessage(hWndTextBox, WM_SETTEXT, 0, ByVal "5")

Notice the quotation marks around the number 5 which turns it into a string and also that I pass it "by value" by using the ByVal keyword.

SendKeys is not an API call but rather a VB statement. It will send key strokes to the window (or control) that currently have focus. Unless you are absolutly certain that the text box you want to send text to has focus I wouldn't recommend using SendKeys (many things can go wrong, the dialog might for some reason never gain focus, or the user might press the tab key (or Alt+Tab, Alt+Esc, Ctrl+Esc or some other key combination) at the wrong moment which would switch focus. It's safer to get the SendMessage call to work.

[quote=Joacim]That doesn't matter. You can locally declare a variable inside a Sub or Function and name it hWnd if you like. Whenever you then use hWnd within that procedure the local variable is used and you would need to use Me.hWnd (or for example Form1.hWnd) to be able to use the property of the Form. It's always the closest scope that is used.
[/qoute]But it wasnt declared as a variable. :)

Quote:

---

Originally Posted by RobDog888

But it wasnt declared as a variable. :)

---

Or maybe it was but that part of the code wasn't posted :). You can even declare hWnd as a module level variable (in the General Declaration section of the Form) without any errors.

If it wasn't declared then please make sure you always declare all variables before you use them. Add Option Explicit to all modules or click Tools > Option and check the Require Variable Declaration option and VB will do this automatically for you in every new module (with that I mean any type of module, regular ones, Forms, and classes) you create.

Thx a lot Joacim for that big explanation!
I recognize a lot of that from C++ and Java :) Also, in my last post (when I wrote that it works :)), I forgot to mention that I changed the class to "Edit"
instead (I used your Tool to find out the class). But from the beginning it was actually a ThunderTextBox (in some strange way) and then it just changed to Edit...kind of strange (maybe I was dragging the magnifying glas to some other window without noticing it or something :S).

I will try out the syntax of the SendMessage that you wrote. I was also very suspicious of SendKeys, because of the reason that u also mentioned. So I hope that the SendMessage command will work :). Now I do get a window and button handle, but before I didn't (no clue of why, just started to work for some reason haha!). Also my question is, is it good to use the ShellExecute function to print a file? I thought that was the problem of why I didn't get a handle for the "Print to file" window in the beginning, because the program continues executing even though the dialog box hasn't appeared yet. But I think I recall that ShellExecute waits untill it executes it's command? It works now though hehe...so probably there was something else going on before when it didn't work.

Thank's a lot guys, you have been really nice to help me!

Quote:

---

Originally Posted by Striver

But from the beginning it was actually a ThunderTextBox (in some strange way) and then it just changed to Edit...kind of strange

---

That would be more than strange since it's not possible. :)

I don't see a problem with using ShellExecute as long as the Print verb is associated with the particular file you're using.

I have a question I forgot to ask last time I posted...how do you know what hexadecimal values those constants that are sent to API functions should have (like WM_SETTEXT = &HC)?

I just tested to use SendMessage like you said Joacim, and it didn't work even thought it finds the textbox. Maybe WM_SETTEXT is set to a wrong value?

Thanks in advance.

OK, resolved...I used the API viewer and it says that WM_SETTEXT = &HC, so it's correct. Why will the text not appear in the textbox then?

Are you really sure you have the handle of the correct textbox? Does the dialog contain more then one? BTW you can download a much better API Viewer from here.

The dialog box contains only one textbox, so it should be it right?

You could always compare the return value you get from FindWindowEx with what is shown in the Window Finder Tool.

You mean comparing the handle values? Converting the hexadecimal handling value found by your program to an integer, and then comparing with the integer in the program? But are those handles constant, or do they change very often?

They could change each time the dialog is displayed but you could just comment out the line that closes the dialog so that it stays on the screen. Just do a Debug.Print with the handle (you can use the Hex function to print it in hexadecimal form for easier comparison).

Ok great...I'll try it out. But what if it's the correct handle? Any ideas on what might be wrong?

If you have the correct handle and are using SendMessage the correct way it should work. I have no idea why it doesn't for you. What are the return value from the SendMessage call?

Well when I tried it out today, I got 0...I'll try tomorrow again (it's at my job) and update this thread with what I got (also I'll check if I have the right handle). Hopefully u'll be here tomorrow too :)
Thx a lot by the way!

0 means the SendMessage call failed.

Yeah...which could be that the handle for the textbox (which it's trying to send text too) is wrong? I used the "ByVal" statement as you wrote earlier also...well, I'll come back with more info tomorrow :)

I'm back :) I checked the handle, and it's the same handle as the WindowFinder tool gives me. And also it seems to work now! Guys, thx a lot for the help!