World: r3wp

for the CHANGES facet, there is the TEXT flag too. It's for changing 
a window title without unview-ing the window. ie (from %analog-clock.r):
l/text: mold now/time 
l/changes: 'text 
show l

how can I refresh a layout while i'm resizing it ?

can I insert a show in it ?

actually when I resize a layout by clicking left mous button and 
pointing to one of it's borders I have an ugly thing

how can I do to insert a refresh action while the border of the layout 
are deplaced

you can do it at 'resize event, but i don't think you can do it during 
the resizing

Vincent I yet do it on resize event completion but it's during the 
completion of the resize event I need to have the refreshing to polish 
the UI eatch time the mouse pointeur is moved ..

event system is stopped when you resize the window: try to do something 
at each clock tick (at 'rate speed,) and you'll see that no event 
is processed while resizing

I know that but there is no matter to plug a little refresh code 
during the resize completion ?

sorry, even busy loop are stopped. no code execution while resizing: 
when you start resizing with mouse, all executed code stops, when 
you finish resizing, code resumes and an event 'resize in generated. 
So no refresh during window resize or movement (white background 
visible, truncated display, and others glitches), but only after.

k thank you :)

well  there is no posibility to refresh within the resize event  
in VID but we can ask carl to add this kind of tricks into VID process

Ashley, is the intent that one develop first in VID, and once finished, 
recode in Rebgui?

Graham, that doesn't make any sense.  Why would you do that?

I looked at the example and the references are hard coded ..

so, if you add another face, you have to change all the references 
by hand if the ordering changes.

So, I presumed that you prototype first in VID and then optimize 
in rebgui

II think that's from a minimalistic POV.  If you're still learning 
View then perhaps you should use VID to prototype and explore your 
styles and then just move the values that you need into a style definition 
for RebGUI, however, if you are a seasoned expert such would not 
be necisarry...

:)

Changing references in a file by hand can be really simple too, Find/Replace. 
;~>

say you have 20 odd faces, and you insert one in the begining .. 
then that's 20 references have to do a find and replace on ...

rebgui seems incompatible with /View < 1.2.10 (crash)

Then you aren't talking about references within the styles but references 
to the faces from outside the top level face, right?

If you're talking about styles then the only way I can see that happening 
is if you are building something like a text-list but then you should 
be using itterated faces which elimates the problem.  If your talking 
about referencing the faces from elsewhere in the code then I disagree 
110% with the idea of not using a word to reference the face, but 
then we're just talking about convention too and you're free to reference 
values pretty much however you like. That's the power of REBOL!  
;~>

Oh, and Ashley, good work BTW! ;~>

yes very good work ;)

can we initiate a contest to create styles (widgets) for RebGUI ?

AShley is one of the few VID artist ;)

one of the first widget that I want to work on is a status bar that 
can encap text, progress and the resize logo

good work Ashley!

- changing the "foreach [style facets] spec" loop in display.r to 
something like "parse spec [any [opt [set varname set-word!] set 
style word! opt [set block block! (...)]]" would allow the use of 
"return" in place of "return none" and let users to define var names 
for faces in definition block.

- found the problem with /View 1.2.1 : i did define 'as-pair as func 
[x y][add 1x0 * x 0x1 * y], and it crashes here, but it works with 
as-pair: func [x y][to-pair reduce [to-integer x to-integer y]]

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

RebGUI 0.1.1 released ( http://www.dobeash.com/files/RebGUI-011.zip
) and View facets documentation updated from feedback ( http://www.dobeash.com/it/rebgui/facets/
).

Anton

 1) VID working with RebGUI ... no reason why not (haven't tried it 
 yet though)
	2) display help cleaned up
	3) Minimum window size ... can be set to 0x0 with /limit

 4) Progress bar using effect ... agree. I want to emulate the WinXP 
 progress bar with image / effects

Graham

 1) Intent ... Ammon & Gregg answered this already; bottom line - 
 whatever folks feel more comfortable with

 2) Positional references were only meant to be for sub-faces of a 
 widget ... documentation corrected
	3) display now accepts set-words as per Vincent's code

Vincent

 1) Changed all occurences of as-pair to to-pair so your prob is fixed 
 (and RebGUI can now run from rebface)

 2) Change 'foreach to 'parse ... done (with the benefits you listed)

Shadwolf

 1) "Ashley is one of the few VID artist" ... thanks, but I defer 
 to Chris in all matters graphical! ;)

Gregg
	1) Agreed. (Need I say more? ;) )

Out of interest, I started rebface (REBOL/SDK) and did several recycles 
before looking at its process size under WinXP. Did the same thing 
again but after do'ing %styles.r and %display.r, and repeated the 
procedure for %view.r (the SDK func that pulls in VID). Results were:

	rebface	3,540 KB
	RebGUI	3,628 KB
	VID		5,224 KB


So I can say that (at this early stage) RebGUI seems to use 88 KB 
while VID uses 1,684!

I guess we will have to see what happens with the use of more complex 
faces

Ashley, I don't mean to undo your work, but perhaps it is easier 
to add a compatibility layer for functions missing from older releases? 
eg.
if not value? 'as-pair [as-pair:  <insert source as-pair here>]

That will shrink your code and user code down a bit.

I'm using the SDK rebview 1.2.10 as my baseline. The only three mezz 
funcs I have had to abandon so far are:


 as-pair		; better off using to-pair reduce [x y] as I'm dealing with 
 integer-based co-ords anyway

 center-face	; was used once in the 'display func and it's inline 
 representation is more efficient

 span?		; used in render-rich-text with a check as per your suggestion 
 (render-rich-text is used from REBOL/VIew more often than not)


It's only the RebGUI code that has to conform to these restrictions; 
user code can use whatever mezz funcs and run under whatever REBOL 
version they want. I used the same design philosophy with RebDB (if 
it runs under SDK/rebbase, it will run anywhere). In the majority 
of cases the extra mezz funcs are more usefull at the user code level 
anyway.

Once official version will came out all actual 1.2.X version will 
be deprecated ...

Agreed. But we have to work within the restrictions of today not 
the promises of tomorrow. ;)

Hum Maybe betting hardly on futur will show the yet hudge possibilities

Ammon, regarding your drop-down style.  Is it possible to also allow 
the field associated with the drop-dow to accept user data?  Such 
as a case where the provided drop-down contents does not contain 
the value the user needs to enter.   Of course it would be useful 
to also store that item into the drop-down for future reference, 
which is easily done dynamically by populating the drop-down with 
any value recorded in that field in the data file.

Hello, Long time no talk. Is there a way to tell the request-file 
to open up in a specific directory?

request-file/file %/c/mozillaFirefox/

Thanks Anton. That makes sense when I see it. I was thinking it had 
to be a file and not just a path. Cool. That will have me a lot of 
clicks. : ^)

Here's a scenario that has me puzzled, not sure if I am doing something 
wrong, or if I ran into a bug

rebol[]


last-sgrp: copy ""		;global used to keep track of last selected button 
in sgrp window

reset-toggles: does [

 t1/state: t2/state: t3/state: t4/state: t5/state: t6/state: t7/state: 
 t8/state: false
]

two-digits: func [num][
	either 10 > num [num: join "0" num][num]
]


get-report-date: function [/delim][report-day day rsd today s e day-diff][
	report-day: 6			; 6 = Saturday, start day of report
	today: now/weekday
	day-diff: report-day - now/weekday

 rsd: now + day-diff		;rsd = report start date		;'difference function 
 used to do date math
	either delim [

  s: join rsd/year ["/" two-digits rsd/month "/" two-digits rsd/day]
	][
		s: join rsd/year [two-digits rsd/month two-digits rsd/day]
	
	]
	e: rsd + 6
	either delim [
		e: join e/year ["/" two-digits e/month "/" two-digits e/day]
	][
		e: join e/year [two-digits e/month two-digits e/day]
	]
	report/text: join s [" - " e]
	show report
]

clear-entry: does [
	probe t1/text probe t2/text probe t3/text probe t4/text
	print "-------"

    clear-fields bx1			;;;;;;;;;;;; Error of disappearing toggle values 
    starts here
	probe t1/text probe t2/text probe t3/text probe t4/text
	print "======="
    ;clear-fields bx2			;;;;;;;;;;;;
    ;create-dt/text: form now
    ;update-dt/text: form now
    unfocus
    show dex
]

new-ticket: does [
    ;store-entry			;stores existing entry
    clear-entry			;clears fields for new entry
    if last-sgrp <> "" [application/text: last-sgrp]
    environment/text: copy "prod"
    show [application environment]
    focus application
]

dex-pane1: layout [
	across
	label "Support Group:"	application: field return
	label "Environment:" 	environment: field return
	label "Report Dates:"	report: field return
	btn "New Ticket" [new-ticket]
	pad 20 btn "Reset Toggles" [reset-toggles]
]

dex-pane2: layout [
	across
	label "Search Criteria:"

 t1: tog "o79" [write clipboard:// join "se sa**/" [last-sgrp: t1/text 
 "ca datp/" get-report-date/delim]]

 t2: tog "p23" [write clipboard:// join "se sa**/" [last-sgrp: t2/text 
 "ca datp/" get-report-date/delim]]

 t3: tog "o88" [write clipboard:// join "se sa**/" [last-sgrp: t3/text 
 "ca datp/" get-report-date/delim]]

 t4: tog "p11" [write clipboard:// join "se sa**/" [last-sgrp: t4/text 
 "ca datp/" get-report-date/delim]]
]

dex: layout[
	bx1: box dex-pane1/size
    bx2: box dex-pane2/size
]

bx1/pane: dex-pane1/pane
bx2/pane: dex-pane2/pane

view dex

Here is the scenario to replicate my problem where Toggle button 
labels are being removed....

1.	Select the 'New Ticket' button
2.	Select the first Toggle button
3.	Select the 'New Ticket' button
4.	Select the second Toggle button
5.	Select the 'New Ticket' button

At this point, the label for the first toggle button disappears.

The problem seems to be with the 'clear-fields' function in the Clear-Entry 
function I created.  Commenting out this line allows the buttons 
keep their label as expected.

>> help clear-fields
USAGE:
    CLEAR-FIELDS panel

DESCRIPTION:
     Clear all text fields faces of a layout.
     CLEAR-FIELDS is a function value.

ARGUMENTS:
     panel -- (Type: object)