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

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]