[Last modified: Mar 95]

Answer: (Be sure to read the update after the first answer. This is also a
second update which cautions against the approach.)

There is no direct way. This was posted by Edmond Pitt (ejp@bohra.cpg.oz) The
correct answer to the question is to put the following in a modifyVerify
callback, where 'mvcb' is the XmTextVerifyCallbackStruct, and 'overstriking'
is defined by you:

if (overstriking && mvcb->text->length == 1)
{
_XmTextDisableRedisplay(w,FALSE);
XtCallActionProc(w,"delete-next-character",mvcb->event,0);
_XmTextEnableRedisplay(w);
}

_XmText{Dis,En}ableRedisplay() are XmText{Dis,En}ableRedisplay() in 1.0, but
X11R3 has no XtCallActionProc() anyway. For this environment you need my 1.0.3
Text widget patches posted last year & available on request.

An update was provided by Ingeborg (inca@osf.org):

In 1.2 and later releases, there is an action function toggle-overstrike()
which will toggle between overstrike and insert mode. Before 1.2.3, there is
no visual difference, and at most one character will get overstruck. In 1.2.3,
a block cursor was added as a visual cue to that the widget is in overstrike
mode, and the code was fixed to overstrike the actual number of characters
input (this makes a difference if you have preediting - for example in
japanese).

There is no default binding in 1.2, but the recommended key is osfInsert
without modifiers.  No resource exists.


Ed Kaltenbach (kaltenba@ataway.aptec.com) wrote:

I was simulating overstrike mode in the Text Field widget by using
the delete_next_character solution listed in subject 71.
When the software is compiled with Motif 1.2.2, the modifyVerify
callback does not get called for the last character when XmNmaxLength
is specified.  It seems that the check if maxLength has been reached
is done before the modifyVerify gets called and it keeps the modifyVerify
from being called.  Is this a Motif bug? Does anybody have a solution that
will work with Versions 1.1 and 1.2 of Motif?


Phil Day <phil@cfmu.eurocontrol.be> responded to Ed (and apologized for only
sending pseudocode!):

I've had the same problem, and for my money it's a bug.  My workaround is to
make all text widgets (I don't use textfield because of some other problems in
the past) have XmNmaxLength > XmNcolumns, so that the modifyVerify callback
gets a chance to do its stuff.

If you only want to support overstrike for typing, 1 extra charater is enough,
but if you want to support cut-and-paste for any length string you need
maxLength = 2*columns.  In the modifyVerify you have to check the result is <
columns.

I've tried using the Motif 1.2 support for overstrike, but this just seems to
work on a kind of pending-delete and only works for the single charater
replacement caes (that's my main argument for calling it a bug).

I don't use delete-next-character (I can't remember why just now, but I know I
had some problem with it).  Instead I have something like the following:

modifyVerify()
{
if (acceptable)
        XmReplaceText(...)

cd->doit = False;
// we've just done it, we don't wnat Motif to !

XtVaSetValues (w,
           XmNverifyBell, False,
           NULL);
// Otherwise we'll get a beep.
}

valueChanged()
{

XtVaSetValues (w,
           XmNverifyBell, True,
           NULL);
// turned off in modifyVerify

}

Glenn Mandelkern <gmandel@Corp.Megatest.Com> writes about a problem with the
above solution.


We have been running our software on Sparc 20's, under Motif 1.1
and Motif 1.2, X11R5, Solaris 2.4.
Unfortunately, some colleagues and I have found a disturbing side effect
when following this suggestion.  Calling XtVaSetValues() in the
modifyVerifyCallback causes the Text widget to flash.

The O'Reilly guides say not to call XtVaSetValues() during text
modification callbacks.  Motif Volume 6 has this on page 511 and
Motif Volume 6A has it on page 496.

I myself thought it would be fairly trivial to just switch the bell
on and off.  But since XtVaSetValues() calls XmText's set_values() method,
my guess is that its set_values() does something that causes this.

So when you enter characters, the Text widget flashes.  It also slows
down the performance of the Text widget.  You'll see this on a multi-line
Text widget, especially with it occupying a full screen with text.

If you want to see this, take the editor.c program in Volume 6 or 6A,
then add a modifyVerifyCallback to the text_output widget.  Then inside
that callback, call XtVaSetValues with the XmNverifyBell like above.

This is a common "mistake", one which I've done more than once.
I remember also that when I did not have the XtVaSetValues() in place,
I got the beeps.

So now we've reworked the application as follows:
1.  The Text widget is initially created with XmNverifyBell
    set to False.

2.  We ring the bell using XBell() when we detect a condition
    for which we want to veto text modifications.

For our application, this provides the wanted feedback and gets rid
of the flashes.