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