Iterated check box anomaly
[1/14] from: geza67:freestart:hu at: 12-Apr-2002 19:37
Hello REBOLers!
I have a question upon a strange behavior of an iterated check box.
The list contains a checkbox and an explanatory text per row.
Here is the code snippet:
a: copy []
q: [
["1" "Setup"]
["2" "Install"]
["3" "Post-install"]
["4" "Run"]
]
view layout [
below
list 550x180 [
across origin 2x2
answer: check [
probe a: either probe answer/data [
sort unique append a answer/text
][
sort difference a compose [(answer/text)]
]
show answer
]
question: info wrap 500
] supply [
if count > length? q [face/show?: false exit]
face/show?: true
face/text: q/:count/:index
]
]
If I, e.g. select the first answer, then the check box redraws appropriately;
thereafter if I select the second answer too, the check box remains in "false" state
after the first click - only the second mouse click toggles it's state to "true".
Probing the state of the checkbox and the list of answers reveals that
the first click on the check box does not toggle it's state IF the previous
selection (on another check box) resulted in the same state.
I.e. YES-YES or NO-NO answers on two different checkboxes do not toggle
the state of the second one, only alternating selections (YES-NO).
Despite the visual fault, the action code executes properly and updates the answer block:
true
["1"]
false
["1" "2"]
true
["1" "2"]
This is strange: the checkboxes appear to behave as if they were ONE,
if they were the SAME face visually but the branching upon their
individual logical state executes normally and fills the answer block
appropriately.
Is there a way to overcome this in an iterated list or should I accept
that sometimes two clicks are needed to toggle the "visual" state of a checkbox?
Thanx for your ideas
Geza
[2/14] from: rotenca:telvia:it at: 12-Apr-2002 22:11
Hi, Geza
you must re-initialize the check data field:
a: copy []
q: [
["1" "Setup"]
["2" "Install"]
["3" "Post-install"]
["4" "Run"]
]
view layout [
below
list 550x180 [
across origin 2x2
answer: check [
a: either answer/data [
sort unique append a answer/text
][
sort difference a compose [(answer/text)]
]
show answer
]
question: info wrap 500
] supply [
if count > length? q [face/show?: false exit]
face/show?: true
face/text: q/:count/:index
if index = 1 [face/data: find a face/text]
]
]
---
Ciao
Romano
[3/14] from: geza67:freestart:hu at: 13-Apr-2002 1:01
Hello Romano,
> you must re-initialize the check data field:
> if index = 1 [face/data: find a face/text]
Hmmm, tricky ;-) Thank you very much, it is a great idea!
BTW What is the exact timing of the 'supply function, i.e. on what
occasion (event) will it be launched? As far as I can see, it is
called not only at initialization time (filling the list with items)
but even when I click in the list?
First I tried toggles instead of check boxes, but selecting one of
them caused to redraw all toggles below the selected one in selected
state :-( Is there a way - via some kind of reinitialization - to use
toggles properly in an iterated list?
Again, View docs are euphemically sparse on a quite difficult topic,
like face iteration.
--
Best regards,
Geza mailto:[geza67--freestart--hu]
[4/14] from: rebol:optushome:au at: 13-Apr-2002 9:25
Hi Geza,
List & supply is just a VID interface to face iteration in View. ("supply"
is akin to a "pane func" with a little less effort needed)
If you would like to dig further in iterated faces, the following Zine
article may help.
Look ma, just one face
http://www.rebolforces.com/zine/rzine-1-04.html#sect4.
Cheers,
Allen K
[5/14] from: rotenca:telvia:it at: 13-Apr-2002 15:03
Hi, Geza
> BTW What is the exact timing of the 'supply function, i.e. on what
> occasion (event) will it be launched? As far as I can see, it is
> called not only at initialization time (filling the list with items)
> but even when I click in the list?
There is not an exact timing. It is called when view need it, for example when
you move the mouse over the list, or you click on the list, or some call show
...
It is not called always from top to down, can be called random for a single
count line
You can check it by yourself:
view layout [
l: list [
across
text no-wrap "try1"
text no-wrap "try2"
] supply [
Print [count index]
face
]
]
Instead, index (not count) are always called from 1 to end in the sequence in
which they appear in l/subface/pane
from what you can see in the list/pane function:
>> probe get in l 'pane
func [face id /local count spane][
if pair? id [return 1 + second id / subface/size]
subface/offset: subface/old-offset: id - 1 * subface/size * 0x1
if subface/offset/y + subface/size/y > size/y [return none]
count: 0
foreach item subface/pane [
if object? item [
subfunc item id count: count + 1
]
]
subface
]
> First I tried toggles instead of check boxes, but selecting one of
> them caused to redraw all toggles below the selected one in selected
> state :-( Is there a way - via some kind of reinitialization - to use
> toggles properly in an iterated list?
Should be the same, never tryed, but you must think that, when supply is
called, all the changed field are in an unknown state: you must reinitialize
every field which can be changed by previous supply call.
There are few limits to the list style, sometime it is only a little hard to
figure what is happening.
> Again, View docs are euphemically sparse on a quite difficult topic,
> like face iteration.
They are a great 0. The only way to follow is "disassembling and try" like in
the old good times.
---
Ciao
Romano
[6/14] from: geza67::freestart::hu at: 13-Apr-2002 18:42
Hello Romano,
>> First I tried toggles instead of check boxes, but selecting one of
>> them caused to redraw all toggles below the selected one in selected
> Should be the same, never tryed, but you must think that, when supply is
> called, all the changed field are in an unknown state: you must reinitialize
OK, thank you again, I will try it by your way! :-)
--
Best regards,
Geza mailto:[geza67--freestart--hu]
[7/14] from: geza67::freestart::hu at: 30-Apr-2002 22:18
Iterated check box anomaly (resend)
Hello REBOLers!
I have a question upon the strange behavior of an iterated check box.
The list contains a checkbox and an explanatory text per row.
Here is the code snippet:
a: copy []
q: [
["1" "Setup"]
["2" "Install"]
["3" "Post-install"]
["4" "Run"]
]
view layout [
below
list 550x180 [
across origin 2x2
answer: check [
probe a: either probe answer/data [
sort unique append a answer/text
][
sort difference a compose [(answer/text)]
]
show answer
]
question: info wrap 500
] supply [
if count > length? q [face/show?: false exit]
face/show?: true
face/text: q/:count/:index
]
]
If I, e.g. select the first answer, then the check box redraws appropriately;
thereafter if I select the second answer too, the check box remains in "false"
state
after the first click - only the second mouse click toggles it's state to "true".
Probing the state of the checkbox and the list of answers reveals that
the first click on the check box does not toggle it's state IF the previous
selection (on another check box) resulted in the same state.
I.e. YES-YES or NO-NO answers on two different checkboxes do not toggle
the state of the second one, only alternating selections (YES-NO).
Despite the visual fault, the action code executes properly and updates the
answer block:
true
["1"]
false
["1" "2"]
true
["1" "2"]
This is strange: the checkboxes appear to behave as if they were ONE,
if they were the SAME face visually but the branching upon their
individual logical state executes normally and fills the answer block
appropriately.
Is there a way to overcome this in an iterated list or should I accept
that sometimes two clicks are needed to toggle the "visual" state of a checkbox?
Thanx for your ideas
Geza
[8/14] from: brett:codeconscious at: 1-May-2002 10:45
Hi,
> This is strange: the checkboxes appear to behave as if they were ONE,
> if they were the SAME face visually but the branching upon their
> individual logical state executes normally and fills the answer block
> appropriately.
Yes, they are one.
Visually they appear to be many, technically there is one that is
moved/altered for the various visual positions. It is a bit like
CRT Monitor scan lines vs the whole picture.
> Is there a way to overcome this in an iterated list or should I accept
> that sometimes two clicks are needed to toggle the "visual" state of a
checkbox?
Have a read of "Iterated Fields?? (an iterator intro and iter-field
howto(-fakeit))"
http://www.rebolforces.com/zine/rzine-1-03.html#sect5.
The comment in that Zine article is "...not all styles can be iterated.
Fields, for instance, cannot be iterated, and this is a problem for
somebody wanting to make a list of entry fields."
Checkbox is an example of a style that cannot be iterated properly.
However, the article demonstrates a way of faking the result.
Also relevant is "Look ma, just one face!":
http://www.rebolforces.com/zine/rzine-1-04.html#sect4.
Regards,
Brett.
[9/14] from: anton:lexicon at: 2-May-2002 1:51
Don't listen to that negative stuff.
Here seems to be a solution. Tell me if it works.
Thanks for asking, by the way. Months could have
gone by and I would never have figured it out.
Anton.
a: copy []
q: [
["1" "Setup"]
["2" "Install"]
["3" "Post-install"]
["4" "Run"]
]
chk-dat: array/initial length? q false
view layout [
below
list 550x180 [
across origin 2x2
answer: check with [my-count: none][
print ["face/my-count:" face/my-count]
change at chk-dat face/my-count not pick chk-dat face/my-count
answer/data: pick chk-dat face/my-count
probe a: either probe answer/data [
sort unique append a answer/text
][
sort difference a compose [(answer/text)]
]
show answer
]
question: info wrap 500
] supply [
if count > length? q [face/show?: false exit]
face/show?: true
if face/style = 'check [
face/my-count: count
;face/data: q/:count/:index
]
face/text: q/:count/:index
]
]
[10/14] from: brett:codeconscious at: 2-May-2002 10:41
Hi Anton,
> Don't listen to that negative stuff.
> Here seems to be a solution. Tell me if it works.
> Thanks for asking, by the way. Months could have
> gone by and I would never have figured it out.
Well done. But for your next trick can you make the multiple
highlighting disappear off the info field? :^)
Regards,
Brett.
[11/14] from: anton:lexicon at: 2-May-2002 21:28
Yes, but this will take some time for preparation... :)
I actually wanted to try that next. I am getting my
head into lists, iterated or not.
Anton.
[12/14] from: geza67::freestart::hu at: 5-May-2002 21:48
Re: Iterated check box anomaly (resend) - now, the ROTARY!
Hello Anton,
> Don't listen to that negative stuff.
> Here seems to be a solution. Tell me if it works.
Thank you, it really works! But ... :-)) Now I am stuck with a more
complex structure, namely the rotary.
I tried several initialization strategies, some of them even did not
let to "rotate" the rotary, i.e. it stayed the same.
The model below characterizes best my wishes: I store the state (the
'index? of 'data list) of the rotary in a global context list, where
the n-th cell will be set to 'index? In the scenario n is the row
count of the list, thus the 'count word of the 'supply function.
rebol[]
c: ["1" "2" "3" "4"]
l: ["first" "second" "third" "fourth"]
view layout [
list 600x400 [
across
cnt: info "1"
answer: rotary 240 [
poke a to-integer cnt/text index? answer/data
] data copy head l
] supply [
if count > length? l [face/show?: false exit]
face/show?: true
switch index [
1 [
face/text: pick c count
]
2 [
face/text: probe pick l a/:count
]
]
]
do [a: [1 1 1 1]]
]
Unfortunately, the code - the intention, to set the
variables in the action block of the rotary and restore their state in
the supply function, is not working.
It seems that answer/data is common among ALL list rows - clicking on
any row will advance the common 'data list to the next slot, thus
answer/data is not individual(separate) amongst the list rows.
Some ideas? Or is the rotary a non-iterable item as Brett pointed out
regarding text fields?
I would be grateful to the elaboration of this list-theme :-)
--
Geza mailto:[geza67--freestart--hu]
[13/14] from: anton:lexicon at: 6-May-2002 23:13
I am still trying to figure it out myself, but just quickly,
this might do enough what you want:
rebol [
Title: "Iterated Rotarys"
File: %iterated-rotarys.r
Date: 6-May-2002
Version: 1.0.0
Needs: [view]
Author: "Anton Rolls"
Language: 'English
Purpose: {Make rotarys in a VID list work}
Usage: {}
ToDo: {
- iterated rotary doesn't react quite the same as a single rotary:
- single rotary shows next value while mouse button down
- can't go backwards with alt-down (right mouse button)
- depends on face/state
}
History: [
1.0.0 [6-May-2002 {First version inspired by a post by Geza Lakner
MD [[geza67--freestart--hu]]
entitled "[REBOL] Re: Iterated check box anomaly (resend) - now, the
ROTARY!" on 6/5/2002} "Anton"]
]
Notes: {
adds a new facet word: 'my-count to the rotary
I am theorizing that to make all faces iterateable,
we could add a new facet, eg. 'save-data, which is an object!
with the facets that need to be stored (eg. data, text etc.)
The list should get/set this object in the supply code.
This get/set code will always be the same, making it trivial
to implement iterated faces on any style.
We would need to modify all the styles so that the appropriate
data is stored in save-data.
}
]
rows: 5 ; number of rows in list
rot-texts: ["first" "second" "third" "fourth"]
rot-data: copy []
rot-states: copy []
repeat n rows [
append/only rot-data rot-texts
append rot-states false
]
?? rot-data
view center-face layout [
list 500x150 [
across
cnt: info "1"
answer: rotary 240 with [my-count: none][
print [newline 'action face/my-count face/data]
; change the displayed value
face/data: either tail? next face/data [
head face/data
][
next face/data
]
; store face/data in rot-data
poke rot-data face/my-count face/data
?? rot-data
; store face/state in rot-states
;poke rot-states face/my-count face/state
;face/state: pick rot-states face/my-count
;?? rot-states
show face
] data rot-texts ; initial data goes into face/texts and face/data
] supply [
if count > rows [face/show?: false exit]
face/show?: true
if face/style = 'rotary [
face/my-count: count
]
switch index [
1 [
; info
face/text: form count
]
2 [
; rotary
;face/state: pick rot-states face/my-count
;poke rot-states face/my-count face/state
;?? rot-states
face/data: pick rot-data face/my-count
face/text: first face/data
;face/texts: rot-texts
]
]
]
]
Anton.
[14/14] from: geza67:freestart:hu at: 6-May-2002 18:31
Hello Anton,
> Title: "Iterated Rotarys"
> File: %iterated-rotarys.r
Nice idea nevertheless, thank you! This way also changing (state, face
text stc.) iterated items are easily implementable!
Although the iterated list seems to be more than a bit awkward than
any others found in streamlined GUI models - Java, Delphi etc.
...
--
Best regards,
Geza mailto:[geza67--freestart--hu]