World: r3wp

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
			]
		]
	]
]

What are you actually trying to do, Paul ?

I'm not trying to do anything actually - I actually do it from within 
the feel as well.  I agree that I don't want REBOL to bloat anymore 
than necessary.  I think this could be something that could be added 
to VID for example.  I think VID could even be pulled out of the 
system object and just loaded when needed.

That's how it works in the SDK.

Yes, but there must be some reason why you want to do this on this 
particular day :)  But I still don't agree it's good to add a new 
facet to the face object just for this one purpose. Consider how 
many different confining systems there can be. This is something 
that should remain user-programmable.

What are names of the registry function in View?

I need to get the install dir

They seem to be removed (at least from global context) in View 1.3.1 
(or maybe before). Previous betas had these (eg. View 1.2.7):
>> ? reg
Found these words:

   create-reg      native!   Creates a registry key and returns TRUE 
   on success...

   delete-reg      native!   Deletes a registry key. Returns TRUE if 
   deleted. (...

   exists-reg?     native!   Returns TRUE if registry key exists. (HKCU 
   is defa...

   get-reg         native!   Returns value of a registry key, else NONE. 
   (HKCU ...

   list-reg        native!   Returns a block of sub-keys for a registry 
   key. (H...

   set-reg         native!   Sets registry key value. Returns value 
   on success,...
   unset-reg-funcs function! [

(sorry that was in View 1.2.57)

or do you need the registry locations?

and it worked like this:
>> get-reg/hkcu "Software\Rebol\View" "Home"
== "d:\anton\dev\rebol\view"

Exactly, that's what I need. But latest view doesn't have those functions

Maybe for your situation you could start an older rebol beta just 
to get this info ?

The problem I have is, that I start a reblet from inside IOS but 
it needs the new View. So I cechk this and want to start View automatically. 
For this I need the install location, dynamically at runtime.

The reblet needs the new View (1.3.2) or IOS needs the new View (1.3.2) 
?

VIEW-ROOT doesn't give you what you want ?