World: r3wp

Eh? You really ought not to have to modify the scroll-panel.r file. 
That's just going to cause problems for you down the line, because 
you are forking. You should be able to override the default scroll-panel 
feel in your user code. Just let me know what you're trying to do 
with that and I'll show how.

Anton, I had the same worry about forking....

this addition/change to scroll-panel.r works: 

detect: func [face event][
	if event/type = 'alt-down [	
		if face/var = 'my-scroll-panel [ print "hello"]
	]
	event
]

But this addition to global handler does not: 

alt-detect: func [face event][
	if event/type = 'alt-down [	
		if face/var = 'my-scroll-panel [ print "hello"]
	]
	event
]
insert-event-func :alt-detect

get error on face/var

Yes, probably because not all faces in the system are VID faces. 
A VID face is an extension of system/standard/face with several facets 
added, including VAR.

If the event handler came across a non-VID face, then face/var is 
an invalid path.

So you see, this is an example of why using this method to identify 
a face is more brittle.
You should better use:

	face = my-scroll-panel

to determine identity of a face.

Anton, Your method is not working for me:

alt-event: func [face event] [
	if event/type = 'alt-down [ print "alt-click"
		if face = my-scroll-panel [print "face name = my-scroll-panel"]
		]
	event
]
insert-event-func :alt-event


I get "alt-click" but I do not get true for 'if face = my-scroll-panel'


I tried 'my-scroll-panel (word) and "my-scroll-panel" (quotes") also....

Aha, I know what's probably happening. The scroll-panel contains 
a number of subfaces in a face hierarchy. You are probably not clicking 
on the scroll-panel face, but on one of its subfaces (which are laid 
on top of it, event-wise). If you look at scroll-panel.r, near the 
bottom of the rebol header, you will see the face hierarchy, with 
the two scrollers, the CROP-BOX and the SUBFACE inside the crop-box. 
The SUBFACE covers most of the area of the scroll-panel, and the 
two scrollers take some from the sides.

You can test this idea by giving the scroll-panel an edge, then alt-clicking 
on the edge. You should get a positive identification then. But of 
course, this is probably not very useful to you. What (I assume) 
you will need to do is, given a face, find out if it is inside a 
scroll-panel (or inside a particular scroll-panel of yours). This 
is a little bit complicated, but I have done most of that coding 
already for  mouse roll-wheel scrolling. (See scroll-wheel-handler.r, 
and demo-scroll-wheel-handler.r for how to use it.)

Basically, you will want to make your own "right-click-handler.r", 
just copying scroll-wheel-handler.r's code and modifying the event 
type that is checked for to 'alt-down. Scroll-wheel-handler checks 
for an Anton-extended VID flag, SCROLL-WHEEL, to determine which 
face should handle the event. So I might also advise you define your 
own VID flag to indicate that a face handles alt-click, maybe call 
it simply ALT-DOWN like the event that triggers it, or CONTEXT-MENU-ACTIVE, 
or whatever you're doing. Then make sure that the faces you want 
to respond to your "right-click-handler.r" are flagged with this 
new flag.
That's all, simple!

I think I see what you are saying, but...
Sounds like more than I want to tackle right now...

I think I'm going to stick with hacking up scroll-panel.r (since 
it seems to work)...the whole app feels like a hacked mess anyway 
so when R3 is ready I'll rewrite it for R3...Where I hope alot of 
these problems will not exist..

Thank you for the help

why not just follow the face up to its parent until you hit the scroll 
panel and then compare then?

not sure how to go about that..

doesn't each face have a value for parent-face ?

That's exactly what I'm doing in scroll-wheel-handler.

Starting with the face clicked on, I climb up to the parent-face 
iteratively until I find an ancestor of the face which is a scroll-panel.

(or until there is no parent-face, which means we are at a top-level 
window face.)

amacleod, I thought all that complication would make you pause. And 
fair enough. I should say though that I've done the scroll-wheel-handler 
in the most proper way I can. It seems a pity not to take advantage 
of its structure. Anyway, it would be nice if you could say what 
you want to handle alt-click for. I'm still not sure why you want 
it. If that's clear to me, then I could probably make the new handler 
for you pretty quickly, as I'm more familiar with my code, obviously.

Incidentally, the VID Extension Kit has a lot of functions to help 
in these situations for finding a specific face.

To for example find the window a face sits in:

root-face face

if you look at the source, the file vid-funcs.r contains most of 
these functions.

Hello All,

I'm working with events but I'm stuck. Any help is appreciated. here 
is the code:

rebol [	title: event testing]
lo: [
	text 100x100 "Hello" 

  edge [size: 25x25 color: 255.0.0 effect: 'bevel]				;; <--edge set 
  here works
		feel [
			engage: func [face action event] [
				if event/type = 'down [
					face/color: 0.200.0
					show face
				]
				if event/type = 'up [
					face/color: 0.0.200
					show face
				]
			]
			over: func [face into pos] [
				if equal? into True [						;; 

     face/edge: [size: 25x25 color: 0.255.0 effect: 'bevel] 	;; <-- edge 
     changed here
					probe face/edge					;; 
					print into						;; 
					show face						;; <-- doesn't render
				]								;; 
				if equal? into False [						;; 

     face/edge: [size: 25x25 color: 0.0.255 effect: 'bevel] 	;; <-- edge 
     changed here
					probe face/edge					;; 
					print into						;; 
					show face						;; <-- doesn't render
				]								;; 
			]
			detect: func [face event] []
			redraw: func [face action offset] []
		]
]
view layout lo

replace the lines where:
>>face/edge: [...]
by
>> face/edge: make face/edge [...]

face/edge is an object, not a block

Thanks Steeve.  That did the trick.

question:  Why did I not have to 'make the edge initally?

ahah, i was waiting for that question

because the lo block you constructed contains a dialect, not rebol 
code.

When you call the layout function, the dialect is processed and the 
values [edge [...]] are translated to code [face/edge: make face/edge 
[...]]

Thanks.  I'll let the brain gears process this for a while.

you can see the source of the layout function to have an idea of 
how the dialect is processed.

But layout is an obfuscated function with too much dependencies with 
other hidden functions.

It's rather difficult to have a whole understanding of how it works.
It reclaims several years of training.

Then is something like this possible? or does the layout function 
always take input either at that location or the 'edge word as dialect? 
 I guess the question could be... how do we know if we are creating 
code or dialect and does it matter?


view layout [text 100x100 "Hello" edge: make/edge [size: 25x25 color: 
0.0.255 effect: 'bevel]]

To see if you can, just try it (in your case it fails).

it won't work, because the edge is not a dialect keyword outside 
of 'with.

Sorry.... should have put the ';; <---- fails' comment next to the 
line.   Hence the rambling questions....

Henrik, that makes sense.  I'll look for docs on the 'with word. 
Thanks.

Ben, see private message.

Thanks. That opens my eyes to what I refer to as Rebol Voodoo. One 
can easily forget the relationship between a dialect and Rebol. Good 
stuff.

It's the central point with Rebol, when a function is accepting a 
block as input, you can't  guess if it will be processed as pure 
rebol code, list of data, or as a dialect (mixed data and commands).
Data is code, Code is data. Never forget.

Are you kidding? It took me a long time before I stopped turning 
everything into a string with my own functions! :-)

i meant you can't guess until you read the documentation of a specific 
function.
'help and 'source are they magic keys.

*the magical key

Oh, I like the feeling when I can say "Oh, that's how it works." 
And then there's anamonitor. I can't tell you how many times I've 
gone back and forth with that tool. :-)

source.... I keep forgetting about that command.  thanks for the 
reminder.

Having trouble changing the data in a drop-down list...

mylist/list-data: new_stuff 
show mylist

works the first time but not there after

you must clear /append in the same original block  :-)

Sorry, not sure what you mean

you should clear the original block you supplied to the drop down 
list, and then append new items to it.  that should work.

new_stuff: copy []
foreach book books [append new_stuff book]

If this is what you mean, I'm doing it...

I'll write you up an example... its easy you'll see.

insert clear head mylist/list-data new-data

it uses texts...

rebol []

items: []


dark-colors: ["Blach" "Navy Blue" "Blood red"]
light-colors: ["Gray" "Cyan" "Pink"]

append items dark-colors


view layout [
	drpdn: choice with [texts: items]
	do [
		probe drpdn/init
		probe drpdn/words
		probe drpdn/multi
		probe drpdn/feel
	]
	toggle "hi" "low" [
		clear items 
		append items either face/data [light-colors][dark-colors]
	]
]

you can also replace face/texts directly I think...

I left the old "do" trick which allows one to easily scan a face 
to look up how it works... not sure many realize they can do this.

I was hoping to use the 'drop-down' style (not choice)...is there 
a difference with the function?

same thing... just replace choice by drop down