[comp.windows.x] Grabbing the AsciiWidget scrollbar. HELP.

roy@neptune.iex.com (Roy Cantu) (07/20/90)

The Text widget allows for optional vertical and   
horizontal scrollbars.  It handles the callbacks
itself without bothering the user about scrollProcs
and jumpProcs.  This is all very nice as long as
the user is satisfied with what these scrollbars 
look like and do.

My application wants to "grab" these scrollbars
so that it may manipulate them while still taking
advantage of the Text widget and without having
to introduce any cumbersome ScrollbarWidgets.
I mean, who wants to write a jump and scroll Proc
when the Text widget already provides it?  
Specifically, my application would like to receive
events whenever the scrollbar is moved and sometimes
(not the majority of the time) set the scrollbar
thumb itself.  I tried to accomplish this with
the following (stripped down) function.

AsciiTextScroll(widget)
AsciiWidget	widget;
{
	Widget	v_bar;

	v_bar = XtNameToWidget(widget, "vScrollbar");
	XawScrollbarSetThumb(v_bar, 0.5, -1.0);
}

This looks good on paper to me, but when I check 
to see if v_bar has a value, it turns out to be
NULL.  Obviously not a good sign.  The inspiration
for the name to widget argument "vScrollbar" comes
from line 380 of Text.c.  I have also tried "vbar"
instead of "vScrollbar", but to no avail.     

Theoretically, if I ever can grab this vertical
scrollbar, I can set my own callback functions
when necessary and set them back to the Text
widget callbacks when I am done.  

Any suggestions or better ways of doing this will
be greatly appreciated.  I hate to keep bugging
people about this, but it is REALLY important.


roy cantu

swick@ATHENA.MIT.EDU (Ralph R. Swick) (07/20/90)

	v_bar = XtNameToWidget(widget, "vScrollbar");

    This looks good on paper to me, but when I check 
    to see if v_bar has a value, it turns out to be
    NULL.

It does look good on paper, doesn't it. :-)  Unfortunately for you,
the Text widget does a very effective job of hiding its internals.
Since it's not a subclass of Composite, XtNameToWidget won't
return any of its component parts.  Your only present option is to
open the box using the big crowbar called TextP.h.

A sanctioned way to use this particular crowbar is to subclass
Text and either export the vbar widget field as a resource (less
preferred), or add a XtNthumbProc callback list resource which
is added to the scrollbar's list internally.

rlh2@ukc.ac.uk (Richard Hesketh) (07/21/90)

In article <roy.648410020@neptune> roy@neptune.iex.com (Roy Cantu) writes:

>AsciiTextScroll(widget)
>AsciiWidget	widget;
>{
>	Widget	v_bar;
>
>	v_bar = XtNameToWidget(widget, "vScrollbar");
>	XawScrollbarSetThumb(v_bar, 0.5, -1.0);
>}

>This looks good on paper to me, but when I check 
>to see if v_bar has a value, it turns out to be
>NULL.  Obviously not a good sign.  The inspiration
>for the name to widget argument "vScrollbar" comes
>from line 380 of Text.c.  I have also tried "vbar"
>instead of "vScrollbar", but to no avail.     

XtNameToWidget() can only search the children of composite parents and
popup shells.  "vScrollbar" is created as an unmanaged child of the Text
widget (which is not a composite parent).  This is perfectly legal as long
as the child is not managed and is explicitly mapped.  However
XtNameToWidget() cannot find it by just searching the child lists of composite
parents.

>Any suggestions or better ways of doing this will
>be greatly appreciated.  I hate to keep bugging
>people about this, but it is REALLY important.

Either there should be additional resources in the TextWidgetClass;
XtNvertScroll & XtNhorizScroll both XtCReadOnly and XtRWidget.  That gives the
programmer access to the widget ids. via GetValues.  Or you need to write your
own routine that picks it straight out of the TextWidgetClasses structure:

#include <X11/IntrinsicP.h>
#include <X11/TextP.h>

Widget
TextScrollbar(tw, vertical)
TextWidget tw;
Boolean vertical;
{
	return (vertical ? tw->text.vbar : tw->text.hbar);
}

>roy cantu

I think that it is probably a good idea for all widget writers to allow
(atleast) read-only access to sub-widget members, for just this sort of
occasion.  We really don't know all the possible uses someone may have for
a widget class so we need to add simple hooks in the classes to allow
unforeseen uses to be developed.

Richard