mitch@well.UUCP (Mitchell Waite) (02/29/88)
In his message Mr. Belsley writes: >> From: <BELSLEY%BCVMS.BITNET@MITVMA.MIT.EDU> (DAVID A. BELSLEY) Subject: Simultaneous scrolling Date: Sat, 20 Feb 88 16:01 EST It should be mentioned that the message posted in this digest several weeks ago regarding simultaneous field scrolling rather misses the point. The statement that was made (I forget the name of the author) was that fields could be made to scroll together merely by a script that says "set the scroll of field A to the scroll of field B", presumably running in a handler for "idle." This solution solves only the simplest and crudest needs of simultaneous scrolling. First, the fields do not really scroll together; they scroll in sequence. The first field moves, then, only after a mouseup, will the second field catch up. If the second field is an index field, this staggered behavior prevents one from knowing how far he has scrolled until it is too late. >> I am sorry Mr. Belsley did not research HyperTalk a little deeper, because we did and found that this problem can be overcome by setting lockscreen to true during the scroll. That way both fields (or all eight if you use that many) will move in sync. This scroll will not be as fast as a pure HyperTalk scroll box scroll, but in some applications, such as ours, which displays a glossary, it is fine. We scroll three lines at a time to make the box seem faster also. >> Second, this solution does not allow for selecting in the field beyond the portion of the field showing in the window. If one attempts to select beyond the scroll, the moment the mouse is let up, the second window "catches us," and, in so doing, removes the selection from the first window. >> I assume the complaint is the field won't scroll when its being edited, and this seems right, but I never said it's contents were editable. Rather we are using it for read only. What Mr. Belsley wants I think could be simulated in HyperTalk with a little creativity in our script. >> Third, the same phenomenon besets the positioning of the insertion point since the insertion point will be "removed" from the first window after contol is given to the second window for its scroll to catch up. >> See above. May be able to work around. If anyone is interested in seeing my dueling scroll fields stack (yes dueling is a play on words) it can be found in DL10 of apphype in Compuserve as the file DUELSC.SIT. If enough people on usenet want to look it over I will be happy to upload to the binaries. Its 30K in StuffIt/binhex format. Mitch
leonardr@uxe.cso.uiuc.edu (03/02/88)
*** BUG IN DUEL SCROLLING STACK ** Here at the University of Illinois we have a group that meets once a week to discuss Hypercard and the Mac in general. At todays meeting we were looking at the Dueling Scroll Stack (mentioned in the previous message) and we discovered A MAJOR FLAW in the stack. If the only way the user moves about the text in the scrolling fields is by the scroll bar then there is no problem HOWEVER if you use the FIND Command, the field containing the found text will automatically scrolled by Hypercard BUT the other field won't! I don't know if there are fix for this problem but thought I would pass it on for anyone else who may be doing something similar. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+