Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Compact Framework / August 2007

Tip: Looking for answers? Try searching our database.

Handling the back key doesn't work if the form has a LinkLabel (.NET CF)

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
spit.respectable@gmail.com - 31 Jul 2007 19:13 GMT
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,
Trafalgar - 31 Jul 2007 19:46 GMT
Have you tried the KeyDown event?

> 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
[quoted text clipped - 27 lines]
>
> Thanks,
Jason - 31 Jul 2007 23:32 GMT
On Jul 31, 11:46 am, Trafalgar <Trafal...@discussions.microsoft.com>
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,
Hilton - 31 Jul 2007 21:44 GMT
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

> 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
[quoted text clipped - 27 lines]
>
> Thanks,
Jason - 31 Jul 2007 23:38 GMT
> 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.
<ctacke/> - 01 Aug 2007 02:32 GMT
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).

Signature

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

> Unfortunately the Back key does not work in many places such as a
> ListView. I have tried numerous times to contact Microsoft folks about
[quoted text clipped - 42 lines]
>>
>> Thanks,
Hilton - 01 Aug 2007 07:46 GMT
> 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
<ctacke/> - 01 Aug 2007 15:12 GMT
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.

Signature

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

>> Have you tried an actual official channel, like opening a support
>> incident? A newsgroup post is relly not a communication to Microsoft -
[quoted text clipped - 19 lines]
>
> Hilton
Hilton - 12 Aug 2007 07:13 GMT
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

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.