Re: short-circuting a dialog box?

2005-05-04 Thread peter
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 [EMAIL PROTECTED] wrote:
On Tue, May 03, 2005 at 07:38:26PM +0200, [EMAIL PROTECTED] 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?)

--
Using Opera e-mail on Gentoo Linux


short-circuting a dialog box?

2005-05-03 Thread Kees Cook
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...)

-- 
Kees Cook@outflux.net



Re: short-circuting a dialog box?

2005-05-03 Thread Andreas Mohr
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



Re: short-circuting a dialog box?

2005-05-03 Thread Shachar Shemesh
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
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html



Re: short-circuting a dialog box?

2005-05-03 Thread Kees Cook
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

-- 
Kees Cook@outflux.net



Re: short-circuting a dialog box?

2005-05-03 Thread wino
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 [EMAIL PROTECTED] 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




Re: short-circuting a dialog box?

2005-05-03 Thread Kees Cook
On Tue, May 03, 2005 at 07:38:26PM +0200, [EMAIL PROTECTED] 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?)

-- 
Kees Cook@outflux.net



Re: short-circuting a dialog box?

2005-05-03 Thread Kees Cook
On Tue, May 03, 2005 at 08:29:10PM +0200, [EMAIL PROTECTED] 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.

-- 
Kees Cook@outflux.net