harling@pictel.uucp (Dan Harling) (06/21/91)
I am using the TEXTSW package to display a large array. Rather than
print the entire array (which could be several Meg) at once, I print
only one screenful of the array at a time. Along with the scrollbar
which comes with the TEXTSW package, I create a horizontal scrollbar,
so that the view can be manipulated along both axes.
I have written a SCROLLBAR_COMPUTE_SCROLL_PROC function, which gets
called whenever either scrollbar is pressed. This function computes
the new display origin, reprints the sub-array starting with the new
coordinates, and reproportions the scrollbar (e.g., elevator
position).
Everything is working properly, except for the vertical scrollbar. The
display is updated properly, but the elevator on the vertical scrollbar
never moves; it always stays at the top of the cable, and the entire
cable is highlighted. This is the same position as it would take if it
were a normal TEXTSW scrollbar, since the window contains only one
screenful of text.
I know that my proportioning code is correct, because the horizontal
scrollbar moves as expected. I suspect that the text window still has
a handle to the vertical scrollbar, and is reproportioning it
automatically, but I have been unable to eliminate this. If I destroy
the original scrollbar and try to create a new one, no vertical
scrollbar appears at all.
I have talked to Sun about this, and all they have been able to suggest
(so far) is that I not use the TEXTSW package, or perhaps look for some
useful X calls. If you have any suggestions, or if you are
encountering similar problems yourself, please drop me a line.
______________________________________________________________________
Daniel A. Harling (uunet!pictel!harling) PictureTel, Inc.
Rockport, MA Peabody, MA
Opinions expressed herein are not necessarily those of
PictureTel, Inc.; they are MINE, ALL MINE! (So there.)
---- === ====jcb@NCD.COM (Jim Becker) (06/22/91)
harling@pictel.uucp (Dan Harling) writes:
I am using the TEXTSW package to display a large array. Rather than
print the entire array (which could be several Meg) at once, I print
only one screenful of the array at a time. Along with the scrollbar
which comes with the TEXTSW package, I create a horizontal scrollbar,
so that the view can be manipulated along both axes.
Everything is working properly, except for the vertical scrollbar. The
display is updated properly, but the elevator on the vertical scrollbar
never moves; it always stays at the top of the cable, and the entire
cable is highlighted. This is the same position as it would take if it
were a normal TEXTSW scrollbar, since the window contains only one
screenful of text.
I know that my proportioning code is correct, because the horizontal
scrollbar moves as expected. I suspect that the text window still has
a handle to the vertical scrollbar, and is reproportioning it
automatically, but I have been unable to eliminate this. If I destroy
the original scrollbar and try to create a new one, no vertical
scrollbar appears at all.
the vertical scrollbar is _owned_ by the TEXTSW object, and you
shouldn't be trying to set it. you can't subvert it, as it knows how
many lines are in the TEXTSW content and sets the scrollbar to reflect
this. it's not under your domain to change.
I have talked to Sun about this, and all they have been able to suggest
(so far) is that I not use the TEXTSW package, or perhaps look for some
useful X calls. If you have any suggestions, or if you are
encountering similar problems yourself, please drop me a line.
sounds like you want to use a CANVAS, and do your own attached
scrollbars to it. the TEXTSW object is composite, with the text area
and the scrollbar, so you have to either use the entire thing or
nothing.
-Jim
--
--
-Jim Becker / jcb@ncd.com / Network Computing Devices, Inc. (NCD)fgreco@fis1026.govt.shearson.com (Frank Greco) (06/24/91)
> I am using the TEXTSW package to display a large array. Rather than > print the entire array (which could be several Meg) at once, I print > only one screenful of the array at a time. Along with the scrollbar > which comes with the TEXTSW package, I create a horizontal scrollbar, > so that the view can be manipulated along both axes. While the TEXTSW allows one to display a horizontal scrollbar, it has no function as the TEXTSW *CANNOT* scroll horizontally. You're going to have to use a CANVAS to get complete scrollability. Frank G.
harling@pictel.uucp (Dan Harling) (06/25/91)
In article <jcb.677539093@lupine> jcb@NCD.COM (Jim Becker) writes: >harling@pictel.uucp (Dan Harling) writes: > I know that my proportioning code is correct, because the horizontal > scrollbar moves as expected. I suspect that the text window still has > a handle to the vertical scrollbar, and is reproportioning it > automatically, but I have been unable to eliminate this. If I destroy > the original scrollbar and try to create a new one, no vertical > scrollbar appears at all. > >the vertical scrollbar is _owned_ by the TEXTSW object, and you >shouldn't be trying to set it. you can't subvert it, as it knows how >many lines are in the TEXTSW content and sets the scrollbar to reflect >this. it's not under your domain to change. I realize that the TEXTSW vertical scrollbar is not intended to be changed. However, in order to have the scrollbar do something other than the default functions, I must either redefine some of its characteristics, or replace it with another scrollbar. Redefining the scrollbar has been quite successful: it does everything it is supposed to do (determine the new origin and redraw the display) except move the elevator. Similar code for the horizontal scrollbar, which I created separately, works properly. Replacing it with a new one has failed miserably; either no scrollbar appears, or the default one covers over the new one, making it inaccessible. I am quite familiar with the obstacles involved in what I am attempting. The XView manual even bails out when it comes to doing anything custom with scrollbars. It should not be this difficult, but the documentation is sadly lacking. In short, I have already heard all the reasons why I *shouldn't* do this; so far, nobody has shown me that it *can't* be done (e.g., that the code which automatically sets the scrollbar properties according to the window contents, overriding my values, cannot be overridden). >sounds like you want to use a CANVAS, and do your own attached >scrollbars to it. Unfortunately, there are three reasons I decided not to use the CANVAS package, if I can avoid it: 1) The display routines already exist in another module, and are written for text windows. I would either have to duplicate the code for canvas (maintenance nightmare), or rewrite the other module to use a one-scrollbar canvas instead of a text window! 2) There could be a large number of these active at one time. The text-based display function is barely fast enough as it is; any further slowdown would be unacceptable. 3) It just doesn't make sense to have to use what is essentially a graphical medium to display pure text. If this is indeed necessary, then I would contend that there is a design problem here: an internal (inaccessible) dependence between packages. >-Jim ______________________________________________________________________ Daniel A. Harling uunet!pictel!harling PictureTel, Inc. Rockport, MA Peabody, MA Opinions expressed herein are not necessarily those of PictureTel, Inc.; they are MINE, ALL MINE! (So there.) ---- === ====
harling@pictel.uucp (Dan Harling) (06/25/91)
For those of you who are interested, I have succeeded in using two
scrollbars on a text subwindow for displaying an array subrange,
despite discouragement from official and unofficial channels.
Problem Description:
-The display function prints one screenful of data to the text
subwindow, starting with the current origin coordinates.
-Clicking on the vertical scrollbar changes the Y origin and calls
the display function with the new coordinates.
-Clicking on the horizontal scrollbar changes the X origin and calls
the display function with the new coordinates.
Unfortunately, the vertical scrollbar that comes as part of the
TEXTSW package seems to be internally dependent on the text display, so
that the elevator proportions depend on the window contents rather than
on my code.
Solution:
After creating the window (array_frame) and text subwindow (array_text),
Scrollbar horiz_scroll,
vert_scroll,
old_scroll; /* existing vertical scrollbar */
Xv_window view;
Rect *rect;
/*
* View 0 owns the vertical scrollbar. Find it and hide it.
*/
view = (Xv_window)xv_get(array_text, OPENWIN_NTH_VIEW, 0);
old_scroll = (Scrollbar)xv_get(view, WIN_VERTICAL_SCROLLBAR);
xv_set(old_scroll, XV_SHOW, FALSE, NULL);
/*
* Get scrollbar rectangle. The location and dimensions
* will be used to position the new scrollbar in the same place.
*/
rect = (Rect *)xv_get(old_scroll, XV_RECT);
/*
* Create a new vertical scrollbar, owned by the text pane,
* using location and size of old_scroll. The handle is stored
* in the frame for later access.
*/
vert_scroll = (Scrollbar)xv_create(array_text, SCROLLBAR,
SCROLLBAR_DIRECTION, SCROLLBAR_VERTICAL,
SCROLLBAR_COMPUTE_SCROLL_PROC, array_compute_scroll,
XV_X, rect->r_left, XV_Y, rect->r_top,
XV_WIDTH, rect->r_width, XV_HEIGHT, rect->r_height,
NULL);
xv_set(array_frame, XV_KEY_DATA, VERT_SCROLL_KEY, vert_scroll, NULL);
/*
* Create a horizontal scrollbar, owned by the text pane.
* the handle is stored in the frame for later access.
*/
horiz_scroll = (Scrollbar)xv_create(array_text, SCROLLBAR,
SCROLLBAR_DIRECTION, SCROLLBAR_HORIZONTAL,
SCROLLBAR_COMPUTE_SCROLL_PROC, array_compute_scroll,
XV_SHOW, TRUE, NULL);
xv_set(array_frame, XV_KEY_DATA, HORIZ_SCROLL_KEY, horiz_scroll, NULL);
Summary:
The vertical scrollbar that was created with the text subwindow is
located and made invisible. Its coordinates are used to create a new
vertical scrollbar in the same position. A horizontal scrollbar is
also created. The scrollbars call a SCROLLBAR_COMPUTE_SCROLL_PROC
(array_compute_scroll) that determines which scrollbar was pressed,
determines the new origin coordinates, and prints a new subrange of the
array.
Conclusion:
The XView toolkit makes many things easy to do; however, there have
been a number of things (such as this problem) which apparently go
beyond the anticipation of the designers, and require quite a lot of
effort to accomplish. This is, of course, in keeping with the "90-10"
rule for when using toolkits:
A good toolkit allows you to do 90% of your work in 10% of the
time; it will also require you to use the remaining 90% of your
time to bypass "features" in order to accomplish the remaining
10% of your work.
______________________________________________________________________
Daniel A. Harling uunet!pictel!harling PictureTel, Inc.
Rockport, MA Peabody, MA
Opinions expressed herein are not necessarily those of
PictureTel, Inc.; they are MINE, ALL MINE! (So there.)
---- === ====