[comp.windows.x] XView Panel Text Item thoughts

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.