gamedevlists-windows

[GD-Windows] Troubles with Win32 slider

[Pierre T. <p.t...@wa...>]

I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

RE: [GD-Windows] Troubles with Win32 slider

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

The slider will send you WM_SCROLL messages. Actually, working=20
with sliders in Win32, I've found to be a pain in the butt,=20
because they're so different from many other controls.

Here's code from a wrapper I wrote for personal use a long time=20
ago:

  virtual int value()
    {
      return SendMessage( controlWindow_->window()->hWnd(), TBM_GETPOS, =
0, 0 );
    }
  virtual void setValue( int v )
    {
      LRESULT lr =3D SendMessage( controlWindow_->window()->hWnd(), =
TBM_SETPOS, TRUE, v );
    }

Cheers,

                / h+

-----Original Message-----
From: gam...@li... =
[mailto:gam...@li...]On Behalf Of =
Pierre Terdiman
Sent: Tuesday, May 27, 2003 2:46 PM
To: gam...@li...
Subject: [GD-Windows] Troubles with Win32 slider


I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

Re: [GD-Windows] Troubles with Win32 slider

[Pierre T. <p.t...@wa...>]

>Here's code from a wrapper I wrote for personal use a long time 

Thanks, it worked.

Mailing lists, great invention :)

Pierre

[GD-Windows] Input thread

[Pierre T. <p.t...@wa...>]

Hi,

Here's an old question of mine I never really solved (since it was for some
home project I never find enough time to work on :
www.codercorner.com/Oni.htm)

The question is about keyboard input management, on Windows. The trouble is
when you rely on multiple keys beeing pressed in a sequence, to do a combo
(like in a fighting game).

Currently I use GetAsyncKeyState() and do my own little analysis to detect
combos. It works well as long as framerate is ok, since I only query
keyboard values on-the-fly, each frame.

As soon as framerate drops, it happens that some combos are missed, and
overall controls appear a bit laggy & not responding wery well.

I read somewhere an old MSDN article from 1996 (that I can't seem to find
again) that advocated the use of a separate thread (actually a multimedia
timer, as in timeSetEvent) to read keyboard values at a fixed rate.

It sounds like a good idea indeed, but I never bothered implementing it,
since it also sounds a bit overkill. So before I give it a try, my 2
questions are :

- is this a standard thing to do ?
- is this still relevant nowadays, or is there a better alternative ? (in
particular, using multimedia timers might be an obsolete thing, superseded
by DirectInput maybe. But I'd like to avoid D.I. since otherwise I never
needed it in this particular project).


- Pierre

RE: [GD-Windows] Input thread

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

> - is this a standard thing to do ?

It works awright. I've not actually needed it, though; we're using=20
Windows key events and they work very well (and give you sequencing!)

Note that multimedia timers (and threads, in general) may only be=20
as accurate as your hardware devices on Windows 98, which may mean=20
20 milliseconds jitter. Sampling the keyboard 100 times a second=20
would be plenty...

Cheers,

				/ h+

Re: [GD-Windows] Input thread

[<cas...@ya...>]

I haven't tried that myself either, but Thatcher has some code snipplets and
some notes about that:

http://www.tulrich.com/geekstuff/



Ignacio Castaño
cas...@ya...


Pierre Terdiman wrote:
> Hi,
>
> Here's an old question of mine I never really solved (since it was for
some
> home project I never find enough time to work on :
> www.codercorner.com/Oni.htm)
>
> The question is about keyboard input management, on Windows. The trouble
is
> when you rely on multiple keys beeing pressed in a sequence, to do a combo
> (like in a fighting game).
>
> Currently I use GetAsyncKeyState() and do my own little analysis to detect
> combos. It works well as long as framerate is ok, since I only query
> keyboard values on-the-fly, each frame.
>
> As soon as framerate drops, it happens that some combos are missed, and
> overall controls appear a bit laggy & not responding wery well.
>
> I read somewhere an old MSDN article from 1996 (that I can't seem to find
> again) that advocated the use of a separate thread (actually a multimedia
> timer, as in timeSetEvent) to read keyboard values at a fixed rate.
>
> It sounds like a good idea indeed, but I never bothered implementing it,
> since it also sounds a bit overkill. So before I give it a try, my 2
> questions are :
>
> - is this a standard thing to do ?
> - is this still relevant nowadays, or is there a better alternative ? (in
> particular, using multimedia timers might be an obsolete thing, superseded
> by DirectInput maybe. But I'd like to avoid D.I. since otherwise I never
> needed it in this particular project).

Re: [GD-Windows] Input thread

[Pierre T. <p.t...@wa...>]

> I haven't tried that myself either, but Thatcher has some code snipplets
and
> some notes about that:
>
> http://www.tulrich.com/geekstuff/

Thanks, looks exactly like what I wanted....

Re: [GD-Windows] Input thread

[Javier A. <ja...@py...>]

Pierre Terdiman wrote:
>> I haven't tried that myself either, but Thatcher has some code
>> snipplets and some notes about that:
>>
>> http://www.tulrich.com/geekstuff/
>
> Thanks, looks exactly like what I wanted....

Is there any reason why you'd rather write a multithreaded keyboard system
rather than using windows messages or buffered DirectInput?

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] Input thread

[Pierre T. <p.t...@wa...>]

> Is there any reason why you'd rather write a multithreaded keyboard system
> rather than using windows messages or buffered DirectInput?

Honestly, I don't know. It's been a long time now, but one year ago (or
maybe two) I was using Windows messages in that part of the code, and IIRC I
ran into some problems of lost messages. Typically, the "key up" event
sometimes was never caught, so for example :
- on key down, I was sending a message to a state machine, that eventually
made the character walk
- key up event was missed
- the character kept walking forever

That's why I switched to GetAsyncKeyState() in the first place : no
messages, just read key status when needed, no problem (at least, no
immediate problem).

Now, if you all say Windows messages are just fine and can't ever be missed,
I probably will try it again. It's very possible the bug was somewhere else
(as you see, I'm not exactly working hard on this project since it's already
years-old). Usually I don't have to deal with game input code (not exactly
needed in my job), that's why I also wanted to avoid DirectInput.

Anyway, you pretty much all answered my question : no, what I had in mind
isn't a standard thing to do. I suppose Thatcher went that way because it's
not a Windows guy, to begin with. Answering your question, that would be "a
reason". Maybe the only one.

- Pierre

Re: [GD-Windows] Input thread

[Gabor <ts...@co...>]

Windows messages can be lost if your window lose the focus. You should
handle the WM_ACTIVATE message: if your window lose the focus you should
stop every activity in your program (so in your example send a stop event to
the character)
A program is losing focus for example if you are using Alt+Tab to switch
between tasks.

Hope this helps,
  Gabor

> Honestly, I don't know. It's been a long time now, but one year ago (or
> maybe two) I was using Windows messages in that part of the code, and IIRC
I
> ran into some problems of lost messages. Typically, the "key up" event
> sometimes was never caught, so for example :
> - on key down, I was sending a message to a state machine, that eventually
> made the character walk
> - key up event was missed
> - the character kept walking forever

Re: [GD-Windows] Input thread

[Pierre T. <p.t...@wa...>]

> Windows messages can be lost if your window lose the focus. You should
> handle the WM_ACTIVATE message: if your window lose the focus you should
> stop every activity in your program (so in your example send a stop event
to
> the character)
> A program is losing focus for example if you are using Alt+Tab to switch
> between tasks.

Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
mandatory with GetAsyncKeyState ...

Pierre

Re: [GD-Windows] Input thread

[Gabor <ts...@co...>]

It's okay. In this case key messages have to work perfectly. Another
solution can be that you use DirectInput in which you can create such a
keybuffer which receives messages even if your application is in the
background. I am sure you will prefer the first solution ;)

Gabor

> Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
> mandatory with GetAsyncKeyState ...

Re: [GD-Windows] Input thread

[Pierre T. <p.t...@wa...>]

Ok, I just rewrote it using vanilla Windows messages and it seems to work
well indeed.

I think I found my former bug :

- The GetAsyncKeyState() version is testing mouse buttons as well.
- To get back to Windows messages, I first record inputs in the event proc
(keys, mouse messages like WM_LBUTTONDOWN, etc).
- Then when the character / scene gets updated, I fire all recorded events
at the state machine and let it do its job.

When I did that, it mostly worked but some combos were a lot more difficult
to make. Which is probably why I discarded Win events at first.

But Win events had nothing wrong, I just forgot to -also- record
double-click messages (WM_LBUTTONDBLCLK, etc) as if they were normal clicks.
Which makes the difference when a particular combo requires rapid
clicking...


Anyway, short story : it seems to work with standard Win events so far,
which is the easiest solution I could have wanted, so everything's fine.
[Until next bug pops up]

Thanks for the help.

- Pierre

Re: [GD-Windows] Input thread

[Javier A. <ja...@py...>]

Pierre Terdiman wrote:

>> Windows messages can be lost if your window lose the focus. You
>> should handle the WM_ACTIVATE message: if your window lose the focus
>> you should stop every activity in your program (so in your example
>> send a stop event to the character)
>
> Well, I already handle WM_SETFOCUS & WM_KILLFOCUS. That's pretty much
> mandatory with GetAsyncKeyState ...

If you use windows messages for mouse stuff, it's also a good idea to
capture the mouse when you receive a mouse down. In a full screen app the
mouse is always over the window, but if you support windowed mode (you do,
right? Debugging), you could receive a BUTTONDOWN but not the corresponding
BUTTONUP because the mouse has moved outside the window (the window is still
in focus). Also remember that SetCapture() and ReleaseCapture() are not
refcounted, so multiple simultaneous button presses need special care.

Another more hackish option is, right after processing all pending windows
messages, scan the input (mouse & keyboard) to update for any potentially
lost or mishandled messages.

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Input thread

[Ivan-Assen I. <as...@ha...>]

> If you use windows messages for mouse stuff, it's also a good 
> idea to capture the mouse when you receive a mouse down. In a 
> full screen app the mouse is always over the window, but if 
> you support windowed mode (you do, right? Debugging), you 
> could receive a BUTTONDOWN but not the corresponding BUTTONUP 
> because the mouse has moved outside the window (the window is 
> still in focus). Also remember that SetCapture() and 
> ReleaseCapture() are not refcounted, so multiple simultaneous 
> button presses need special care.

Also remember that in multimon configuration your application might
have stretched itself to the entire primary screen, but still the mouse
can be able to escape to other monitors... we had such a problem
with Celtic Kings. (Sadly, this didn't convince management to
install a second monitor on every programmer's desk :-)

I also second the DirectInput suggestion. If you want to access the
keyboard as an assortment of buttons (vs. a text-input device), 
the DirectInput API is very straightforward.

regards,
Assen

[GD-Windows] WM_SYSCOMMAND documentation question

[Daniel V. <vo...@ep...>]

The D3D sample applications return 1 in response to WM_SYSCOMMAND to prevent
certain events from interfering with the app being fullscreen though I can't
find any documention why 1 is returned. The MSDN docs state that 0 should be
returned if the application handles WM_SYSCOMMAND so I'm wondering where the
return value of 1 is documented.

case WM_SYSCOMMAND:
	// Prevent moving/sizing and power loss in fullscreen mode
	switch( wParam )
	{
		case SC_MOVE:
		case SC_SIZE:
		case SC_MAXIMIZE:
		case SC_KEYMENU:
		case SC_MONITORPOWER:
			if( false == m_bWindowed )
				return 1;
			break;
	}
	break;


Thanks,

-- Daniel, Epic Games Inc.

Re: [GD-Windows] WM_SYSCOMMAND documentation question

[brian s. <pud...@po...>]

My take would be: they're not actually handling the message (hence a 
non-zero return) and they don't want it to go to DefWindowProc (hence 
the immediate return).  Where the 1 comes from, I have no idea.  But if 
they returned 0, it would be read by the OS as "I've handled the 
message, you are now clear to turn off the monitor power/size the 
window" and they probably don't want to deal with those messages in a 
simple sample app.  They'd rather just eat them up and ignore them.

You, as a creator of a real application, probably *should* deal with 
those messages properly and return 0.

--brian

On Monday, June 9, 2003, at 08:22  AM, Daniel Vogel wrote:

> The D3D sample applications return 1 in response to WM_SYSCOMMAND to 
> prevent
> certain events from interfering with the app being fullscreen though I 
> can't
> find any documention why 1 is returned. The MSDN docs state that 0 
> should be
> returned if the application handles WM_SYSCOMMAND so I'm wondering 
> where the
> return value of 1 is documented.
>
> case WM_SYSCOMMAND:
> 	// Prevent moving/sizing and power loss in fullscreen mode
> 	switch( wParam )
> 	{
> 		case SC_MOVE:
> 		case SC_SIZE:
> 		case SC_MAXIMIZE:
> 		case SC_KEYMENU:
> 		case SC_MONITORPOWER:
> 			if( false == m_bWindowed )
> 				return 1;
> 			break;
> 	}
> 	break;
>
>
> Thanks,
>
> -- Daniel, Epic Games Inc.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The 
> best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>