World: r3wp

what are you trying to do? can't you randomize a tuple directly?

well i want random collors in my 'draw effect like this ->

 effect: compose [ merge fit draw [  
                        pen randomcolor + alpha blending
                        line-width 4
                        line-pattern 1 5
                        fill-pen randomcolor + alpha blending
                        box 10 10 8
]

but somehow Im unable to do that with compose or reduce...

so i need to rejoin the random color with i.e. the alpha of .64...
Do i need a compose/deep on this perhpas?

0.0.0.64 or random white

you don't need to compose (compose/deep in this case) at each change, 
you can just change the value of 'randomcolor, then show the face. 
draw blocks aren't fully evaluated ("+" does nothing), but words 
gets their values

yes thats what I though... but somehow I need to be able to stick 
the colors and the alpha together and that brings me always to a 
string.. instead of a tuple.. so the result is 'none and thus my 
drawing is transparent ;-)

to-tuple rejoin [ random white "." 64 ]

Duh? i tried that already... But I see now... i mixed a .64 and a 
"." 64 with the rejoin.. This would indeed ben very odd if that would 
not have been possible ;-) Thnx...

>> (random white) + 0.0.0.64
== 85.26.216.64

how to tell if your app has focus or not ?

I want to sound an audio cue for incoming messages if I don't have 
focus on the chat program

you would have to use win32 api imo ....

oh well...

a problem? :-) I have some win-shell wrapper, may post it ...

could try the file sharing here .. is it enabled yet?

but - windows windowing system is somehow curious - I mean - I sometimes 
don't understand what function should I use for what ...

dunno ...

Graham, perhaps track when it loses focus.

view/new window: layout [area]
window/feel: make window/feel [

 detect: func [face event][if find [active inactive] event/type [probe 
 event/type] event]
]
do-events

Yes, if you track active or inactive events, you can always know 
the current state.

I'll give that a go...

Q: invalid args: []

Hi, I have a layout, and I always get the above mentioned error ... 
does anyone know a some hints to find the culprit? I haven't succeeded 
so far.

Q: focusing a specific field

Whar's the best way to focus a specific field on display of a layout? 
ATM I append sth like:
do [focus the-field]

that's what I do.

Thanks Graham, it's nice to know that I'm on track ;-)

Q: Clickable list lines

Hi, I have a 'list with several 'texts in it, Now I want to be able 
to click anywhere on a line, and start some action. So far I add 
an action block to the text fields. Is it possible to add it to the 
list itself, so that it is available anywhere on the line, even when 
there's no text field?

I think so. Probably just modify the list face's feel/detect function.

Is someone able to point me to a document on the design principles 
of VIEW's modal window system which has kept up with the latest changes 
and corrections made by IIRC Romano and Gabrielle? I only located 
snatches on the web but found no official or semi-official docs.

Should have read "design goals" rather than "principles". It's the 
idea I'm looking for, and even the SDK sources are very terse wrt 
this subject.

1) show-popup creates modal windows (either inside a parent window, 
as a subface, or outside as a standalone window)

2) modal windows have a pop-detect feel that catches *all* events

3) this feel decides if the event should be eaten, the popup should 
be closed, and so on

4) there are 8 default handlers for popup windows with a predefined 
pop-detect

4.1) the default one, blocks all the other events, and hides the 
popup on close

4.2) the "nobtn" one is assigned to popups without any actions. it 
hides the popup on any click inside the popup

4.3) the "away" one closes the popup on any event (except move, time, 
active and inactive) outside of it

4.4) the "away-nobtn" one is a combination of 2 and 3

4.5) the "win" one is for popups inside another window (as a subface), 
and has a different logic to figure out if the event is "outside" 
or "inside" it; it also does not hide the popup on close

4.6) "win-nobtn" combines 2 and 5

4.7) "win-away" combines 3 and 5 (e.g. popups for CHOOSE and so on)

4.8) "win-away-nobtn" combines 2, 3 and 5

if you have the sdk, look at view-object.r for how this is done.

Hi Anton, thanks, I'll try that.

Concise, clean and straight  to the point, Gabriele. It's information 
like this I expected to get through commented source code when I 
once bought the SDK. Invaluable information - it's fairly easy to 
see what code is doing, but hard to understand what code want's to 
accomplish. Thanks!

yes... i agree. that's indeed an important commenting rule (intent 
in the comments, action in the code)

i hope we can get this better for R3

How do most people handle drag and drop events so that the drag face 
doesn't go beyond the borders of the parent face?

I was thinking about this last night and a good modification to the 
face object might be good to include the item 'move-limit

No that's not necessary. We actually want to cut down on such bloat. 
The face object needs a bit of plastic surgery.

view center-face layout [
	box: box navy 300x300 with [
		pane: make-face/spec 'box [
			size: 80x80 
			offset: 40x40 
			color: red 
			text: "drag me"
			feel: make feel [
				engage: func [face action event][
					print remold [action event/offset]
					if find [over away] action [
						if drag-off [
							; we are dragging
							face/offset: face/offset + event/offset - drag-off
							; now constrain the face within its parent box
							;face/offset: confine face/offset face/size 0x0 box/size
							show face
						]
					]
					if action = 'down [drag-off: event/offset] ; begin drag
					if action = 'up [drag-off: none] ; end drag
				]
				drag-off: none
			]
		]
	]
]