World: r3wp

so if Paul has found a trick that allows us to use the normal file 
requestor so it can pick folders... YAY

It wasn't a common dialog though, and required callbacks (at least 
the Shell API I knew of). I don't remember it in 16-bit Windows, 
but the duff on the floor of my brain is thick.

Max, not sure what dialogs you're talking about, but the common dialogs 
allow that.

Maxim, I think that the "New folder" button is an option for the 
folder selection dialog; at least I see it often in programs pre-Vista. 
Vista+ the folder selection dialog is a subset of the Open/Save dialog, 
with most of its abilities.

Gregg, it's possible that the Win3.1 programs that I remember were 
using a custom dialog that served as the inspiration of the later 
common dialog, but they worked the same. The common dialogs themselves 
were a later addition, iirc; not sure whether Windows before 3.0 
had them.

was there windows before 3.11?  ;-)

Yup. Windows had a 1.0.3 release, just like REBOL but with less memory 
usage :)

I was joking, there where many releases before 3.11 ...  ;-)

I know, just going with it :)  Though practically, I considered REBOL 
1.0.3 to be more useful than Windows 1.0.3 :)

hehe, but its funny that windows 1.0.3 actually didn't have windows, 
it was a row/column/grid gui engine.

the OS itself I mean.

and it was running with what... less than 1 Mb ?

Less that 512k - room to spare to run apps even if you only had 640k.

Partly due to the wonders of small screen resolutions and bitdepths 
(which made tiled windows a bad idea). Nowadays I have screen images 
that take more memory than Win 1.0.3 altogether :)

I remember that with 3.11 the memory allocated for graphic controls 
of an active window was limited to 64Kb

yes people forget that just storing a SINGLE bitmap which is 1280x1024 
in RGBA colors, takes up 5.25 MB of ram.

it adds up very quickly.

To be fair Steeve, just about everything in Win3.1 was limited to 
64k - stupid segmented memory. I jumped at Win32s when it came out 
:)

trying to use set-face in a loop to assign values to multiple text 
fields...what is wrong here?

fields: [a b c]

foreach field fields [
	set-face field now
]

although I never used set-face... 

I'd say you have to do:

	set-face field to-string now

I tried it with a string ...I was not thinking when I wrote the example

getting this error:
** Script Error: in expected object argument of type: object port
** Where: set-face
** Near: if all [
    access: get in face 'access
    in access 'set-face*
] [
    access/set-face* face value
]
if

add a show to it... might just not be refresing itself.

ah.

probably just need to 'REDUCE your fields block first.
its not receiving an object as its first parameter

fields: reduce [a b c]

foreach field fields [
	set-face field now
]


btw... use the 'source command whenever you get these types of errors.

>> source set-face
set-face: func [

    {Sets the primary value of a face. Returns face object (for show).}
    face
    value
    /no-show "Do not show change yet"
    /local access
][
    if all [
        access: get in face 'access
        in access 'set-face*
    ] [
        access/set-face* face value
    ]
    if not no-show [show face]
    face
]

I never use set-face either but I'm tired of setting a bunch of fields 
manually

The fields need to stay as word! 

If I reduce them they will give me their current value...

remember that even if [a b c] are bound... they will still be passed 
as words to the function in your loop.


another way is to use 'GET directly on the words within the loop, 
but that can have hard to understand binding side-effects, depending 
on how the block was originally created.

example using 'GET

fields:  [a b c]

foreach field fields [
	set-face get field to-string now
]

that works...thanks

but I do not fully get it...I look into it.

GET gives you the value of a word.  


the detail being that the word may or not be bound.  when it isn't 
bound explicitely, it will search for it in the global context (explicitely 
if you give it a lit-word).


which is why its always a good idea to use GUI code within a context, 
so you can be sure any un-explicit binding is local to that context. 
 note that you must explicitely create them within the context (at 
the root level of the context) for that binding to occur.


(note to Lad & Brian..I know I'm over-simplifying the whole concept, 
but that is how basically it works for "mere mortal"  ;-)

ex: 
here .... danger!   [a b c] use isn't bound within the context.

context [
	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]





while this will be (and protect your global context from being clobbered 
by the field names), plus you are sure that GET will try to use the 
field names locally.

context [
	a: b: c: none

	layout [a: field b: field c: field]

	fields: [a b c]
	foreach field fields [
		set-face get field to-string now
	]
]



if you really wanted to be funky, you could put words in the [a b 
c] block which are bound to other contexts using 'IN.

append fields [] IN other-context 'd


then when the loop runs, the field specified by d in that OTHER context 
will also be set.

hehe... that seems like it was a "Binding 101" tutorial   hehehe

That helps...I think. thanks

using the above tricks you can make system-wide intialisation functions:


here is a cool previous login detection system which fills up your 
whole gui based on stored data in a database.

	

; supply contexts, view controls set into them and the data to set 
into.
setup-all-gui: func [
	spec 
	/local ctx control controls data i
][
	foreach [ctx controls data] spec [
		repeat i length? controls [
			control: get in ctx controls/:i
			set-face control data/:i
		]
	]		
]
	
; reload previous session
either all [

 main-data: get-sql-last-main-data  ; returns [ "project" "module"]

 login-data: get-sql-last-login    ; returns ["user" "encrypted" "server.com"]
][
	setup-all-gui reduce [
		main-gui [proj-fld mod-fld] main-data  
		login-gui [login-fld passwd-fld server-fld] login-data
	]
][

 print "This is the first time you use application, user-setup will 
 now be called."
	setup-user
]

is it not possible to capture ctrl+tab?

no ... that is my old-time complaint ... ctrl tab is needed to swithc 
between tabs ....

ok, thanks

http://www.rebol.com/downloads/v277/viewpro-277-agg-fix1.exe

are there known problems with RATE inside a DETECT? when I use it, 
EVENT/TIME is fired constantly, even if I set rate to something like 
0:0:10.

whoops, I meant event/type = 'time, not event/time.

you need to do a show of the face to have the rate taken in account.

here is how it works..... I had to stumble upon this within GLASS.


when you add a rate to a face, actually, the timer will trigger 30 
times a second, no matter what your rate is.

do event

will filter the events based on what your rates are set up.

because detect is part of the wake-event system, it gets all the 
events from the input stream, so you end up with all time events.

it was done this way so view can share the same time event among 
many faces, internally.

ok, I see.

It took me quite a while to figure out what I called "Time event 
madness"  ;-)

ok, the "do event" thing? when do I apply that?

that managed within the do-event of wake-events.


the fact that  detect is called, means do event was called.  whenever 
a detect returns false, it consumes the event and subfaces do not 
get their events (even time IIRC).

sorry...  "that managed within the do-event of wake-events"  should 
read

that's managed within view's port wake-event

IIRC the corrected time event is kept by engage, not detect.

exactly.