chris@flood.com (Chris Newton) (02/28/91)
Recently, I ran into a problem using panel text items in XView which prompted the following thoughts. I'm interested in others' ideas on the subject, hence this posting. Panel text items provide a mechanism for intercepting individual keystroke events. The called procedure can return INSERT to direct the panel to insert the character into the text item, or NONE, to direct the panel to ignore the character. This provides a means of validating user input at the keystroke level. It's fine - as far as it goes. Problems surfaced, however, when I needed to *translate* the keystroke event into something else - in my case, coerce lower-case to upper-case. No amount of fiddling with the passed event structure results in a modification of the character actually inserted into the text item. I suspected that the panel code is not re-examining the event structure upon return of the notify procedure. Examination of the panel source should this to be the case. The "action" and "id" fields are extracted from the event structure well before invocation of the notification callback. If the callback returns INSERT, these pre-stored values are used to update the item. The change was trivial - merely re-evaluate the event structure after INSERT is returned and everything works as desired. It seems to me that this approach in the panel code is unnecessarily limiting to applications developers. I don't know if the panel code was written specifically this way, or if its merely an unfortunately side-effect of the implementation. The Panel package does support one case of keystroke translation - the PANEL_MASK_CHAR attribute - but this serves only a severely restricted case (i.e. masking the entry of passwords, etc.) Would it not be more generally useful to allow arbitrary event translation by the notification procedure? Sure, you have to know what you're doing, but I'd argue that anyone attempting this sort of low-level event processing probably does. Any thoughts out there? Anyone from the Sun XView camp care to comment? -Chris -- Chris B. Newton The Flood Group, Inc. Lawndale, Ca. Internet: chris@flood.com (213) 219-1155 UUCP: ...!uunet!flood!chris
fgreco@govt.shearson.COM (Frank Greco) (02/28/91)
> > Problems surfaced, however, when I needed to *translate* the keystroke > event into something else - in my case, coerce lower-case to upper-case. > No amount of fiddling with the passed event structure results in a > modification of the character actually inserted into the text item. I > suspected that the panel code is not re-examining the event structure > upon return of the notify procedure. If you do all your handling in the event proc, it's easy and it works just fine. Just connect the following to your text item's event procedure: --------------------------------------------------------------------- void input_eproc(item, event) /* item's event proc */ Panel_item item; Event *event; { char ch; if ( event_is_up(event) ) return; if ( !isprint(ch = event_action(event)) ) switch(ch) { case '\n': case '\033': case '\r': fprintf(stderr, "You selected [%s]\n", xv_get(item, PANEL_VALUE)); case '\t': return; } else { if ( isalpha(ch) ) event_id(event) = TOUPPER(ch); /* force it upwards */ else { notice_prompt(numstring_window1->window1, NULL, NOTICE_MESSAGE_STRINGS, "You can only input characters", NULL, NOTICE_BUTTON_YES, "Continue", NULL); return; } } panel_default_handle_event(item, event); } --------------------------------------------------------------------- > Would it not be more generally useful to allow arbitrary event translation > by the notification procedure? Sure, you have to know what you're doing, > but I'd argue that anyone attempting this sort of low-level event > processing probably does. That's what XView event procs are for. Frank G.