click the button and look at the red filter drop down on tt2. There are two <=======> options. Should there only be one when a filter is in place?
I don't know what does the "<=======>" option mean exactly so let's see if Rebolek can comment on that.
IIRC (it's been a while that I used it):
do-actor tt2 'on-filter-data [1 [value = 1]]
The [1 [value = 1]] part means: - filter column 1 - filter by value 1
VALUE is the word that's used by the filter code to compare for TRUE or FALSE
I think it's even possible to filter by more than one column, filtering is applied in order. So first filter, than on the result-set, 2nd filter etc.
How to programaticaly set drop-down at i.e the second item of data ?
view[ d: drop-down [ "11" "22" "33"] on-action button "set drop-down to 2" on-action [set-face d 2]]
I'm struggling a lot coming from R2 and dealing with faces. get-facet seems extremely unintuitive to me.
Let's say I have an area:
view [c: area "hello"] print get-facet c 'text-edit
get-facet always returns "hello" even if I type something else in the area. What is going on with this?
is there a different facet that stores the "real" information?
the 'state and 'caret objects have the correct text, but can't find a way to access those
ah, yes, '
making things overcomplicated, I suppose
I think I assumed that GET-FACE would return a face-object
Josh, this getter function is same as in R2 VID...try:
>> view/new layout [a: area "Hello"] >> get-face a == "Hello"
So R3GUI is 'compatible' in that way and R2 VID users should be familiar with that interface already.
But it is true most people are used to directly hack into the style internals in R2 VID. So in R3-GUI we wanted to avoid that and 'force' people to use indirect/abctract mechanisms from the beginning because In the end both sides, the user and the style designer are happy because using the abstracted methods user's code won't break if style internals are changed in future versions.
Cyphre, does that explain this:
"get-facet always returns "hello" even if I type something else in the area."
sure, the get-facet is not a 'public api'..it shouldn't be used by application code get-facet function is for style programmer Why it shouldn't be used by app programmer? Because it is used to access internal values (facets) of the style (ie. direct access) Why style programmer should use it instead of direct access like face/facets/value? If you look at the source of the function it does other checks as well so it will behave always correctly in all cases. Also if internal structure of the face is changed the style code doesn't need to be modified.
This is just my POV how R3GUI should work. As you can see we don't have the code modularized yet so app programmer cannot see which fuction is 'public'. Also the styles are still using the face/facet/value construct frequently but this can be hopefully changed as well.