jonasn@ttds.UUCP (Jonas Nygren) (05/26/89)
Two problems I have encountered while implementing my own scrollbars. The first is connected with use of the intervall timer and the second with expected behaviour of the LeaveNotify-event. I have implemented scrollbars using one window for each of the 5 scrollbar parts. For the parts that should act repetitively, eg up-button, I have used the intervaltimer 'setitimer(0,...)' to generate the scroll, while the client loops for events ButtonRelease, LeaveNotify and EnterNotify. This scheme works well most of the time but sometimes the X-server reports 'out of sequence' and the client eventually hangs, the 'out of sequence' perhaps indicates that the signal-interrupt corrupts the event-queue(s). Can anybody help me with an explanation to what is happening and a work around if possible? The page-up and page-down parts are implemented as two windows which change size as part of the scrolling, during page-down scroll the page-up windows grows as much as the page-down window diminishes. If the pointer is not moved it will, as a result of the scroll, leave the page-down window and enter the thumb- or page-up window. My problem is that I never get a LeaveNotify event which I should get, shouldn't I? (what equipment? DEC3100,Ultrix,dxwm,Xlib) Thanx in advance Jonas
dheller@cory.Berkeley.EDU (Dan Heller) (05/27/89)
In article <1205@ttds.UUCP> jonasn@ttds.UUCP (Jonas Nygren) writes: > I have implemented scrollbars using one window for each of the 5 scrollbar > parts. For the parts that should act repetitively, eg up-button, I have > used the intervaltimer 'setitimer(0,...)' to generate the scroll, while > the client loops for events ButtonRelease, LeaveNotify and EnterNotify. As I noted in an easlier posting, you cannot use signals in X applications reliably. You have to be very careful/clever to avoid disaster. Fortunately, you are only using timer events, so the problem is easily solved. In the scrollbars that I have built for my widget set, I have two attributes called wait-time and scroll-time which specify in milliseconds the following time-outs. The wait-time is the timeout between the time the user presses a button on the scrollbar and the time in which continuous scrolling takes place. The second time is the time-out between continuous scrolling events. The way to implement this is to let the button-down event initiate scrolling and have it call XtAddTimeOut( ... continuous_scroll_func, ...) and make sure you pass it the wait_time timeout value. The button up event calls XtRemoveTimeOut() to terminate the continuous scrolls. The function continuous_scroll_func just calls the same thing that is called when you want to scroll. It also has to call XtAddTimeOut again with the continuous scroll timeout value, but it should call the same function (continuous_scroll_func). --------- As I said, I suggested before that X should handle signals, but go the reply that "not all X clients will run on unix". I've been thinking about this and have determined that this argument has nothing to do with the issue. If X (or Xt) can handle "timeouts" (however the OS happens to implement it), then there's no reason it can't handle other signals. If the OS doesn't support those signals, then so what -- the code doesn't compile in and the signal will never be delivered. Since 90% of X clients will probably be on unix systems, then avoiding the issue because 10% of the clients can't deliver unix signals is dodging the issue. There are other windowing systems (nudge nudge wink wink) that handle events in this nature and there will probably be code available in a new X release. Surely this model could be adapted for the general case and adopted into the offical stuff. Of course, some porting may be necessary, but the model can be examined and reverse-engineered if necessary. Dan Heller <island!argv@sun.com>