Skip Menu |

This queue is for tickets about the Curses-UI CPAN distribution.

Report information
The Basics
Id: 18046
Status: open
Priority: 0/
Queue: Curses-UI

People
Owner: Nobody in particular
Requestors: cpan [...] kevin.lebleu.info
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.95
Fixed in: (no value)



Subject: Need way to cancel focus change
There is no clear way to have a control, during its onBlur event, cancel the focus change and stay in the same control. This feature is commonly available in other UI libraries I have worked with in the past, and very useful for a variety of functions. Using $this->focus does not work, as it keeps focus in the control, but the next control in focus order still gets highlighted like it has focus.
On Tue Mar 07 17:33:02 2006, guest wrote: Show quoted text
> There is no clear way to have a control, during its onBlur event, cancel > the focus change and stay in the same control. This feature is commonly > available in other UI libraries I have worked with in the past, and very > useful for a variety of functions. > > Using $this->focus does not work, as it keeps focus in the control, but > the next control in focus order still gets highlighted like it has focus.
Can you provide an example of when this is useful? I'm thinking that most actions which would result in an onBlur are nearly-instantaneous, so don't see how a user would have the chance to cancel anything, and off the top of my head I can't see why a program would, itself, decide to take an action and then immediately cancel it.
Subject: Re: [rt.cpan.org #18046] Need way to cancel focus change
Date: Sun, 27 Jul 2008 10:04:07 -0500
To: bug-Curses-UI [...] rt.cpan.org
From: "Kevin C." <kevin [...] kevin.lebleu.info>
On Sat, Jul 26, 2008 at 10:10 AM, Shawn Boyette via RT < bug-Curses-UI@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=18046 > > > On Tue Mar 07 17:33:02 2006, guest wrote:
> > There is no clear way to have a control, during its onBlur event, cancel > > the focus change and stay in the same control. This feature is commonly > > available in other UI libraries I have worked with in the past, and very > > useful for a variety of functions. > > > > Using $this->focus does not work, as it keeps focus in the control, but > > the next control in focus order still gets highlighted like it has focus.
> > Can you provide an example of when this is useful? I'm thinking that > most actions which would result in an onBlur are nearly-instantaneous, > so don't see how a user would have the chance to cancel anything, and > off the top of my head I can't see why a program would, itself, decide > to take an action and then immediately cancel it. >
A very common reason to do so is to prevent the user from leaving the field when the data entered is invalid. I believe, if I recall correctly (I'm at home right now, don't have access to the code I was working on), that I was working on an application that worked with barcode scanning, and I needed to keep the cursor in the field if an invalid barcode was scanned. In both those scenarios, the user triggers the action, and the program cancels it. Are those examples sufficient? Thanks, Kevin -- If you're reading this, you're part of the mass hallucination that is Kevin the Blue. Copyright 2008 Kevin the Blue <copy@kevin.lebleu.info> "Software is like fire - it can be freely distributed without lessening the original flame."-konstant <mpriest@microsoft.com>
On Sun Jul 27 11:04:41 2008, kevin@kevin.lebleu.info wrote: Show quoted text
> A very common reason to do so is to prevent the user from leaving the > field > when the data entered is invalid. > > I believe, if I recall correctly (I'm at home right now, don't have > access > to the code I was working on), that I was working on an application > that > worked with barcode scanning, and I needed to keep the cursor in the > field > if an invalid barcode was scanned. > > In both those scenarios, the user triggers the action, and the program > cancels it. > > Are those examples sufficient?
Sure, that's totally fair and valid. I simply hadn't considered the problem of on-the-fly validation.