World: r3wp

de nada

~Hides~

(School starts on the 24th, and I'm seriously thinking about dropping 
4th year Spanish)

view problem: showing the parent-face doesn't work because that's 
the whole window. The thing is, if the first draw is done and I than 
click into the box that has the iterated function attached, the text 
is shown.

Not sure i understand. but another try:  the list uses the first 
face returned, even if you return another one later. "tmp-face: calendar-week-faces/(face/month)" 
if this returns different faces, the first face would be reused forever. 
if thats the "The problem is, that the text drawn first is still 
there.", yes, it would be.

so the "display-face" has to be the same all the time. means, either 
copy your data in it, as you do within a supply-block. Or put your 
face in display-face/pane.

Should be mentioned in docu.

hmm, the new object-set/get may be used here. 
  set display-face get calendar-face
:)

I further investigated the problem. First I use three different boxes, 
that use the same iteration function. The iteration function uses 
different proxy faces. So, each box uses its own proxy face.

The thing is that I have a pane that's 200x20 in size. Within these 
200 pixels, I'm positioning 5 faces that have a with of 30 each. 
So there are areas where my function doesn't return a face for. And 
these areas are not cleared by View. So if I hit the older text, 
it's overwritten, if not it stays there.


The problem is, that the box, where the iteration function is used, 
isn't cleared before doing a refresh.

I think you must display iterated face in the whole box area, but 
you set the text and color of some of them to clear "what was here 
before".

I think it is strange that you are iterating different faces. That 
seems to defeat the purpose of iterating to start with. You should 
iterate one face. It is a single face which changes its position, 
shape and contents rapidly when it is asked for. You have to ensure 
that the face always has the correct information when it is asked 
for. But anyway, we can't make good suggestions unless we see a more 
complete demo that we can run.

Hmm... the thing is that the faces must have different positions. 
So it's not distributed evenly. The apps is this:

I have day numbers 1-30/31 from left to right. And now at each Monday 
position, I want to draw the week-number. So x-positions shift.

different face: It's just three month side by side. So forget it. 
The problem applies to one month.

and each month has it's own iteration face.

You are using a single iteration function to manage three faces. 
Hmm... I hesitate to say it can't be done, but maybe it isn't recommended... 
unless I misunderstand it.

The problem looks like it is that you are only updating one of the 
faces and returning it per call of the function. So any faces which 
weren't updated stay where they were.

So is the month very wide (1 - 30/31 days) or do they wrap at every 
week ? ie. are you trying to make an iterated version of my calendar-month 
widget ?

ie. 
	1 2 3 4 5 6 7 8 9 10 11 .... 
or
	1 2 3 4 5 6 7
	8 9 ...
Perhaps you can draw and show us a picture of it ?

I think you need 2 main faces:
- A normal iterated face for days.

- A classic face with 5 subfaces to display week. You just have to 
change offset, size and text according the monday location.

The problem is that iterated face are not designed to display things 
of differents size or offsets.

Iterated face works fine with linear offset changes that give always 
the same result.

That's not true. I've seen a demo of iterated virtual faces flying 
around everywhere.

Dide, I think that's the way I'm going to use. KISS ;-))

Just thought it could be done with iterated faces too.

I am certain it can be.

Dide, sorry, there is truth to what you say. But it can be done, 
too, just more work for the programmer.

So there are areas where my function doesn't return a face for. And 
these areas are not cleared by View.

 Thats why i said "show parent-face". then the whole background face 
 is redrawn, then the iterated faces in its pane-function.

there is no parent-face. It's the whole layout and I need to do an 
initailize while layouting ;-)

for coordinates, my demo-rebol-colorizer uses them. Positions faces 
freely over a text.

Help ... I am trying to reset a button's background color with an 
action but am missing how to do that under View 1.3.  I think it 
worked before. I had thought it was:
  
view layout [button "Test" gold [
    face/text: "Text Reset" 
    face/color: red 
    show face
    ]
]

Hi, I am not sure, just ask View gurus here, but imo button is still 
"crippled" design ....

Look at get-style 'button and its 'init method. Imo button is colorized 
in terms of effect block, so face/font/colors, nor face/color does 
apply ... and don't be confused by face/multi part ... it is imo 
used when multiple facets of the same kind are used, as e.g. "button 
red green ...

IIRC I once did such trick and I used to redefine 'effect part, but 
it was long time ago ... it is imo pity that such stupid simple things 
require hacker aproach to styles

that is also why I propesed more of usage of "accessors", simply 
to have face/something, where that "something" would be handler, 
which would take care of everything needed in terms of style. Currently 
View/VID does not provide us with proper encapsulation in terms of 
OOP - while we have complete freedom, non experienced user can be 
confused and mess things ...

Thanks Petr ... I was hoping it was something simple that I was doing 
wrong.  


I have been probing the face objects for awhile and looking at the 
new View documentation.   I used the new View doc to get this to 
work 
face/color: get pick [green red] face/color = red 


from the example in a face but can't get the same satisfaction under 
VID layout button.

With oops i would look at the docu now.
with /view i look at
  echo on
  probe get in get-style 'button 'feel,
the redraw, and see there face/color is set from face/colors.
trying to change that,
 face/colors/2: red

does not work. Hmm, face/colors is none. i guess i give button two 
colors immediate.
  button "Test" gold gold
yup, now it works.

Also button is not the best example for customisation, as it does 
a lot to be smart with the vid.arguments.

yes, you have to change face/colors, not face/color. this is very 
common in VID.

Button style has changed since 1.2.1.

In 1.2.1 when you provide color(s) for a button, the button was simply 
of this color(s), no effect.

So you can change button color after layouting by changing the face/colors 
facet.

Since some betas (arround 1.2.30, 1.2.40), the face/init style has 
evolved, and now, the face/colors are used to generate two gradient 
effects during the creation of the button.
So it's way more difficult to change it later.

You can compare the init code of 1.2.1 and 1.3.1 for button like 
this :

probe get in get-style 'button 'init

Thanks for the help.  I was still having trouble because I was taking 
the default  button color in the the init layout then trying to change 
it based on some click action. If you default the button color, you 
can not change it.

Here is my test-script, comments below

view/new layout [across
	toggle "Test" gold "Test Reset" red [
		probe value
	]
	button "Test" [
		face/text: "Text Reset"
		face/colors: reduce [white red]
		show face
	] feel [
		redraw: func [face act pos /local state] [
			if all [face/texts face/texts/2] [
				face/text: either face/state [face/texts/2] [face/texts/1]
			]
			either face/images [
				face/image: either face/state [face/images/2] [face/images/1]
				if all [face/colors face/effect find face/effect 'colorize] [

     change next find face/effect 'colorize pick face/colors not face/state
				]
			] [

    if face/edge [face/edge/effect: pick [ibevel bevel] face/state]
				state: either not face/state [face/blinker] [true]
				if probe face/colors [face/color: pick face/colors not state]

    if probe face/effects [face/effect: pick face/effects not state]
			]
		]
	]
]

one is, maybe you want a toggle instead of a button?

that 'redraw is copypasted from original source (probe get in get-style 
'button 'feel).

then instrumented with a few probes. so i can track what really happens 
on  redraw.

seems it has to do with the effect. if i clear effect (face/effects: 
face/effect: none) i get pure colors. but with effects on it mysteriously 
does not work. dont understand that yet.

because i am not a graphics person ;) with default colors an effect 
looks like this: [gradient 0x1 66.120.192 44.80.132] and without 
[gradient 0x-1 32.32.255 173] . in first case last value is a color, 
in second an integer. seems the integer filters face/color, while 
the color-tuple overrides it.

Thanks Volker et al.   I am using VID for a quiz for my kid's grade 
school studies - mostly history and science questions.  In this humble 
attempt, the button label is the answer to a multiple choice question. 
When an answer button is clicked it changes from a default color 
to green if it is a correct answer or red if it is a wrong answer. 
 This might offend UI experts but the button color change (when it 
works) gives immediate feedback.  Repeating the drill seems to bring 
the number of wrong clicks down until they get toward zero and grades 
seem to go up accordingly.

good idea :)