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

Checkbox state is not changing - maybe Allen Kamp updates hi...

 [1/19] from: g:santilli:tiscalinet:it at: 8-Sep-2001 14:05


Hello [Sanghabum--aol--com]! On 08-Set-01, you wrote: S> Well, no, not really. Reading the source of "REBOL/View S> 1.2.1.3.1 21-Jun-2001" tells me what that version of VID does. S> It does not tell me what RT want it to do.... This is a whole different story. And documentation (in particular a community contributed documentation, as asked in this list) often describes implementation, not the designer's desires. What you're asking for is a formal specification, which is needed indeed for a language to be accepted in a lot of places (the academic world, for example). S> Quick fixes: yes; S> important stuff with a long lifecycle: no. Well, you are not forced to upgrade to a new version of the interpreter. When you have a solution that works, just keep it running on the same environment. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [2/19] from: arolls::bigpond::net::au at: 8-Sep-2001 1:33

Re: Checkbox state is not changing - Cybarite has a doc with check


I found a vid document that shows how to use checks, amongst other goodies... Take your rebol desktop to http://www.cybarite.com/public/index.r and click on "VID Usage" or directly, in console do http://www.cybarite.com/public/vid-usage.r

 [3/19] from: g::santilli::tiscalinet::it at: 7-Sep-2001 13:57

Re: Checkbox state is not changing - maybe Allen Kamp updates hisView F


Hello Geza! On 05-Set-01, you wrote: GM> That's the _main_ problem regarding /View, VID etc. We only GM> _think_ about things instead of _knowing_ it surely - with a Actually, that problem regards NATIVE!s etc. but it surely does NOT regard VID etc. You have the full source code of VID, so you really KNOW what it does. I'm sure that a lot of people does not have the time and will to scan all of the VID source code. But a lot of us here has read some part of it, and we all together probably have read ALL of it. GM> Then we should inform Allen Kamp that his information on GM> Rebolforces' View FAQ is incorrect. I tried his I think RF's FAQ was in part written during the beta days. Some things changed since then... GM> Because Allen seems to be a positively zealous :-) REBOL GM> personality I have only one explanation for this behavior of GM> all his code snippets: In /View 1.x where x<>2 but some GM> earlier release, checkbox's 'state property _worked_ as GM> expected. Maybe this /View release is buggy in this respect. That was not 1.x. It was most likely 0.y. I don't recall when the change was made... Keep in mind that in the first two betas there was CID instead of VID, and even if they are similar, there are a whole lot of differences... GM> view layout [c: check do [c/data: true]] or: view layout [c: check true] GM> It would be more convenient if the widgets would behave more GM> uniformly. They do. They have been changed in the past just for this reason. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [4/19] from: sanghabum:aol at: 8-Sep-2001 5:28

Re: Checkbox state is not changing - maybe Allen Kamp updates hi...


[g--santilli--tiscalinet--it] writes:
> Actually, that problem regards NATIVE!s etc. but it surely does > NOT regard VID etc. You have the full source code of VID, so you > really KNOW what it does
Hi Gabriele, Well, no, not really. Reading the source of "REBOL/View 1.2.1.3.1 21-Jun-2001" tells me what that version of VID does. It does not tell me what RT want it to do.... ....I may be writing code based on bugs that will be fixed in the next version ....I may be writing code based on features that will be removed in the next version ....I may be writing code based on the use of internal features or functions that are not meant to be exposed and will be hidden or changed in the next version ....I may be writing code based on features that aren't complete, and whose behavior will change in the next version. These things are all, of course, part of the cutting-edge risk involved in using something new, so I use Rebol with my eyes open to such possibilities. Which is precisely why I will not recommend it for "mission critical" systems. Quick fixes: yes; important stuff with a long lifecycle: no. I'd be a lot happier with Rebol if all the interfaces and intended functionality was published. That way..... ....this list would not have long discussions on (say) "tuples and sameness" that could be solved with a quick look in the documentation. ....we could report bugs confident that they ARE bugs (ie that the code doesn't do what the docs says—one or the other is wrong) ....we could plan the code we write to avoid (or embrace) features that are flagged as incomplete or deprecated ....Rebol would not be limited to the relatively few of us who have the time and patience to learn the language by reading the raw source code. The opposite end of the spectrum would be Rebol with an ISO standard number attached. That would give us clarity, but stifle RT/Carl's innovation. But we are far too far down the other end of the spectrum today, the one that could easily be interpreted as "Work it all out for yourselves, because we can't be bothered to tell you; and it'll all change in the next release anyway" The Perl and Python boys must be laughing themselves silly. --Colin.

 [5/19] from: geza67:freestart:hu at: 6-Sep-2001 21:57


Hello Allen,
> I've made some changes to the view FAQ, could you verify them for me please?
I tried all checkbox-related code snippets - they are now perfect.
> I'd like to add more content to the Faq but I've using View for so long, I > don't know what questions aren't answered in the docs, anymore. I tend not
Seriously --- are there any REAL official /View docs anyway ? ;-) Since CORE.PDF no comprehensive docs appeared ever on RT's site. Every /View hack originates from the REBOL community - ambitious members, like e.g. you. Because I do not have the time and effort to disassemble "system.r" I can do 'trial-and-error with 'ask-jeeves :-) . I thought about scanning e.g. this year's rebol-list postings for REBOL "fortune cookies" (WIKI has some niceties as well, on the Compkaori rebsite) and assemble something. If you would like, I will send you my advancements and you could incorporate them (or some of them) in your FAQ. -- Best regards, Geza mailto:[geza67--freestart--hu]

 [6/19] from: geza67:freestart:hu at: 6-Sep-2001 22:34

Re: Checkbox state is not changing - maybe Allen Kamp updates his View


Hello Anton,
> Just be aware that you are asking for people to > do work for you. Although it would benefit all > of us, not just you, it is still work to prepare > docs.
Sorry if my words mislead your mind: _I_ haven't asked anybody for doing anything. I just waived a flag, gave a notification. It is everybody's (specifically every " gurus' ") personal issue if he would react and work for _ME_(?) or not. REBOL community _painfully_ misses organized documentation. Being a rather small group and RT being a really small company as well, optimal "human resource management" is AN issue.
> You might want to send feedback to Allen with this,
Allen updated his FAQ beforehand and contacted me for verifying the code (which I indeed did): Now his VIEW FAQ is up-to-date upon checkboxes.
>> In /View 1.x where x<>2 but some earlier release, checkbox's 'state >> property _worked_ as expected. Maybe this /View release is buggy in >> this respect. > way. Whether or not you expected it is a matter of religion.
It is not a matter of religion - I think. If something worked one way in a release and works other way in a more recent release then the _change_ itself is a bit irritating. MS changed the document format of MS Office with almost every release making all users mad. WordPerfect has not changed the WP format for years - besides its typographic properties were far more advanced "ab ovo". Word just tried to race behind. If REBOL issues considerable modifications (e.g. look at 'stylize + 'with) in each release of VID then one may really ask: is the View framework so fallible & inmature that not only behind-the-scenes operations but the API itself should be reconfigured for each release?
> Allen's old code is now out of date, because of the more > consistent treatment of the data attribute in the latest View.
I appreciate it.
> Try this, which simulates code that takes a while > (one second).
<<quoted lines omitted: 5>>
> - button does action block > - button changes visual state to "up"
Ahh! Nice! -- Best regards, Geza mailto:[geza67--freestart--hu]

 [7/19] from: geza67::freestart::hu at: 3-Sep-2001 21:35

Checkbox state is not changing


Hello REBOLers, In REBOL/View 1.2.1.3.1 21-Jun-2001 the following code prints _only_ 'false values regardless of the visual state (checked or not checked) of the underlying check box: view layout [ c: check [probe c/state]] Have I missed something or is this /View VID release buggy? -- Best regards, Geza Lakner MD mailto:[geza67--freestart--hu]

 [8/19] from: petr:krenzelok:trz:cz at: 3-Sep-2001 22:08


----- Original Message ----- From: "Geza Lakner MD" <[geza67--freestart--hu]> To: <[rebol-list--rebol--com]> Sent: Monday, September 03, 2001 9:35 PM Subject: [REBOL] Checkbox state is not changing
> Hello REBOLers, > > In REBOL/View 1.2.1.3.1 21-Jun-2001 the following code prints _only_ > 'false values regardless of the visual state (checked or not checked) > of the underlying check box: > > view layout [ c: check [probe c/state]]
try c/data Cheers, -pekr-

 [9/19] from: geza67:freestart:hu at: 4-Sep-2001 21:04


Hello Petr,
>> view layout [ c: check [probe c/state]] > try c/data
Quite inconsistent (... as so many aspects of VID ...) - toggles work with /state - but it works. Thank you. -- Best regards, Geza mailto:[geza67--freestart--hu]

 [10/19] from: arolls:bigpond:au at: 5-Sep-2001 12:30


> >> view layout [ c: check [probe c/state]] > > try c/data > Quite inconsistent (... as so many aspects of VID ...) - toggles work with > /state - but it works.
Not really. I think state is whether gadget is "depressed" or not. The check cannot be pushed down in current implementation, therefore its state should not change. See this view layout [b: button [probe b/state]] It's always true, because: - first you press button, state becomes true (button looks depressed). - you let go of button, action occurs. - then state becomes false (button looks normal/ready again). Perhaps in future, check will react like button and change visual state when user clicks on it.

 [11/19] from: carl:cybercraft at: 5-Sep-2001 21:23


On 05-Sep-01, Anton wrote:
>>>> view layout [ c: check [probe c/state]] >>> try c/data
<<quoted lines omitted: 3>>
> I think state is whether gadget is "depressed" > or not.
Ahah! Now that actually makes sense. (Nearly.:) I'd thought it should be state and not data too, but I guess a check button also has an in and out state as well as a checked and un-checked one, so this is consistant. But data? Adding a 'checked? word would've been clearer I think. -- Carl Read

 [12/19] from: petr:krenzelok:trz:cz at: 5-Sep-2001 12:00


Carl Read wrote:
> On 05-Sep-01, Anton wrote: > >>>> view layout [ c: check [probe c/state]]
<<quoted lines omitted: 9>>
> is consistant. But data? Adding a 'checked? word would've been > clearer I think.
probably yes, but it is consistent imo too, if you look at the "data" in a "type" manner - what does it hold? Can it hold integer, text? No - it holds true, or false - it is only data it can contain, in opposite to field e.g. -pekr-

 [13/19] from: ammoncooke:yaho:o at: 5-Sep-2001 9:45


no! not more states, adding a checked only makes things complicated. Oneof the beauties, & I say one of the greatest beauties of rebol is that everything has a format, a particular layout. They all follow the same pattern. Basically all objects have the same properties, you don't have to guess, & you don't need a spec sheet on every object, just one explaning where to find what kind of info. My 2˘ Ammon

 [14/19] from: giesse:writeme at: 5-Sep-2001 17:37


Geza Lakner MD wrote:
> Quite inconsistent (... as so many aspects of VID ...) - toggles work with > /state - but it works.
Actually, most VID styles report their "value" in the DATA facet. The STATE facet, instead, is usually used internally by VID to hold the state of the face; this can sometimes be the same thing as its "value", but you should not make such assumption... HTH, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [15/19] from: carl:cybercraft at: 6-Sep-2001 9:04


On 06-Sep-01, Ammon Cooke wrote:
> no! not more states, adding a checked only makes things complicated. > Oneof the beauties, & I say one of the greatest beauties of rebol is > that everything has a format, a particular layout. They all follow > the same pattern. Basically all objects have the same properties, > you don't have to guess, & you don't need a spec sheet on every > object, just one explaning where to find what kind of info.
With VID, you do need a spec sheet. With text-list for instance, data's not enough. There's picked and other words you need to know about. This is mainly a docs problem though. Currently you have to guess that "Data: Used by VID for storing other information about the face. Outside of VID this field can be freely used by programs." means, in relation to check, where its checked state is stored. Let's hope that View book is out soon...
> My 2˘ > Ammon
<<quoted lines omitted: 24>>
> Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com
-- Carl Read

 [16/19] from: geza67:freestart:hu at: 5-Sep-2001 22:49

Re: Checkbox state is not changing - maybe Allen Kamp updates his View


Hello Anton,
>> >> view layout [ c: check [probe c/state]] >> > try c/data >> Quite inconsistent (... as so many aspects of VID ...) - toggles work with >> /state - but it works. > Not really. > I think state is whether gadget is "depressed"
That's the _main_ problem regarding /View, VID etc. We only _think_ about things instead of _knowing_ it surely - with a knowledge based on sound and behind-the-scenes _information_ (back to basics, i.e. /View's sparse documentation ... ;-) )
> or not. The check cannot be pushed down in > current implementation, therefore its state > should not change.
Then we should inform Allen Kamp that his information on Rebolforces' View FAQ is incorrect. I tried his checkbox-setting routines on /View 1.2.1.3.1) and neither his methods is working: First: it shows the layout, but check apears not checked view layout [chk1: check with [state: true] Second: simply error ;-(
>> checkers: stylize [
[ true-check check [state: true] [ ] == []
>> >> view layout [styles checkers
[ chk1: true-check chk2: check] Unknown word or style: true-check Third: shows layout, no checked checkboxes ... checks: layout [chk1: check chk2: check] chk1/state: true view checks Fourth: ... the same ... view layout [chk1: check do [chk1/state: true]] Because Allen seems to be a positively zealous :-) REBOL personality I have only one explanation for this behavior of all his code snippets: In /View 1.x where x<>2 but some earlier release, checkbox's 'state property _worked_ as expected. Maybe this /View release is buggy in this respect. Thus the current one of the checkbox-checking solutions is with 'data : view layout [c: check do [c/data: true]]
> view layout [b: button [probe b/state]] > It's always true, because: > - first you press button, state becomes true (button looks depressed). > - you let go of button, action occurs. > - then state becomes false (button looks normal/ready again).
I think your code is rather instructive but: 'probe is fired AFTER you have released the button thus button is in "up"-position. In this respect 'state again "lies": it should have been always FALSE. Maybe it is trivial but as I played around I could simulate a toggle with a button and a special engage function like this: rebol[] view layout [ button feel [ engage: func [face action event] [ if action = 'up [ face/state: not face/state show face print [face/state] ] ] ] ]
> Perhaps in future, check will react like button and change
It would be more convenient if the widgets would behave more uniformly. -- Best regards, Geza mailto:[geza67--freestart--hu]

 [17/19] from: john_kenyon:mlc:au at: 6-Sep-2001 9:16

Re: Checkbox state is not changing


Hi, I think an upgraded help function should address some of these problems. help native! lists all of the native words.
>From there you can get help on each function with help function name.
Fictional function, help/dialect view function! ; or some other syntax to show words available in dialect help/dialect view face or help/dialect layout field maybe extend to help/dialect parse thru Comments? Cheers, John On 06-Sep-01, Ammon Cooke wrote:
> no! not more states, adding a checked only makes things complicated. > Oneof the beauties, & I say one of the greatest beauties of rebol is > that everything has a format, a particular layout. They all follow > the same pattern. Basically all objects have the same properties, > you don't have to guess, & you don't need a spec sheet on every > object, just one explaning where to find what kind of info.
With VID, you do need a spec sheet. With text-list for instance, data's not enough. There's picked and other words you need to know about. This is mainly a docs problem though. Currently you have to guess that "Data: Used by VID for storing other information about the face. Outside of VID this field can be freely used by programs." means, in relation to check, where its checked state is stored. Let's hope that View book is out soon...

 [18/19] from: allenk:powerup:au at: 6-Sep-2001 19:29

Re: Checkbox state is not changing - maybe Allen Kamp updates his View


> view layout [chk1: check do [chk1/state: true]] > > Because Allen seems to be a positively zealous :-) REBOL personality I > have only one explanation for this behavior of all his code snippets: > In /View 1.x where x<>2 but some earlier release, checkbox's 'state > property _worked_ as expected. Maybe this /View release is buggy in > this respect.
It is indeed true, they were written for a previous beta version by members of this list. When 1.0 was released a number of people offered to check the examples in the FAQ (as I didn't have time then). Since no-one pointed out any errors, I lived in happy ignorance that I didn't have to revise anything. Sorry if those examples misled.. I am happy to add any correction or additional content to the FAQ.. Cheers, Allen K

 [19/19] from: arolls:bigpond:au at: 6-Sep-2001 22:41


See comments below.
> >> >> view layout [ c: check [probe c/state]] > >> > try c/data
<<quoted lines omitted: 8>>
> and behind-the-scenes _information_ (back to basics, i.e. /View's > sparse documentation ... ;-) )
Just be aware that you are asking for people to do work for you. Although it would benefit all of us, not just you, it is still work to prepare docs. However, I am listening. I have been doing some docs, they just aren't ready yet. :)
> > or not. The check cannot be pushed down in > > current implementation, therefore its state
<<quoted lines omitted: 4>>
> First: it shows the layout, but check apears not checked > view layout [chk1: check with [state: true]
Should now be: view layout [chk1: check with [data: true]]
> Second: simply error ;-( > >> checkers: stylize [
<<quoted lines omitted: 5>>
> [ chk1: true-check chk2: check] > Unknown word or style: true-check
Ok, the above should now be: checkers: stylize [ true-check: check with [data: true] ] view layout [ styles checkers chk1: true-check chk2: check ] You might want to send feedback to Allen with this, if he is not already on to it.
> have only one explanation for this behavior of all his code snippets: > In /View 1.x where x<>2 but some earlier release, checkbox's 'state > property _worked_ as expected. Maybe this /View release is buggy in > this respect.
Yes, in an earlier release, check's state property worked that way. Whether or not you expected it is a matter of religion. Allen's old code is now out of date, because of the more consistent treatment of the data attribute in the latest View.
> Thus the current one of the checkbox-checking solutions is with 'data : > view layout [c: check do [c/data: true]]
<<quoted lines omitted: 6>>
> AFTER you have released the button thus button is in "up"-position. In > this respect 'state again "lies": it should have been always FALSE.
No, because button does its action block before changing the button visual to the "up" position. Try this, which simulates code that takes a while (one second). view layout [button [wait 1]] So the sequence is: - user presses mouse button on button - button changes visual state to "down" - user releases mouse button over the button - button does action block - button changes visual state to "up"

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