gamedevlists-windows

RE: [GD-Windows] Dialog doesn't move

[Andrew G. <ag...@cl...>]

> The documentation for IsDialogMessage() claims that a message should not
> be further processed (translate/dispatch) if IsDialogMessage() returns
TRUE.

Just to be clear, I'm pretty sure you need to ignore all non-zero return
values not just those that return TRUE. E.g.

while (dlg->Running() && GetMessage(&msg,NULL,0,0))
{
	if (!IsDialogMessage(dlg->Handle(), &msg))
	{
		TranslateMessage(&msg);
     		DispatchMessage(&msg);
	}
}

Make sure it's the dialog handle you're passing in,not your main window.
Obvious I know, but that sort of thing has bitten me before.

My understanding is that the only use of IsDialogMessage() is to handle
keyboard navigation between items so you should be safe to omit this call
altogether if you don't need that functionality.

And finally, as always make sure you're pumping the message queue from the
correct thread, in this case the one that called CreateDialog.

A.


> -----Original Message-----
> From: gam...@li...
[mailto:gamedevlists-
> win...@li...] On Behalf Of Jon Watte
> Sent: Friday, April 28, 2006 12:17 AM
> To: gam...@li...
> Subject: [GD-Windows] Dialog doesn't move
> 
> I'm creating a dialog using CreateDialog() and running it as a modeless
> dialog.
> 
> The documentation for IsDialogMessage() claims that a message should not
> be further processed (translate/dispatch) if IsDialogMessage() returns
TRUE.
> 
> However, I have found that the dialog will lock up if you click in the
> title bar of it, unless you actually let some kinds of messages through
> to translate/dispatch even though IsDialogMessage() returns TRUE:
> 
>                case WM_NCLBUTTONDOWN:
>                case WM_NCMOUSEMOVE:
>                case WM_NCLBUTTONUP:
>                case WM_LBUTTONUP:
>                case WM_MOUSEMOVE:
> 
> This doesn't appear to be documented behavior, but seems to work OK.
> Does anyone know if this is the appropriate thing to do? Are there other
> messages I should let through to translate/dispatch as well?
> 
> (My dialog proc returns FALSE for pretty much everything except
> WM_COMMAND, WM_INITDIALOG and WM_DESTROY).
> 
> Cheers,
> 
> 			/ h+
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

Re: [GD-Windows] Dialog doesn't move

[Jon W. <hp...@mi...>]

Andrew Grant wrote:

> Just to be clear, I'm pretty sure you need to ignore all non-zero return
> values not just those that return TRUE. E.g.
 > while (dlg->Running() && GetMessage(&msg,NULL,0,0))
 >   if (!IsDialogMessage(dlg->Handle(), &msg))

Yes, that's what I did. That made the dialog seize up when clicking the 
title bar to move it, or clicking the close button. NOT ignoring the 
messages I listed made it work OK.

> My understanding is that the only use of IsDialogMessage() is to handle
> keyboard navigation between items so you should be safe to omit this call
> altogether if you don't need that functionality.

I do need it.

 > Make sure it's the dialog handle you're passing in,not your main
 > window.

I'm pretty sure -- see below.

Now, there is a little bit more to the story. I'm calling IsDialogEvent 
from inside a GetMessage WindowsHook, and if it (IsDialogEvent) returns 
true, I change the message to WM_NULL/0/0. The reason is that I'm 
actually hosted as a DLL inside another application. I've already 
recovered my HMODULE, the HMODULE of the host, and the HWND of the main 
window, so that's all good. I also know the thread is the same, because 
I only hook GetCurrentThreadId() in the SetWindowsHookEx() call.

So: with this set-up, I have to explicitly not ignore about six events 
(related to NC mouse actions), or the dialog siezes up. Such behavior 
isn't documented anywhere. Given that I don't have source for the host 
application, it's been more annoying to debug than I would have hoped.

Any more insights to this situation? ("You shouldn't want to do that" 
came to me, as well, but wouldn't help the current situation :-)

Cheers,

			/ h+

Re: [GD-Windows] Dialog doesn't move

[Martin S. <ms...@he...>]

> Now, there is a little bit more to the story. I'm calling IsDialogEvent 
> from inside a GetMessage WindowsHook, and if it (IsDialogEvent) returns 
> true, I change the message to WM_NULL/0/0. The reason is that I'm 
> actually hosted as a DLL inside another application. I've already 
> recovered my HMODULE, the HMODULE of the host, and the HWND of the main 
> window, so that's all good. I also know the thread is the same, because 
> I only hook GetCurrentThreadId() in the SetWindowsHookEx() call.

If your in a window hook don't you want to let the original window 
handler get a look in with something like

         return CallWindowProc(m_oldWindowProc, hwnd, message, wParam, 
lParam);

not sure if this applies to your situation or not but may help;)

cheers

Martin


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.1/327 - Release Date: 28/04/2006

Re: [GD-Windows] Dialog doesn't move

[brian s. <bri...@gm...>]

On 29 Apr 2006, at 07:04, Martin Slater wrote:

>> Now, there is a little bit more to the story. I'm calling  
>> IsDialogEvent from inside a GetMessage WindowsHook, and if it  
>> (IsDialogEvent) returns true, I change the message to WM_NULL/0/0.  
>> The reason is that I'm actually hosted as a DLL inside another  
>> application. I've already recovered my HMODULE, the HMODULE of the  
>> host, and the HWND of the main window, so that's all good. I also  
>> know the thread is the same, because I only hook GetCurrentThreadId 
>> () in the SetWindowsHookEx() call.
>
> If your in a window hook don't you want to let the original window  
> handler get a look in with something like
>
>         return CallWindowProc(m_oldWindowProc, hwnd, message,  
> wParam, lParam);
>
> not sure if this applies to your situation or not but may help;)
>

You're thinking of what one does when subclassing windows - hook  
procedures are another beast entirely.  Jon needs to call  
CallNextHookEx but if he doesn't the only thing that will break will  
be other hooks.

Only thing that springs to my mind for Jon's problem is that a  
GetMessage hook doesn't catch all the messages sent to an app.   
Anything sent via PostMessage goes into the message queue, but  
anything sent via SendMessage goes straight to the WndProc.  I have  
no idea if this is related to the problem, but it *is* a difference  
between a quote-unquote "standard" app and what Jon is trying to do.

--brian
____________________________________________________

brian sharon | bri...@gm... | http://projecthellion.co.uk

Re: [GD-Windows] Dialog doesn't move

[Jon W. <hp...@mi...>]

Martin Slater wrote:

> If your in a window hook don't you want to let the original window 
> handler get a look in with something like
> 
>         return CallWindowProc(m_oldWindowProc, hwnd, message, wParam, 
> lParam);
> 
> not sure if this applies to your situation or not but may help;)

It applies, although I already do it. Because I use SetWindowsHookEx(), 
I don't get the old hook directly; instead I get a handle that I call 
through CallNextHookEx(), but it's the same idea. (The nice thing about 
Ex is that you can un-install yourself safely)

So, no, that wasn't the problem, either. But thanks!

Cheers,

			/ h+