I'm porting a Pocket PC app to SmartPhone.  Certain forms within the
app contain buttons -- these are not supported on SP so I've switch
them to LinkLabels.  They work fine, but the issue is that overriding
the back button does not work on these forms.

For handling the SP back button, my keypress method looks like:

       protected override void OnKeyPress(KeyPressEventArgs e)
       {
           if (e.KeyChar == (char)Keys.Escape)
           {
               e.Handled = true;
               MessageBox.Show("Got back key on SP");
           }
           else
               base.OnKeyPress(e);
       }


This works great, unless I add the following to the form's
InitializeComponent():

       this.Controls.Add( new System.Windows.Forms.LinkLabel() );

Now when I press the SP's back key my 'OnKeyPress' does not fire, and
the app is no longer displayed on the screen (i.e. the default SP back
key behavior).

Has anyone worked around this before?  I did a quick search and didn't
see any obvious hits.

Thanks,

Have you tried the KeyDown event?

"spit.respectable@gmail.com" wrote:


> I'm porting a Pocket PC app to SmartPhone.  Certain forms within the
> app contain buttons -- these are not supported on SP so I've switch
> them to LinkLabels.  They work fine, but the issue is that overriding
> the back button does not work on these forms.
> 
> For handling the SP back button, my keypress method looks like:
> 
>        protected override void OnKeyPress(KeyPressEventArgs e)
>        {
>            if (e.KeyChar == (char)Keys.Escape)
>            {
>                e.Handled = true;
>                MessageBox.Show("Got back key on SP");
>            }
>            else
>                base.OnKeyPress(e);
>        }
> 
> 
> This works great, unless I add the following to the form's
> InitializeComponent():
> 
>        this.Controls.Add( new System.Windows.Forms.LinkLabel() );
> 
> Now when I press the SP's back key my 'OnKeyPress' does not fire, and
> the app is no longer displayed on the screen (i.e. the default SP back
> key behavior).
> 
> Has anyone worked around this before?  I did a quick search and didn't
> see any obvious hits.
> 
> Thanks,
> 
> 

Unfortunately the Back key does not work in many places such as a ListView. 
I have tried numerous times to contact Microsoft folks about this (through 
the NGs and other channels of communication).  Not only do they not even 
acknowledge the problem, they don't even care to suggest a workaround.  Very 
dissapointing from Microsoft.

So, you are correct, don't expect the BackKey to work consistently on the 
Smartphone.  The CF just seems to 'gobble up' the key press and the app 
isn't even notified.

I'm hoping I'm completely wrong and a Microsoft engineer will jump in and 
correct me.  Let's see if I can tempt them...

Hilton


 wrote in message 
news:1185905614.234801.102930@i13g2000prf.googlegroups.com...

> I'm porting a Pocket PC app to SmartPhone.  Certain forms within the
> app contain buttons -- these are not supported on SP so I've switch
> them to LinkLabels.  They work fine, but the issue is that overriding
> the back button does not work on these forms.
>
> For handling the SP back button, my keypress method looks like:
>
>       protected override void OnKeyPress(KeyPressEventArgs e)
>       {
>           if (e.KeyChar == (char)Keys.Escape)
>           {
>               e.Handled = true;
>               MessageBox.Show("Got back key on SP");
>           }
>           else
>               base.OnKeyPress(e);
>       }
>
>
> This works great, unless I add the following to the form's
> InitializeComponent():
>
>       this.Controls.Add( new System.Windows.Forms.LinkLabel() );
>
> Now when I press the SP's back key my 'OnKeyPress' does not fire, and
> the app is no longer displayed on the screen (i.e. the default SP back
> key behavior).
>
> Has anyone worked around this before?  I did a quick search and didn't
> see any obvious hits.
>
> Thanks,
> 

On Jul 31, 11:46 am, Trafalgar 
wrote:

> Have you tried the KeyDown event?


All the documentation I've seen indicates that the SP back key fires
KeyPress
(ex. http://msdn2.microsoft.com/en-us/library/ms172543(VS.80).aspx).

I've tried catching it in KeyDown, but that doesn't fire (whether or
not I have a LinkLabel on the form).

Thanks,

On Jul 31, 1:44 pm, "Hilton"  wrote:

> Unfortunately the Back key does not work in many places such as a ListView.


Thanks for the confirmation.  I was thinking that perhaps the
LinkLabel was gobbling up the back key, but I added an event handler
for it and I'm not seeing it fire for the back key.

Have you tried an actual official channel, like opening a support incident? 
A newsgroup post is relly not a communication to Microsoft - it's a post in 
USENET where some Microsoft people might see it.  It doesn't get tied into 
their bug reporting and tracking system, nor is anyone accountable for 
handling it (unlike a support incident).


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Hilton"  wrote in message 
news:qaNri.1839$Yz6.1041@newssvr22.news.prodigy.net...

> Unfortunately the Back key does not work in many places such as a 
> ListView. I have tried numerous times to contact Microsoft folks about 
> this (through the NGs and other channels of communication).  Not only do 
> they not even acknowledge the problem, they don't even care to suggest a 
> workaround.  Very dissapointing from Microsoft.
>
> So, you are correct, don't expect the BackKey to work consistently on the 
> Smartphone.  The CF just seems to 'gobble up' the key press and the app 
> isn't even notified.
>
> I'm hoping I'm completely wrong and a Microsoft engineer will jump in and 
> correct me.  Let's see if I can tempt them...
>
> Hilton
>
>
>  wrote in message 
> news:1185905614.234801.102930@i13g2000prf.googlegroups.com...
>> I'm porting a Pocket PC app to SmartPhone.  Certain forms within the
>> app contain buttons -- these are not supported on SP so I've switch
>> them to LinkLabels.  They work fine, but the issue is that overriding
>> the back button does not work on these forms.
>>
>> For handling the SP back button, my keypress method looks like:
>>
>>       protected override void OnKeyPress(KeyPressEventArgs e)
>>       {
>>           if (e.KeyChar == (char)Keys.Escape)
>>           {
>>               e.Handled = true;
>>               MessageBox.Show("Got back key on SP");
>>           }
>>           else
>>               base.OnKeyPress(e);
>>       }
>>
>>
>> This works great, unless I add the following to the form's
>> InitializeComponent():
>>
>>       this.Controls.Add( new System.Windows.Forms.LinkLabel() );
>>
>> Now when I press the SP's back key my 'OnKeyPress' does not fire, and
>> the app is no longer displayed on the screen (i.e. the default SP back
>> key behavior).
>>
>> Has anyone worked around this before?  I did a quick search and didn't
>> see any obvious hits.
>>
>> Thanks,
>>
>
> 

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message 
news:O2Hxsv90HHA.1344@TK2MSFTNGP04.phx.gbl...

> Have you tried an actual official channel, like opening a support 
> incident? A newsgroup post is relly not a communication to Microsoft - 
> it's a post in USENET where some Microsoft people might see it.  It 
> doesn't get tied into their bug reporting and tracking system, nor is 
> anyone accountable for handling it (unlike a support incident).


I have posted so many articles here about the Back Key not working (even 
some asking for Microsoft's help in the title), there's just no way an MS 
person could not have seen it (e.g. Ilya).  So, let's assume an MS person 
did it.  For them not to file an 'incident' on it, IMHO, shows a lack of 
<insert one of a million words here>.  So, I stand by my assertion that it 
is a bad reflection on MS.  Heck, no-one even asked specifics about it. 
Sorry, but I've gotta believe someone from Microsoft saw the posts.

OK, so it has taken me about 20 minutes to figure out how to file an 
'incident' through the Microsoft web site and even though I signed on, I now 
need to apply for permission to help them fix their code.  Chris, I love 
what Microsoft has done with .NET and the CF, I think it is phenominal that 
I can write code so quickly and easily that runs on cell phones etc.  But I 
just have to believe that they...  [I stopped myself before saying bad 
things about Microsoft]

Hilton

My point is that posting here, even a thousand times, is not an official 
channel into Microsoft.  There's no magic "turn this newsgroup post into a 
support case" button on their news reader, and very frequently those who 
might read the post aren't the owners of the area where the bug resides (I 
doubt Ilya would own this, and if it came in as a bug, I doubt he'd be the 
one fixing it).

To open a support case is quite simple.  You go to the MS support page.  On 
it are several phone numbers based on where you are and what technology is 
the problem.  You call that number.  I've done it several times and *always* 
have had fast and very good support.  I can't say that the bugs have always 
been fixed or that a workaround was always provided because I've had some 
really oddball stuff in the past that had no business case for resolution 
(like wanting support for RDP client on a 160x240 display).  The have always 
resolved the issue to my satisfaction though (which is in fact the 
requirement to close a case - your satisfaction, not theirs).

Sure, this specific case maybe someone should have seen a post about it and 
done something, but maybe the MS readers didn't personally consider it a big 
deal (for example, I've never been affected by it in all my years of CF 
coding nor has anyone I've worked with) or assumed that someone else closer 
to the fix would act.  The point is that it's not their responsibility or 
job to do so.  I can't imagine trying to open support cases for every "bug" 
reported in the newsgroups and then trying to manage both them and an actual 
job.  If you have a real bug, open a real incident.  It will get a real 
resolution.


-- 

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com


"Hilton"  wrote in message 
news:x%Vri.32672$C96.9360@newssvr23.news.prodigy.net...

> "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message 
> news:O2Hxsv90HHA.1344@TK2MSFTNGP04.phx.gbl...
>> Have you tried an actual official channel, like opening a support 
>> incident? A newsgroup post is relly not a communication to Microsoft - 
>> it's a post in USENET where some Microsoft people might see it.  It 
>> doesn't get tied into their bug reporting and tracking system, nor is 
>> anyone accountable for handling it (unlike a support incident).
>
> I have posted so many articles here about the Back Key not working (even 
> some asking for Microsoft's help in the title), there's just no way an MS 
> person could not have seen it (e.g. Ilya).  So, let's assume an MS person 
> did it.  For them not to file an 'incident' on it, IMHO, shows a lack of 
> <insert one of a million words here>.  So, I stand by my assertion that it 
> is a bad reflection on MS.  Heck, no-one even asked specifics about it. 
> Sorry, but I've gotta believe someone from Microsoft saw the posts.
>
> OK, so it has taken me about 20 minutes to figure out how to file an 
> 'incident' through the Microsoft web site and even though I signed on, I 
> now need to apply for permission to help them fix their code.  Chris, I 
> love what Microsoft has done with .NET and the CF, I think it is 
> phenominal that I can write code so quickly and easily that runs on cell 
> phones etc.  But I just have to believe that they...  [I stopped myself 
> before saying bad things about Microsoft]
>
> Hilton
>
> 

Chris wrote:

> My point is that posting here, even a thousand times, is not an official 
> channel into Microsoft.  There's no magic "turn this newsgroup post into a 
> support case" button on their news reader,

Agreed.


> ...and very frequently those who might read the post aren't the owners of 
> the area where the bug resides (I doubt Ilya would own this, and if it 
> came in as a bug, I doubt he'd be the one fixing it).


He works for Microsoft - right?  When I worked for large companies, I always 
filed or emailed a reported bug; but that's just me.


[zap: how to open support case via the phone]


> Sure, this specific case maybe someone should have seen a post about it 
> and done something, but maybe the MS readers didn't personally consider it 
> a big deal (for example, I've never been affected by it in all my years of 
> CF coding nor has anyone I've worked with) or assumed that someone else 
> closer to the fix would act.


The bug makes code written for the Smartphone unable to adhere to 
Microsoft's UI guidelines, that's a big deal and very frustrating for our 
customers.  The "Back Key" has an accepted/anticipated behavior; how can I 
achieve that?  To me that should get a high priority because this bug will 
affect *EVERY* CF application written for the Smartphone that uses certain 
controls such as a ListView.  That's a big deal.



> The point is that it's not their responsibility or job to do so.  I can't 
> imagine trying to open support cases for every "bug" reported in the 
> newsgroups and then trying to manage both them and an actual job.  If you 
> have a real bug, open a real incident.  It will get a real resolution.


Agreed.  But they don't have to open support cases for every bug, only mine. 
:)  Just kidding.  Seriously though, a bug that breaks Microsoft's own 
usability guidelines, has no workaround and affects an entire platform 
should at least get some attention from Microsoft.  I'm not here to blame 
anyone, I just expected more, I expected an engineer at Microsoft to perhaps 
take 5 minutes our of their day to send a quick email: "Hey Bob, this guy on 
the CF NG is reporting a Back Key bug.  Please take a look." and then a post 
saying: "Thanks, I have referred the bug to the CF team.", OK, maybe only 2 
minutes.

Hilton