World: r3wp

Can I see a demo of your technique, Steeve?

I wanted transparent events along with transparent regions of a face 
(eg. a face with rounded corners, the events should pass through 
the corner regions, but the rest should land on the face).
It just couldn't be done properly - see my file
http://anton.wildit.net.au/rebol/gui/transparent-events.r

even in R3 Carl use the same trick

Try click on the button at the left and drag to the right.

I want to see code. (But got to go - I'll check back later.)

(My stuff all relates to R2, by the way.)

(and not at all to R3)

Hmm Anton, you can't do like that, you must hack the global event 
handler with insert-event-function

Hmm what you are trying to do anton is tricky, i never did that, 
i always had the transparent area covering the whole unerlying faces.
It was much simple than your use case.

I don't use VID styles as underlying faces but my owns to discard 
the default dispatch of events (no feel object).

But in your case, you'll have to translate all move events comming 
from the global handler into OVER, AWAY events depending of the sub-face.
Lot of work...

Yes, what I tried was a definitive solution. But after working on 
it for a very long time, I found it can't be done completely. (At 
least, I am 99% certain.)

well, it allowed you to build skewed windows, which isn't a small 
feat within windows   :-)

Well, yes, but it still wasn't a complete solution.

Is there a delay with view when working with internal values?


For example if I change the offset of a scroll-panel after showing 
it it reverts to the changed value but if I put a wait of .1 the 
offset viewed remains as expected and does not show the new value.

Am I making sense?

the wait is after show but before the offset value is changed...

the function SHOW, pushes a new show event in the events stack,but 
is not dispatched until your program enter in a wait loop.
So it's normal.

Thanks steeve. I thought I was loosing it..again.

It's the main difference between procedural programming and event-driven 
programming.

When you develop event-driven applications, you must use a different 
flow in your code

Don't exactly get that but I will keep it mind, thanks.

Eheh, you have no choice, when you are programming a visual interface 
with Rebol, it's an event-driven flow

amacleod, doesn't make sense to me. Are we talking about R2?

Which scroll-panel are you using ?

anyone interested in an SCP based file copy software? this uses SSH 
port, so no need for ftp on the server  :-)  I've already got file 
browsing working.

this is view based client.

sure ...

does View set parent-face for a layout internally?

it is set after a show

so it's internal

but you can set it manually.   :-)  as long as its the actual parent, 
its totally safe.

some view functions require the parent-face to be set in order to 
work.... this is sometimes usefull when you want to create stuff 
between a call to layout and one to show.

I guess it comes from the fact that you can build face trees manually 
and therefore would need to set them with SHOW directly.

glayout has always set parent-face directly after creating panes 
on the fly and its never been an issue.

I'm altering the VID model and so all faces are required to have 
a parent-face set.

Yeah, I guess I need to do the same.

btw, you know that creating row/colum styles in VID is really easy?

example?

you can do directly within a call to style :-)

give me a minute... will load code to be sure I give a proper working 
example.

row: box edge none with [
		color: none
		multi: make multi [
			block: func [
				face 
				blks
				/local frame tt
			][
				if block? blks/1 [
					frame:  layout compose [
						origin 0x0
						space 10x10
						across
						(blks/1)
					]
					face/pane: frame/pane
					

     face/size: frame/size + any [all [face/edge 2 * face/edge/size] 0]
				]
			]
		]
	]

I see. :-)

maybe I'll use that for forms.

the nice thing is that you get R3/Glayout style layout blocks  :-)

adding the column...

column: box edge none with [
		color: none
		multi: make multi [
			block: func [
				face 
				blks
				/local frame tt
			][
				if block? blks/1 [
					frame:  layout compose [
						origin 0x0
						space 10x10
						below
						(blks/1)
					]
					face/pane: frame/pane
					

     face/size: frame/size + any [all [face/edge 2 * face/edge/size] 0]
				]
			]
		]
	]



view layout [
	column [
		row [
			vtext 100 "first name"
			field
		]
		row [
			vtext 100 "last name"
			field
		]
	]
]

layout is totaly obvious at first glance and all alignment is perfect.

ok, can you decide the size of a column? say you want to share column 
sizes across multiple panels.

I never understood why these where never added to VID.

if you look at the styles above, they inherit their sizes from the 
content... but you can easily do a simple trick  :-)


only inherit the size in the direction of the size which is set to 
-1

so if you do: 	

column 200x-1 [ 

then it would staticaly size the x but inherit the y

I see.

new style with this trick enabled....

column: box edge none with [
		color: none
		multi: make multi [
			block: func [
				face 
				blks
				/local frame tt
			][
				if block? blks/1 [
					frame:  layout compose [
						origin 0x0
						space 10x10
						below
						(blks/1)
					]
					face/pane: frame/pane
					unless face/size [face/size: -1x-1] ; prevent error below
					if face/size/x = -1 [					

      face/size/x: frame/size/x + any [all [face/edge/x 2 * face/edge/size/x] 
      0]
					]
					if face/size/y = -1 [					

      face/size/y: frame/size/y + any [all [face/edge/y 2 * face/edge/size/y] 
      0]
					]

				]
			]
		]
	]

graham: wrt scp copy... I'll finish writting it and see if it can 
be posted to rebol.org... I need it to setup my linode server.

 so it will definitely be done shortly.

I think I'll borrow that style if you don't mind. :-)

Henrik: realize that in the above, you can add other faces in the 
group layouts on the fly, I sometimes do so to provide title bars 
to my panes.


in which case I use the multi and add another callback with the function 
name to 'text   and set the string to some internal buffer, then 
reuse that text in the dynamically created group/frame title bar 
instead of the group's text itself.

;-)