If I understand correctly, the capslock state info is correct
during
regular keypresses, just not when the capslock key is hit.
Yes - in all the tests I tried, the Caps Lock state was always correct during
(and after) regular key presses.
However, any attempt to discern the Caps
On 04/11/13 02:18, MacArthur, Ian (Selex ES, UK) wrote:
If I understand correctly, the capslock state info is correct during
regular keypresses, just not when the capslock key is hit.
Yes - in all the tests I tried, the Caps Lock state was always correct
during (and after) regular
On 11 Apr 2013, at 18:34, Greg Ercolano wrote:
I guess we should see how Win32 and OSX behave, and if they're
reliable
as well, we should either:
1) Document the OS specific behavior, whether different or same,
and leave the code alone
2) Pick one
Try the xkbvled(1) application.
Do you find it too doesn't properly represent the shift lock LED?
It also fails.
I've tried this now with F17 and Ubuntu-12.10, hosted on Win7 and OSX
10.6.8, though in VirtualBox VM's in each case.
I don't have ready access to another brand of
On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote:
It's also rare apps try to do anything with the capslock state.
I don't agree. Most login screens warn immediately if capslock is on
because their password fields don't echo input.
Howard Rubin
On Wed, 10 Apr 2013 10:05:04 -0700, Greg Ercolano e...@seriss.com
wrote:
On 04/10/13 09:25, Howard Rubin wrote:
On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote:
It's also rare apps try to do anything with the capslock state.
I don't agree. Most login screens warn
On 10.04.2013 19:05, Greg Ercolano wrote:
If you wrote the code in pure Xlib, you'd still encounter this problem,
the workaround apparently being to access the LEDs directly I think.
Anyway, not sure if hacking X11's event structure in the case of
capslock
is a
On 10 Apr 2013, at 17:25, Howard Rubin wrote:
I don't agree. Most login screens warn immediately if capslock is on
because their password fields don't echo input.
Though it does appear that, at least if there is any prospect that your users
will be running Linux in a VBox VM, that we may
X11's own KeyRelease events seem to behave similarly;
in my tests with the pure X11 code below, when X11 sends
a KeyRelease event for the capslock key, the event.xkey.state
shows accurate info when capslock is ENABLED, but INACCURATE INFO
when capslock is
I tried the following FLTK code with the above X11 only code
and it seemed to work more reliably.
Not so much for me - though that may be an issue with the VM rather than a
real problem.
I find that, with this code, if I toggle Caps Lock on/off a few times, I can
easily get to a
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote:
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
caps_state = (n 0x01) == 1;
That works perfectly, and even better, needs no timer. Test program below.
Will this be fixed
On 04/09/13 12:18, Howard Rubin wrote:
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote:
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
caps_state = (n 0x01) == 1;
That works perfectly, and even better, needs no timer.
On 04/09/13 12:29, Greg Ercolano wrote:
we could perhaps provide a wrapper to get the
state of the keyboard LEDs (for operating systems that provide this)
e.g. fl_get_indicators() or some such that returns flags.
Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds()
On 9 Apr 2013, at 20:18, Howard Rubin wrote:
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote:
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
caps_state = (n 0x01) == 1;
That works perfectly, and even better, needs no
On 9 Apr 2013, at 22:02, Greg Ercolano wrote:
On 04/09/13 12:29, Greg Ercolano wrote:
we could perhaps provide a wrapper to get the
state of the keyboard LEDs (for operating systems that provide this)
e.g. fl_get_indicators() or some such that returns flags.
Maybe
I tried the following FLTK code with the above X11 only code
and it seemed to work more reliably.
Ian writes:
Not so much for me - though that may be an issue with the VM rather than
a real problem.
I find that, with this code, if I toggle Caps Lock on/off a few times,
I can
On 04/08/13 10:35, Howard Rubin wrote:
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
Howard Rubin schrieb:
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last message?
Yes, it
On 04/05/13 22:58, Edzard Egberts wrote:
It seems, that caps-lock handling starts to work after key handling and
I think there might be other problems, like switching caps lock, when
there is another window in focus. I think a better way is, to use a
timer and to check for change of state
On 04/05/13 08:59, Howard Rubin wrote:
I need to immediately detect when Caps Lock is turned on or off in our
login screen, so I can alert the user. Neither of the approaches I've
tried works.
Do you see the same problem when using the fltk
test/keyboard application?
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Secret_Input.H
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
if (event== FL_SHORTCUT)
{
virtual int handle(int event) {
if (event== FL_SHORTCUT)
if (event== FL_SHORTCUT Fl::event_key()== 65509)
Without check of key every shortcut signals caps lock, thats wrong. And
it seems, the real state establishs after the events had run through,
but because of binary state
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last message?
I'm less than enthusiastic about
On 05.04.2013 22:02, Howard Rubin wrote:
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last
Correction:
On 06.04.2013 02:10, Albrecht Schlosser wrote:
[... about compiling and running program #1]
...
event = FL_KEYDOWN ... caps lock 9
event = FL_KEYUP ... caps lock 10
event = FL_KEYDOWN ... caps lock 11
event = FL_KEYUP ... caps unlock 12
You can see (or guess) that the CAPS LOCK
25 matches
Mail list logo
