I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to traps calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the "Ok" button, and finally trap calls to EndDialog.
It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly.
Is there a simpler way to programatically click "Ok" on a dialog box? (The dialog box coming from code that I don't have source for...)
Hi,
On Tue, May 03, 2005 at 12:36:09AM -0700, Kees Cook wrote:
Is there a simpler way to programatically click "Ok" on a dialog box? (The dialog box coming from code that I don't have source for...)
I'm not sure about that at all, but maybe CBT (Computer-Based Training) hooks are what you want?
Andreas Mohr
Kees Cook wrote:
I'm trying to figure out if there is a way to short-circuit a dialog box. Basically, I want to traps calls to DialogBoxParam, pump calls into lpDialogFunc for dialog init, and then clicking of the "Ok" button, and finally trap calls to EndDialog.
It seems that this is ... hard. :) There is a lot of resource loading, window initialization code, etc that goes on inside DialogBoxParam, and I'd need to handle all of that, I think. There even appears to be issues with 16 vs 32 bit handler addresses, etc. Looks really ugly.
Is there a simpler way to programatically click "Ok" on a dialog box? (The dialog box coming from code that I don't have source for...)
For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using "FindWindow".
I've done such things before. For simple things, this works very well. As soon as things stop being simple, this gets very hairy very fast. Just hope that your case is a simple one.
Shachar
On Tue, May 03, 2005 at 11:56:35AM +0300, Shachar Shemesh wrote:
For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using "FindWindow".
Ah-ha, yes. I ended up using EnumWindows (filtering out the HWND from GetTopWindow). Thanks! WM_COMMAND, IDOK, 0 did the trick.
Now, a final note, is there any way to stop a dialog from displaying itself? (i.e., let dialogs become active, but not draw themselves?) The ttydrv doesn't like trying to open the dialog:
fixme:ttydrv:TTYDRV_GetBitmapBits (0x7d, 0x76d3501c, 128): stub
YOu could trap it#s onshow event but be careful since most dlgs are created as modal , you could end up hanging your process.
On Tue, 03 May 2005 17:23:40 +0200, Kees Cook kees@outflux.net wrote:
On Tue, May 03, 2005 at 11:56:35AM +0300, Shachar Shemesh wrote:
For simple things, merely sending the dialog a WM_COMMAND with the right parameters will do it for you. You can programatically find the dialog using "FindWindow".
Ah-ha, yes. I ended up using EnumWindows (filtering out the HWND from GetTopWindow). Thanks! WM_COMMAND, IDOK, 0 did the trick.
Now, a final note, is there any way to stop a dialog from displaying itself? (i.e., let dialogs become active, but not draw themselves?) The ttydrv doesn't like trying to open the dialog:
fixme:ttydrv:TTYDRV_GetBitmapBits (0x7d, 0x76d3501c, 128): stub
On Tue, May 03, 2005 at 07:38:26PM +0200, wino@piments.com wrote:
YOu could trap it#s onshow event but be careful since most dlgs are created as modal , you could end up hanging your process.
How would I go about capturing that? (Or, how would I hook the event handler?)
It appears you really have very little knowlege of win32 API programming, I'm not sure this is the place for you to start.
Is this a wine problem ? If so in what way.
Maybe you just need to say what you are ultimately trying to achieve and see if someone can suggest a more global solution of volenteer to write a procedure to do it.
HTH
On Tue, 03 May 2005 20:05:18 +0200, Kees Cook kees@outflux.net wrote:
On Tue, May 03, 2005 at 07:38:26PM +0200, wino@piments.com wrote:
YOu could trap it#s onshow event but be careful since most dlgs are created as modal , you could end up hanging your process.
How would I go about capturing that? (Or, how would I hook the event handler?)
On Tue, May 03, 2005 at 08:29:10PM +0200, peter@piments.com wrote:
It appears you really have very little knowlege of win32 API programming, I'm not sure this is the place for you to start.
That's true. I should probably take this off channel.
Is this a wine problem ? If so in what way.
It's not a Wine problem exactly. More of a "make it work with Linux via Wine" issue. I've been developing against the Wine libraries (I don't use Windows natively). The tool I've been writing loads and runs DirectShow DLLs via the IFileSourceFilter APIs: http://outflux.net/software/pkgs/srcfilter/
In the process, I've been writing patches to wine to fully implement some of the calls made by the DLLs I've tried. In an effort to make srcfilter as easy to use as possible, I've been trying to make it as non-interactive as possible, hence my desire to make the dialogs never display, not require X11, etc. I need the dialog to think it's running, though.
-
Andreas Mohr -
Kees Cook -
peter＠piments.com -
Shachar Shemesh -
wino＠piments.com