swick@ATHENA.MIT.EDU (Ralph R. Swick) (04/10/90)
> Registering actions for FocusIn and FocusOut doesn't appear to work The ancestors of the text canvas instance need to be managing focus in a way that causes these events to be generated for the descendant. Either XSetInputFocus or XtSetKeyboardFocus should do the trick. > xprop claims that the resulting > client application "does not accept the focus") when the widget is > subclassed from core. Sounds like the old XtNinput False error. The particular class of a widget deep down in the tree shouldn't affect how the input hint is set. > If we subclass it from the Paned widget, it works! What works? Focus events start appearing (maybe you have a special parent class that looks at the class of its child), or the input hint has a different value (hard to believe)? > When subclassing a new widget, what steps must be taken to insure > that it is "input accepting" and will receive focus in/out events? This is one of those areas where the widget set designer(s) have been left a little freedom. So a proper and complete answer can only be given if you tell us what widget set you're using. The convention recommended by the Xt spec is that composite widgets use XtCallAcceptFocus to see if the child wants the focus. This is dynamic. Any widget which selects for FocusChange events should be getting them, but someone higher up in the tree has to do something to cause them to be generated. > ... make > the awl widget a subclass of topLevelShellWidgetClass in the first place, ... > top = XtAppCreateShell("awl", "Awl", awlWidgetClass, dpy, ...); Nothing wrong with this at all. If you don't subclass from ApplicationShell then you'll have to decide who is responsible for creating the WM_COMMAND property on one of your shells. If you do subclass from ApplicationShell, you'll have to decide if it's appropriate that all the windows have this property set. XtAppCreateShell will work with either variety; it doesn't require ApplicationShells. > was I better off subclassing it to core and letting people > always create their own shell? With what you've said so far, I don't see any significant flaw in being a Shell. Forge on! -Ralph.