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

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.

I tried all checkbox-related code snippets - they are now perfect.

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]

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.

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.

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?

I appreciate it.

Ahh! Nice! -- Best regards, Geza mailto:[geza67--freestart--hu]

try c/data Cheers, -pekr-

Quite inconsistent (... as so many aspects of VID ...) - toggles work with /state - but it works. Thank you. -- Best regards, Geza mailto:[geza67--freestart--hu]

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.

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

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-

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/

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...

-- Carl Read

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 ... ;-) )

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 ;-(

[ true-check check [state: true] [ ] == []

[ 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]]

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] ] ] ] ]

It would be more convenient if the widgets would behave more uniformly. -- Best regards, Geza mailto:[geza67--freestart--hu]

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:

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...

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

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. :)

Should now be: view layout [chk1: check with [data: true]]

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.

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.

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"