It's great to see you back, Kirill.
I would really like to see proper keyboard traversal in widgets. (Being
hand-challenged, I sometimes only use the kbd.)
Why can't somebody (Andy or Kirill) implement Lisp functions to traverse to the next
widget in a particular buffer, or to a specified widget? Then we can define
keyboard commands to (a) switch between the last selected widget in a buffer and the
buffer's point; (b) to switch to the next widget; (c) between panes
("windows") in a
frame; and (d) between frames. (We might have to do a bit of work to allow defining
keystrokes in widgets, but probably not much more than passing keyboard events up to
the buffer. The obvious Lisp interface is through the existing glyph extent
keymap.)
We should consult existing Microsoft apps to figure out good bindings.
From Word, I would suggest TAB/Sh-TAB for (b), F6/Sh-F6 for (c), and
Ctrl-F6/Ctrl-Sh-F6 for (d). For (a), either Alt-F6 (undefined in Word), Ctrl-TAB
(and remove the existing binding), or maybe F11 ("go to the next field" in
Word).
Note also, both Front Page and Dev Studio use Ctrl-PgUp/PgDn to select different
tabs, and Dev Studio uses Alt-1/2/3 to select a specific pane. Dev Studio also uses
Ctrl-F6 and Ctrl-TAB interchangeably.
ben
Kirill 'Big K' Katsnelson wrote:
This patch fixes a problem: focus disappears after pressing Done
in a customize buffer, and does not reappear until a click on
a buffer (focus lost: it was on a "Done" button, destroyed).
The rest, I made usage of tab stops consistent. XEmacs currently
does not make use of this flag, but I felt I had to make it
consistent.
The flag WS_EX_CONTROLPARENT applied to parents, not children.
It affects the behavior of GetNextDlgTabItem. Suppose A,B,C are
children of W, and B1, B2 and B3 are children of B. If all of
the windows are tab stops (WS_TABSTOP), GetNextDlgTabItem
will traverse A,B,C if B does not have the WS_EX_CONTROLPARENT
flag, and A,B1,B2,B3,C if it does.
In mswindows_subwindow_instantiate, this flag is not necessary
as long as its child is STATIC.
Andy (I suppose you wrote the code, did you?), why there are
sandwiches of two windows to represent each widget? If there
is a rationale behind this which I overlook, then it has to be
documented - the code looks quite cryptic now... :)
It is customary in Windows to make all controls accessible equally
using mouse and keyboard. Now, should I click on a widget, there
is no way to move focus away from it using keyboard (neither to
sibling widget nor back to the buffer). Symmetrically there is
no way to activate a widget from a buffer using only keyboard.
I have no idea how to make it better (it's midnight here, and I
haven't been xemacsing for a long time), but this should be
discussed.
Big K
2000-01-12 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
* glyphs-msw.c (mswindows_unmap_subwindow): Set focus back to the
frame upon hiding a subwindow.
(mswindows_button_instantiate): Changed the push button style to
BS_PUSHBUTTON.
(mswindows_button_instantiate): Removed button BS_NOTIFY
style.
(mswindows_button_instantiate): Removed redundant check for
a disabled gui item.
(mswindows_button_instantiate): Made use of WS_TABSTOP
consistent: "operable" controls (edit, button, tree, scroll) have
this style, "display-only" ones (static, progress gauge) do
not. This style is currently ignored by XEmacs though. Also,
removed the WS_EX_CONTROLPARENT style - it is not for children,
it is for their parents!
(mswindows_edit_field_instantiate): Ditto.
(mswindows_progress_gauge_instantiate): Ditto.
(mswindows_tree_view_instantiate): Ditto.
(mswindows_tab_control_instantiate): Ditto.
(mswindows_scrollbar_instantiate): Ditto.
(mswindows_combo_box_instantiate): Ditto.
(mswindows_widget_instantiate): Added the WS_EX_CONTROLPARENT
style to the "clip" window.
(mswindows_button_instantiate): Removed compilation warning by
equally typing terms of the ?: operator.
Index: glyphs-msw.c
===================================================================
RCS file: /var/cvsroot/xemacs/src/glyphs-msw.c,v
retrieving revision 1.1.1.1
diff --unified=2 -r1.1.1.1 glyphs-msw.c
--- src/glyphs-msw.c 2000/01/12 07:54:49 1.1.1.1
+++ src/glyphs-msw.c 2000/01/13 07:29:31
@@ -2098,4 +2098,5 @@
SWP_HIDEWINDOW | SWP_NOMOVE | SWP_NOSIZE
| SWP_NOSENDCHANGING);
+ SetFocus (GetParent (IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (p)));
}
}
@@ -2356,5 +2357,5 @@
if ((IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (ii)
= CreateWindowEx(
- 0, /* EX flags */
+ WS_EX_CONTROLPARENT, /* EX flags */
XEMACS_CONTROL_CLASS,
0, /* text */
@@ -2418,5 +2419,7 @@
struct Lisp_Image_Instance *ii = XIMAGE_INSTANCE (image_instance);
HWND wnd;
- int flags = BS_NOTIFY;
+ int flags = WS_TABSTOP;/* BS_NOTIFY #### is needed to get exotic feedback
+ only. Since we seem to want nothing beyond BN_CLICK,
+ the style is perhaps not necessary -- kkm */
Lisp_Object style;
Lisp_Object gui = IMAGE_INSTANCE_WIDGET_ITEM (ii);
@@ -2424,7 +2427,4 @@
Lisp_Object glyph = find_keyword_in_vector (instantiator, Q_image);
- if (!gui_item_active_p (gui))
- flags |= WS_DISABLED;
-
if (!NILP (glyph))
{
@@ -2448,9 +2448,11 @@
}
else
- flags |= BS_DEFPUSHBUTTON;
+ {
+ flags |= BS_PUSHBUTTON;
+ }
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
- pointer_bg, dest_mask, domain, "BUTTON",
flags,
- WS_EX_CONTROLPARENT);
+ pointer_bg, dest_mask, domain, "BUTTON",
+ flags, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
@@ -2466,7 +2468,7 @@
(WPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
IMAGE_BITMAP : IMAGE_ICON),
- (LPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
- XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
- XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
+ (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
}
}
@@ -2481,6 +2483,5 @@
pointer_bg, dest_mask, domain, "EDIT",
ES_LEFT | ES_AUTOHSCROLL | WS_TABSTOP
- | WS_BORDER,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ | WS_BORDER, WS_EX_CLIENTEDGE);
}
@@ -2495,6 +2496,5 @@
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, PROGRESS_CLASS,
- WS_TABSTOP | WS_BORDER | PBS_SMOOTH,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_BORDER | PBS_SMOOTH, WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
/* set the colors */
@@ -2580,5 +2580,5 @@
WS_TABSTOP | WS_BORDER | PBS_SMOOTH
| TVS_HASLINES | TVS_HASBUTTONS,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
@@ -2643,6 +2643,5 @@
pointer_bg, dest_mask, domain, WC_TABCONTROL,
/* borders don't suit tabs so well */
- WS_TABSTOP,
- WS_EX_CONTROLPARENT);
+ WS_TABSTOP, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
@@ -2708,6 +2707,5 @@
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, "SCROLLBAR",
- 0,
- WS_EX_CLIENTEDGE );
+ WS_TABSTOP, WS_EX_CLIENTEDGE);
}
@@ -2740,5 +2738,5 @@
| CBS_AUTOHSCROLL
| CBS_HASSTRINGS | WS_VSCROLL,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
/* reset the height */
widget_text_to_pixel_conversion (domain,
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.