Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Fw: Scrolling text

 [1/7] from: brett::codeconscious::com at: 7-Jun-2001 19:35


Forwarded because the original bounced back with a message that [rebol-list--rebol--com] service was unavailable.

 [2/7] from: gjones05:mail:orion at: 7-Jun-2001 5:41


From: "Brett Handley"
> The gurus would know this but as for moi ... > Please try the code below.
<<quoted lines omitted: 25>>
> What is my best bet going forwards to > avoid the unwanted field text scroll?
Hi, Brett, I remembered seeing something similar a few months ago, but it was text on a button scrolling!!! The archive url (watch for wrapping) http://www.escribe.com/internet/rebol/index.html?by=OneThread&t=%5BREBOL %5D Odd scrolling behaviour%3F I didn't ever really understand what Allen meant in the final thread post. My intuition suggested that assigning the area an index and updating it would "fix" the problem, and it does (see code below). But this seems to be a buglet. If no one offers any more substantive rationale for the behavior, I would submit it as a possible bug to feedback. view layout [ the-field: field "sample" the-area: area 200x100 {This is some text that just happens to run over multiple lines. If you scroll to the bottom of this text area using the arrow keys you will see the text of this area scrolling up. What was unexpected for me was that the text of the field will also be scrolled up as soon as the face is reshown - which will happen when you click on the button below. Next try scrolling to the top and again hit the button. } button "Show" [show the-area the-field] ] Cheers! --Scott Jones

 [3/7] from: brett:codeconscious at: 7-Jun-2001 21:30


Hi Scott, Thanks for your message. At first I thought you had it! But alas... I've been checking some more and that extra show you put in makes it appear that the problem is fixed but it is not. You can see this by scrolling to the bottom of the area again and then instead of hitting the button click in the field then click on the button. The result is the area is back at the top again. :) So I ended up doing some more digging and I believe it comes down to the fact that the area and the field share the same PARA object which includes a field that records the scroll offset.
>> layout [the-field: field the-area: area] >> same? the-field/para the-area/para
== true So in a new version if I ensure that area has a new para object different to field - there is no problem. view layout [ the-field: field "sample" the-area: area 200x50 {This is some text that just happens to run over multiple lines. If you scroll to the bottom of this text area using the arrow keys you will see the text of this area scrolling up. } button "Show" [show the-field show the-area] do [the-area/para: make the-area/para []] ] I suspect that area should get its own version of a para by default. So I'll send this off to feedback. Thanks for your help! Brett.

 [4/7] from: gjones05:mail:orion at: 7-Jun-2001 7:15


From: "Brett Handley"
> Thanks for your message. At first I thought > you had it! But alas... I've been checking
<<quoted lines omitted: 5>>
> on the button. The result is the area is back > at the top again. :)
Sorry!
> So I ended up doing some more digging and I > believe it comes down to the fact that the area
<<quoted lines omitted: 4>>
> == true > So in a new version if I ensure that area has a new para object
different to
> field - there is no problem. > view layout [
<<quoted lines omitted: 11>>
> I suspect that area should get its own version of a para by default. > So I'll send this off to feedback. Thanks for your help!
Good job! --Scott Jones

 [5/7] from: cyphre:volny:cz at: 7-Jun-2001 14:34


Hello Brett,
> I suspect that area should get its own version of a para by default. >
I've found this kind of behaviour in VID some months ago. This is not only case of area and para. It is a problem of each VID style. It is a problem of cloning objects. So if you want to build independent FACE object you have to MAKE recursive all sub faces/objects. That means you HAVE TO always clone at least font and para subobjects in FACE :(( I really don't like such behaviour of 'make and I've put that in bug-database in Rebol/express few months ago. I think that make should behave recursively when cloning new object or maybe /deep refinement in 'make would be a solution. What about RT? Another example of such behaviour: view layout [ vtext "test" with [font/color: red] vtext "anohter text" ] Regards Cyphre

 [6/7] from: petr:krenzelok:trz:cz at: 7-Jun-2001 15:02


Richard Smolak wrote:
> Hello Brett, > >
<<quoted lines omitted: 9>>
> behave recursively when cloning new object or maybe /deep refinement in > 'make would be a solution. What about RT?
Hi Cyphre, what is more - once you try "print mold" some already used style in layout - you end up in some strange kind of recursion, probably because of some cross-references ... Well, I think RT will not want to change - as many scripts would be affected by such change. Maybe the solution is make/deep? -pekr-

 [7/7] from: agem:crosswinds at: 7-Jun-2001 15:19


Know the problem too. my shortcut for copying is area para [] i think area para [] font [] would copy font to. -Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 07.06.01, 12:30:46, schrieb "Brett Handley" <[brett--codeconscious--com]> zum Thema [REBOL] Re: Fw: Scrolling text:

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted