Sign in to follow this  
Eber Kain

Win32 Question

Recommended Posts

I recently added an option to allow for a windowed mode during the window creation, but I cant seem to figure out how to make the window mobile. So that you can use the mouse to drag the window around the screen. I have looked over all the params for CreateWindowEx() carefully, and I dont see anything there, I even commented out all my mouse processing so the defaultWindowProc() function could take that, still cant move the window around. What else should I look at? Im happy to post any code you think may be relavant.

Share this post


Link to post
Share on other sites
Currently im using these styles.

xs is the dwExstyle
s is the dwstyle

	if(windowMode == FULLSCREEN) {
s = WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN;
xs = WS_EX_APPWINDOW;
}
else {
s = WS_OVERLAPPEDWINDOW | WS_CLIPSIBLINGS | WS_CLIPCHILDREN;
xs = WS_EX_APPWINDOW | WS_EX_WINDOWEDGE;
}

Share this post


Link to post
Share on other sites
Quote:
Original post by jflanglois
Could you be more specific on the problem? How is the window not able to move? Is it that the title bar is not showing up? Or does the mouse not do anything when you drag?


jfl.



The window has a title bar and buttons, there is no cursor when the mouse is over the window, which has not been an issue since I have always just rendered the cursor. My WNDCLASS object is this.

	wc.cbClsExtra =		0;
wc.cbWndExtra = 0;
wc.hbrBackground = NULL;
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hIcon = LoadIcon(NULL, IDI_WINLOGO);
wc.hInstance = hin;
wc.lpfnWndProc = WindowProc;
wc.lpszClassName = WINDOW_INSTANCE_NAME;
wc.lpszMenuName = NULL;
wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgramMax
What does the message handler look like? You may not be calling the default window proc and so the messages that you don't handle are never handled.



LRESULT CALLBACK WindowProc(HWND p_hwn,UINT p_msg,WPARAM p_wparam,LPARAM p_lparam) {
return GameClient->ProcessIO(&p_hwn, &p_msg, &p_wparam, &p_lparam);
}

LRESULT CALLBACK cGameClient::ProcessIO(HWND* p_hwn,UINT* p_msg,WPARAM* p_wparam,LPARAM* p_lparam) {
switch(*p_msg) {
case WM_ACTIVATE:
if(!HIWORD(*p_wparam))
active = true;
else
active = false;
return 0;

case WM_SYSCOMMAND:
switch (*p_wparam)
{
case SC_SCREENSAVE:
case SC_MONITORPOWER:
return 0;
}
return 0;

case WM_KEYDOWN:
keys[*p_wparam] = true;
Keyboard((unsigned short)*p_wparam);
return 0;
case WM_KEYUP:
keys[*p_wparam] = false;
return 0;

case WM_QUIT:
case WM_CLOSE:
running = false;
return 0;
}
return DefWindowProc(*p_hwn, *p_msg, *p_wparam, *p_lparam);
}

Share this post


Link to post
Share on other sites
Quote:
Original post by jflanglois
My guess is, from the info at hand:
Change IDirectInputDevice8::SetCooperativeLevel to DISCL_BACKGROUND | DISCL_NONEXCLUSIVE

[edit] Is cGameClient::ProcessIO a static member function?



jfl.


Im not using Directinput, nor do I have any DirectX SDK.

[edit] no. If I make it static i got a ton of errors.

Share this post


Link to post
Share on other sites
Well there is at least one problem...your window proc is always calling default.

It should be like this:

switch( blah )
{
case BLAH:
// return a value...
break;

case FOO:
// return a value...
break;

default:
return DefaultWindowProc( );
}


And if you really want to be cool: A lot of people think that functions should have one entry point and one exit point. So you could do:

LRESULT blah;

switch( )
{
case FOO:
blah = something; // what I would normally have returned

default:
blah = DefaultWindowProc( );
}

return blah;

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgramMax
Well there is at least one problem...your window proc is always calling default.

It should be like this:

switch( blah )
{
case BLAH:
// return a value...
break;

case FOO:
// return a value...
break;

default:
return DefaultWindowProc( );
}


And if you really want to be cool: A lot of people think that functions should have one entry point and one exit point. So you could do:

LRESULT blah;

switch( )
{
case FOO:
blah = something; // what I would normally have returned

default:
blah = DefaultWindowProc( );
}

return blah;


I can step through the code with the debugger and I can tell that is is not calling the default window proc every pass. Whats the point in a return; followed by a break;? For the hell of it, I put the default function under the default case, but that still does not help fix my problem.

Share this post


Link to post
Share on other sites
ProgramMax is partly right.
The big problem is your WM_SYSCOMMAND case.

You can change it to:
case WM_SYSCOMMAND:
switch (*p_wparam)
{
case SC_SCREENSAVE:
case SC_MONITORPOWER:
return 0;
}
return DefWindowProc(*p_hwn, *p_msg, *p_wparam, *p_lparam);

and it should work. [edit] As an explanation, when you effectively intercept the WM_SYSCOMMAND message, you do not handle all the system commands apart from SC_SCREENSAVE and SC_MONITORPOWER, such as SC_MOVE. You need to pass those to DefWindowProc. [edit2] Improved the code slighly.


jfl.

[Edited by - jflanglois on November 4, 2005 5:15:40 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by jflanglois
ProgramMax is partly right.
The big problem is your WM_SYSCOMMAND case.

You can change it to:
case WM_SYSCOMMAND:
switch (*p_wparam) {
case SC_SCREENSAVE:
case SC_MONITORPOWER:
return 0;
default:
DefWindowProc(*p_hwn, *p_msg, *p_wparam, *p_lparam);
}
return 0;

and it should work. [edit] As an explanation, when you effectively intercept the WM_SYSCOMMAND message, you do not handle all the system commands apart from SC_SCREENSAVE and SC_MONITORPOWER, such as SC_MOVE. You need to pass those too DefWindowProc, thusly the default: section


jfl.


Excellent, that fixed it. Thanks a ton.

Share this post


Link to post
Share on other sites
You aren't supposed to call Defaultblah( ) every time. You only call it when you didn't handle the message yourself.

That's why I put it in the default case. Your most recent post puts it in the default case...but that is inside a specific case of a seperate switch.

You need the outter-most switch to have the default.

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgramMax
You aren't supposed to call Defaultblah( ) every time. You only call it when you didn't handle the message yourself.

That's why I put it in the default case. Your most recent post puts it in the default case...but that is inside a specific case of a seperate switch.

You need the outter-most switch to have the default.


Well, the structure of his message handler effectively does the same thing. He moved return 0 to the inside of the switch.

switch( msg ) {
case WM_CLOSE:
PostQuitMessage( 0 );
break;

default:
return DefWindowProc( hwnd, msg, wp, lp );
}
return 0;
Is functionally the same as:
switch( msg ) {
case WM_CLOSE:
PostQuitMessage( 0 );
return 0;
}
return DefWindowProc( hwnd, msg, wp, lp );


I tend to use breaks as well. But his way is also valid.

The reason I moved DefWindowProc outside of the WM_SYSCOMMAND case is because I am not certain whether it will perform additional work on SC_SCREENSAVE and SC_MONITORPOWER. I may be wrong there.


jfl.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this