I would like to block input to prevent controls like buttons from being
pressed for a short period of time while a sound is playing.

While my app is doing something like playing a sound synchronously, the user
can press buttons or other controls. These mouse events are queued up and
then my message pump processes them *after* the sound is done playing.

In this scenario, a user can press a button with the stylus but the program
won't act on it until several seconds later (depending on the duration of the
sound). This behavior is unwanted. Rather, it is preferred that such button
presses are ignored, which is preventable by blocking/filtering mouse and
keyboard input.

I have tried a couple of various methods but each one comes with its own
downfall and none have fully solved this problem.

What I would really like is to be able to make a call that tells the OS to
stop sending my application input messages, and then a call to tell the OS to
start sending them again. Any input between the two calls would be blocked
from making it to my application. There appears to be a BlockInput(bool) call
that does just this, but it's not supported in Windows CE as far as I can
tell.

NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key combos.
Just trying to block regular input, and thus preventing control events.

What about disabling the controls while the sound plays?

--
Tim Wilson
..Net Compact Framework MVP

"Tyler Laing" <(E-Mail Removed)> wrote in message
news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> I would like to block input to prevent controls like buttons from being
> pressed for a short period of time while a sound is playing.
>
> While my app is doing something like playing a sound synchronously, the
user
> can press buttons or other controls. These mouse events are queued up and
> then my message pump processes them *after* the sound is done playing.
>
> In this scenario, a user can press a button with the stylus but the
program
> won't act on it until several seconds later (depending on the duration of
the
> sound). This behavior is unwanted. Rather, it is preferred that such
button
> presses are ignored, which is preventable by blocking/filtering mouse and
> keyboard input.
>
> I have tried a couple of various methods but each one comes with its own
> downfall and none have fully solved this problem.
>
> What I would really like is to be able to make a call that tells the OS to
> stop sending my application input messages, and then a call to tell the OS
to
> start sending them again. Any input between the two calls would be blocked
> from making it to my application. There appears to be a BlockInput(bool)
call
> that does just this, but it's not supported in Windows CE as far as I can
> tell.
>
> NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
combos.
> Just trying to block regular input, and thus preventing control events.

Thought of that one, but then the screen gets filled with grayed out controls
and is kind of ugly. Ran that one by the project lead already and he doens't
like it.

I also thought of taking a screen shot, then puting it up over the form so
it looked like the form and all the controls were there but it would just be
a non-interactive image. But that's even uglier (design wise).

I hope the above solutions don't need to be taken and that there are better
alternatives.

Thanks though.



"Tim Wilson" wrote:

> What about disabling the controls while the sound plays?
>
> --
> Tim Wilson
> ..Net Compact Framework MVP
>
> "Tyler Laing" <(E-Mail Removed)> wrote in message
> news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> > I would like to block input to prevent controls like buttons from being
> > pressed for a short period of time while a sound is playing.
> >
> > While my app is doing something like playing a sound synchronously, the
> user
> > can press buttons or other controls. These mouse events are queued up and
> > then my message pump processes them *after* the sound is done playing.
> >
> > In this scenario, a user can press a button with the stylus but the
> program
> > won't act on it until several seconds later (depending on the duration of
> the
> > sound). This behavior is unwanted. Rather, it is preferred that such
> button
> > presses are ignored, which is preventable by blocking/filtering mouse and
> > keyboard input.
> >
> > I have tried a couple of various methods but each one comes with its own
> > downfall and none have fully solved this problem.
> >
> > What I would really like is to be able to make a call that tells the OS to
> > stop sending my application input messages, and then a call to tell the OS
> to
> > start sending them again. Any input between the two calls would be blocked
> > from making it to my application. There appears to be a BlockInput(bool)
> call
> > that does just this, but it's not supported in Windows CE as far as I can
> > tell.
> >
> > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> combos.
> > Just trying to block regular input, and thus preventing control events.
>
>
>

Here is what I have tried along with the problems that came from them.

1) When playing a sound, add a message filter to the main forms message
pump, start a new thread and play the sound in the new thread, when the sound
is done remove the message filter. The message filter removes all mouse and
keyboard events while the sound is playing.

The problem is that the call to play the sound is within a loop that
iterates through some method calls. So although the input is being blocked,
the main form is not being blocked because the sychronous sound is now in a
different thread. Thus the for loop continues and this is undesirable.

2) Add a message filter before playing the sound. Play the sound in the same
thread (main form), when the sound is done send a custom application message
using PostMessage(...). What I was hoping for here was that the message
filter would filter out all the input message up until the custom message is
received.

The problem here is that the OS stores the input messages in the system
message queue and sends them to the thread message queue later (after the
sound is done), thus my custom message is received before any of the input
messages.

3) Same as attempt 2, but before sending the custom message I tried calling
Application.DoEvents() to get the message pump to process the input message
and filter them out.

Problem is code re-entry, for every stylus tap I did during the sound play,
the sound would play again. Application.DoEvents() warns against re-entrant
code which I apparently did.

Thanks in advance

Fair enough. One thing to consider though is that the user might be confused
as to why he/she can tap of buttons that look active and yet nothing
happens. This is the main reason as to why controls gray-out so as to
visually indicate to the user that the control is inaccessible.

--
Tim Wilson
..Net Compact Framework MVP

"Tyler Laing" <(E-Mail Removed)> wrote in message
news:F4FB3B6E-6D1A-4946-9BA3-(E-Mail Removed)...
> Thought of that one, but then the screen gets filled with grayed out
controls
> and is kind of ugly. Ran that one by the project lead already and he
doens't
> like it.
>
> I also thought of taking a screen shot, then puting it up over the form so
> it looked like the form and all the controls were there but it would just
be
> a non-interactive image. But that's even uglier (design wise).
>
> I hope the above solutions don't need to be taken and that there are
better
> alternatives.
>
> Thanks though.
>
>
>
> "Tim Wilson" wrote:
>
> > What about disabling the controls while the sound plays?
> >
> > --
> > Tim Wilson
> > ..Net Compact Framework MVP
> >
> > "Tyler Laing" <(E-Mail Removed)> wrote in message
> > news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> > > I would like to block input to prevent controls like buttons from
being
> > > pressed for a short period of time while a sound is playing.
> > >
> > > While my app is doing something like playing a sound synchronously,
the
> > user
> > > can press buttons or other controls. These mouse events are queued up
and
> > > then my message pump processes them *after* the sound is done playing.
> > >
> > > In this scenario, a user can press a button with the stylus but the
> > program
> > > won't act on it until several seconds later (depending on the duration
of
> > the
> > > sound). This behavior is unwanted. Rather, it is preferred that such
> > button
> > > presses are ignored, which is preventable by blocking/filtering mouse
and
> > > keyboard input.
> > >
> > > I have tried a couple of various methods but each one comes with its
own
> > > downfall and none have fully solved this problem.
> > >
> > > What I would really like is to be able to make a call that tells the
OS to
> > > stop sending my application input messages, and then a call to tell
the OS
> > to
> > > start sending them again. Any input between the two calls would be
blocked
> > > from making it to my application. There appears to be a
BlockInput(bool)
> > call
> > > that does just this, but it's not supported in Windows CE as far as I
can
> > > tell.
> > >
> > > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> > combos.
> > > Just trying to block regular input, and thus preventing control
events.
> >
> >
> >

Why not strip the message queue (ApplicationEx would allow it) after playing
then continue processing as normal after that?

--
<ctacke/>
www.OpenNETCF.org
Your CF searches start and end here


"Tyler Laing" <(E-Mail Removed)> wrote in message
news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
>I would like to block input to prevent controls like buttons from being
> pressed for a short period of time while a sound is playing.
>
> While my app is doing something like playing a sound synchronously, the
> user
> can press buttons or other controls. These mouse events are queued up and
> then my message pump processes them *after* the sound is done playing.
>
> In this scenario, a user can press a button with the stylus but the
> program
> won't act on it until several seconds later (depending on the duration of
> the
> sound). This behavior is unwanted. Rather, it is preferred that such
> button
> presses are ignored, which is preventable by blocking/filtering mouse and
> keyboard input.
>
> I have tried a couple of various methods but each one comes with its own
> downfall and none have fully solved this problem.
>
> What I would really like is to be able to make a call that tells the OS to
> stop sending my application input messages, and then a call to tell the OS
> to
> start sending them again. Any input between the two calls would be blocked
> from making it to my application. There appears to be a BlockInput(bool)
> call
> that does just this, but it's not supported in Windows CE as far as I can
> tell.
>
> NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> combos.
> Just trying to block regular input, and thus preventing control events.

How so? I am using ApplicationEx.

I'm not exactly sure what you mean by "strip the message queue", although I
can take a good guess.

Thanks


"Chris Tacke, eMVP" wrote:

> Why not strip the message queue (ApplicationEx would allow it) after playing
> then continue processing as normal after that?
>
> --
> <ctacke/>
> www.OpenNETCF.org
> Your CF searches start and end here
>
>
> "Tyler Laing" <(E-Mail Removed)> wrote in message
> news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> >I would like to block input to prevent controls like buttons from being
> > pressed for a short period of time while a sound is playing.
> >
> > While my app is doing something like playing a sound synchronously, the
> > user
> > can press buttons or other controls. These mouse events are queued up and
> > then my message pump processes them *after* the sound is done playing.
> >
> > In this scenario, a user can press a button with the stylus but the
> > program
> > won't act on it until several seconds later (depending on the duration of
> > the
> > sound). This behavior is unwanted. Rather, it is preferred that such
> > button
> > presses are ignored, which is preventable by blocking/filtering mouse and
> > keyboard input.
> >
> > I have tried a couple of various methods but each one comes with its own
> > downfall and none have fully solved this problem.
> >
> > What I would really like is to be able to make a call that tells the OS to
> > stop sending my application input messages, and then a call to tell the OS
> > to
> > start sending them again. Any input between the two calls would be blocked
> > from making it to my application. There appears to be a BlockInput(bool)
> > call
> > that does just this, but it's not supported in Windows CE as far as I can
> > tell.
> >
> > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> > combos.
> > Just trying to block regular input, and thus preventing control events.
>
>
>

Fair enough indeed. I ran the "disable the controls" idea by the project lead
and he wasn't too fond of it. However, it is still quite tempting to take
that route. Thanks for you input Tim.


"Tim Wilson" wrote:

> Fair enough. One thing to consider though is that the user might be confused
> as to why he/she can tap of buttons that look active and yet nothing
> happens. This is the main reason as to why controls gray-out so as to
> visually indicate to the user that the control is inaccessible.
>
> --
> Tim Wilson
> ..Net Compact Framework MVP
>
> "Tyler Laing" <(E-Mail Removed)> wrote in message
> news:F4FB3B6E-6D1A-4946-9BA3-(E-Mail Removed)...
> > Thought of that one, but then the screen gets filled with grayed out
> controls
> > and is kind of ugly. Ran that one by the project lead already and he
> doens't
> > like it.
> >
> > I also thought of taking a screen shot, then puting it up over the form so
> > it looked like the form and all the controls were there but it would just
> be
> > a non-interactive image. But that's even uglier (design wise).
> >
> > I hope the above solutions don't need to be taken and that there are
> better
> > alternatives.
> >
> > Thanks though.
> >
> >
> >
> > "Tim Wilson" wrote:
> >
> > > What about disabling the controls while the sound plays?
> > >
> > > --
> > > Tim Wilson
> > > ..Net Compact Framework MVP
> > >
> > > "Tyler Laing" <(E-Mail Removed)> wrote in message
> > > news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> > > > I would like to block input to prevent controls like buttons from
> being
> > > > pressed for a short period of time while a sound is playing.
> > > >
> > > > While my app is doing something like playing a sound synchronously,
> the
> > > user
> > > > can press buttons or other controls. These mouse events are queued up
> and
> > > > then my message pump processes them *after* the sound is done playing.
> > > >
> > > > In this scenario, a user can press a button with the stylus but the
> > > program
> > > > won't act on it until several seconds later (depending on the duration
> of
> > > the
> > > > sound). This behavior is unwanted. Rather, it is preferred that such
> > > button
> > > > presses are ignored, which is preventable by blocking/filtering mouse
> and
> > > > keyboard input.
> > > >
> > > > I have tried a couple of various methods but each one comes with its
> own
> > > > downfall and none have fully solved this problem.
> > > >
> > > > What I would really like is to be able to make a call that tells the
> OS to
> > > > stop sending my application input messages, and then a call to tell
> the OS
> > > to
> > > > start sending them again. Any input between the two calls would be
> blocked
> > > > from making it to my application. There appears to be a
> BlockInput(bool)
> > > call
> > > > that does just this, but it's not supported in Windows CE as far as I
> can
> > > > tell.
> > > >
> > > > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> > > combos.
> > > > Just trying to block regular input, and thus preventing control
> events.
> > >
> > >
> > >
>
>
>

Well all taps, etc are going to get posted to the message queue, so you
simply need to pull them off before continuing. So something like this
pseudocode

MyApp()
{
DoStuff()
PlaySound()
StripQueue()
DoStuff()
}

void StripQueue()
{
while(PeekMessage(out msg, IntPtr.Zero, 0, 0, 0))
GetMessage(out msg, IntPtr.Zero, 0, 0);
}

Of course you might have a conflict for messages with the main pump, so that
might have to be disabled. A far better thing now that I think about it may
to be just run the sound in a separate thread, and in the main thread add an
IMessageFilter implementation that throws out all messages, enable it, play
the sound and disable it.

--
<ctacke/>
www.OpenNETCF.org
Your CF searches start and end here


"Tyler Laing" <(E-Mail Removed)> wrote in message
news:AC1103DC-1F3A-4867-AF98-(E-Mail Removed)...
> How so? I am using ApplicationEx.
>
> I'm not exactly sure what you mean by "strip the message queue", although
> I
> can take a good guess.
>
> Thanks
>
>
> "Chris Tacke, eMVP" wrote:
>
>> Why not strip the message queue (ApplicationEx would allow it) after
>> playing
>> then continue processing as normal after that?
>>
>> --
>> <ctacke/>
>> www.OpenNETCF.org
>> Your CF searches start and end here
>>
>>
>> "Tyler Laing" <(E-Mail Removed)> wrote in message
>> news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
>> >I would like to block input to prevent controls like buttons from being
>> > pressed for a short period of time while a sound is playing.
>> >
>> > While my app is doing something like playing a sound synchronously, the
>> > user
>> > can press buttons or other controls. These mouse events are queued up
>> > and
>> > then my message pump processes them *after* the sound is done playing.
>> >
>> > In this scenario, a user can press a button with the stylus but the
>> > program
>> > won't act on it until several seconds later (depending on the duration
>> > of
>> > the
>> > sound). This behavior is unwanted. Rather, it is preferred that such
>> > button
>> > presses are ignored, which is preventable by blocking/filtering mouse
>> > and
>> > keyboard input.
>> >
>> > I have tried a couple of various methods but each one comes with its
>> > own
>> > downfall and none have fully solved this problem.
>> >
>> > What I would really like is to be able to make a call that tells the OS
>> > to
>> > stop sending my application input messages, and then a call to tell the
>> > OS
>> > to
>> > start sending them again. Any input between the two calls would be
>> > blocked
>> > from making it to my application. There appears to be a
>> > BlockInput(bool)
>> > call
>> > that does just this, but it's not supported in Windows CE as far as I
>> > can
>> > tell.
>> >
>> > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
>> > combos.
>> > Just trying to block regular input, and thus preventing control events.
>>
>>
>>

That would conflict with the main threads messages if any non-input messages
were in the queue. I tried something similar where I called DoEvents()
instead of StripQueue() in your example, and had an IMessageFilter
implementation to remove input, but that caused re-entrant code and the sound
played multiple times.

Your second suggestion I also already tried:

Add IMessageFilter to remove input messages
Start new Thread
Play sound in the new thread
While sound is playing, main thread filters out input messages
When sound is done, remove filter to re-enable input messages

This is the closest working attempt I've got so far. The only problem here
is where the PlaySound call is being done. Its being called inside of a loop
that later does some other stuff after calling PlaySound. If PlaySound is in
the same thread and it's called synchronously then the other stuff if the
loop doesn't happen until after the PlaySound method returns (synchronous
flag set).

If PlaySound is in a seperate thread like above, then everything works
except that the other stuff done by the loop happens right after the sound
starts rather than when the sound ends because the loop is in the main thread.

Due to its design I can't move the loop into the sound thread because that
would cause all sort of other issues.

Possible Solution:

Maybe I can just add a semphore that can be checked within the loop which
calls PlaySound. If it's set, then the loop will jump into an inner loop that
calls DoEvents() until the semphore is released. This will forego the futher
calls within the loop and allow for message filtering.

I'll give it a shot. Thanks for your comments Chris.



"Chris Tacke, eMVP" wrote:

> Well all taps, etc are going to get posted to the message queue, so you
> simply need to pull them off before continuing. So something like this
> pseudocode
>
> MyApp()
> {
> DoStuff()
> PlaySound()
> StripQueue()
> DoStuff()
> }
>
> void StripQueue()
> {
> while(PeekMessage(out msg, IntPtr.Zero, 0, 0, 0))
> GetMessage(out msg, IntPtr.Zero, 0, 0);
> }
>
> Of course you might have a conflict for messages with the main pump, so that
> might have to be disabled. A far better thing now that I think about it may
> to be just run the sound in a separate thread, and in the main thread add an
> IMessageFilter implementation that throws out all messages, enable it, play
> the sound and disable it.
>
> --
> <ctacke/>
> www.OpenNETCF.org
> Your CF searches start and end here
>
>
> "Tyler Laing" <(E-Mail Removed)> wrote in message
> news:AC1103DC-1F3A-4867-AF98-(E-Mail Removed)...
> > How so? I am using ApplicationEx.
> >
> > I'm not exactly sure what you mean by "strip the message queue", although
> > I
> > can take a good guess.
> >
> > Thanks
> >
> >
> > "Chris Tacke, eMVP" wrote:
> >
> >> Why not strip the message queue (ApplicationEx would allow it) after
> >> playing
> >> then continue processing as normal after that?
> >>
> >> --
> >> <ctacke/>
> >> www.OpenNETCF.org
> >> Your CF searches start and end here
> >>
> >>
> >> "Tyler Laing" <(E-Mail Removed)> wrote in message
> >> news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> >> >I would like to block input to prevent controls like buttons from being
> >> > pressed for a short period of time while a sound is playing.
> >> >
> >> > While my app is doing something like playing a sound synchronously, the
> >> > user
> >> > can press buttons or other controls. These mouse events are queued up
> >> > and
> >> > then my message pump processes them *after* the sound is done playing.
> >> >
> >> > In this scenario, a user can press a button with the stylus but the
> >> > program
> >> > won't act on it until several seconds later (depending on the duration
> >> > of
> >> > the
> >> > sound). This behavior is unwanted. Rather, it is preferred that such
> >> > button
> >> > presses are ignored, which is preventable by blocking/filtering mouse
> >> > and
> >> > keyboard input.
> >> >
> >> > I have tried a couple of various methods but each one comes with its
> >> > own
> >> > downfall and none have fully solved this problem.
> >> >
> >> > What I would really like is to be able to make a call that tells the OS
> >> > to
> >> > stop sending my application input messages, and then a call to tell the
> >> > OS
> >> > to
> >> > start sending them again. Any input between the two calls would be
> >> > blocked
> >> > from making it to my application. There appears to be a
> >> > BlockInput(bool)
> >> > call
> >> > that does just this, but it's not supported in Windows CE as far as I
> >> > can
> >> > tell.
> >> >
> >> > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> >> > combos.
> >> > Just trying to block regular input, and thus preventing control events.
> >>
> >>
> >>
>
>
>

"Chris Tacke, eMVP" wrote:

> Well all taps, etc are going to get posted to the message queue, so you
> simply need to pull them off before continuing. So something like this
> pseudocode
>
> MyApp()
> {
> DoStuff()
> PlaySound()
> StripQueue()
> DoStuff()
> }
>
> void StripQueue()
> {
> while(PeekMessage(out msg, IntPtr.Zero, 0, 0, 0))
> GetMessage(out msg, IntPtr.Zero, 0, 0);
> }
>
> Of course you might have a conflict for messages with the main pump, so that
> might have to be disabled. A far better thing now that I think about it may
> to be just run the sound in a separate thread, and in the main thread add an
> IMessageFilter implementation that throws out all messages, enable it, play
> the sound and disable it.
>
> --
> <ctacke/>
> www.OpenNETCF.org
> Your CF searches start and end here
>
>
> "Tyler Laing" <(E-Mail Removed)> wrote in message
> news:AC1103DC-1F3A-4867-AF98-(E-Mail Removed)...
> > How so? I am using ApplicationEx.
> >
> > I'm not exactly sure what you mean by "strip the message queue", although
> > I
> > can take a good guess.
> >
> > Thanks
> >
> >
> > "Chris Tacke, eMVP" wrote:
> >
> >> Why not strip the message queue (ApplicationEx would allow it) after
> >> playing
> >> then continue processing as normal after that?
> >>
> >> --
> >> <ctacke/>
> >> www.OpenNETCF.org
> >> Your CF searches start and end here
> >>
> >>
> >> "Tyler Laing" <(E-Mail Removed)> wrote in message
> >> news:6F04E77E-14E6-4DE9-A17D-(E-Mail Removed)...
> >> >I would like to block input to prevent controls like buttons from being
> >> > pressed for a short period of time while a sound is playing.
> >> >
> >> > While my app is doing something like playing a sound synchronously, the
> >> > user
> >> > can press buttons or other controls. These mouse events are queued up
> >> > and
> >> > then my message pump processes them *after* the sound is done playing.
> >> >
> >> > In this scenario, a user can press a button with the stylus but the
> >> > program
> >> > won't act on it until several seconds later (depending on the duration
> >> > of
> >> > the
> >> > sound). This behavior is unwanted. Rather, it is preferred that such
> >> > button
> >> > presses are ignored, which is preventable by blocking/filtering mouse
> >> > and
> >> > keyboard input.
> >> >
> >> > I have tried a couple of various methods but each one comes with its
> >> > own
> >> > downfall and none have fully solved this problem.
> >> >
> >> > What I would really like is to be able to make a call that tells the OS
> >> > to
> >> > stop sending my application input messages, and then a call to tell the
> >> > OS
> >> > to
> >> > start sending them again. Any input between the two calls would be
> >> > blocked
> >> > from making it to my application. There appears to be a
> >> > BlockInput(bool)
> >> > call
> >> > that does just this, but it's not supported in Windows CE as far as I
> >> > can
> >> > tell.
> >> >
> >> > NOTE: I am NOT trying to block CTRL+ALT+DEL or any other system key
> >> > combos.
> >> > Just trying to block regular input, and thus preventing control events.
> >>
> >>
> >>
>
>
>