World: r3wp

fixed :)

Grats :)

helps to talk about these things :)

very true:)

Graham, good tip: Don't save/restore anonymous widgets. If (whyever) 
the order of faces change you are lost. I always use named widgets, 
even it's more to code. But I can move the stuff around without any 
problems. And my widgets have the same name as the database-columns.

can't do ... users are allowed to create the forms

But they could be forced to name the fields?

but they could overwrite globals

they might name a field rebol: field 100

i would take roberts suggestion but use my own naming. eg have a 
/my-name in your fields and compare with that.

Graham, simple fix: Just prefix each field name internally with graham_<field-name-by-user> 
and you are save.

this is an example form http://www.compkarori.com/emr/images/cvs.png

I use the form to create text .. so it is not being saved to any 
database ...

it is being used to create english sentences

I guess I would use named fields though if I had to save and restore 
to database fields

So its stored only short-term and long-term-compatibility is no issue?

yes

mostly for forms I store the form data as a block in the database

because you might have a hundred different forms

and I don't want to save the form definition with the data

Why do you need to populate the form? crash-backups? defaults?

just to view the data

easier to see the data in the form sometimes

but you dont store the data, only as text?

as datatypes

but for the example form .. as text

because I don't need to preserve the granularity that is being captured

Naming is only needed if ou ad/remove fields while there exists valid 
data. But then it is needed.

yeah ..

and then I need to preserve the names of the fields with the data

Robert, how much testing has been done of Cyphre's changes?

I'm using all of them in a big app (100KB at the moment). Mostly 
not problems found. But feel free to report bugs, as we are going 
to fix them.

There might be some quirks here and there but it's nothing critical.

I reported bugs with the radio-group here ..

and in the trac

if full naming is to much effort, maybe you could store the labels 
together with the data. not to find the right field, but to havea 
check to make sure. just in case. could also make datatypes more 
readable. just to make sure that the right femoral artery does not 
change to a left femoral artery just becaue somebody deleted a line.

this is a potential problem :)

We didn't checked against TRAC yet.

perhaps better to create an object and save it like that.

if 'face in the do-block refers to the layout, how to get this inside 
a button action block?

I want button [ unview/only parent-face ]

unview/only face/parent-face

Hi Graham, in my example-2 the the right-most text-lists keep their 
widths, and the lower text-lists keep their height, and the upper 
left text-list is maximized to fill the size of the window.
I would like to have equal sizes for all text-lists.

I am creating templates which I load up and display.  These templates 
contain some variables for label widths etc.  I have to bind the 
template to the variables, but then if I do that, operators such 
as '- have no context.  do I have to redefine '- and '+ etc?

Ingo:


is there a reason, that display opens the windows, but does not start 
do-events?

 ... we can't assume the "first" window automatically needs to start 
 the event loop. Perhaps the display is being assigned to a word and 
 cached for later use? Or the display is done early in the script 
 for lots of subsequent initialization and *then* needs to fire up 
 the event loop. I personally like having to code it explicitly as 
 it then stands out - "We are starting the event loop HERE".

Is it possible to get the window size?
 ... display [button do [ws: face/size]]

Is it possible to set an own resizer function?

 ... No, you'd have to change a lot of code to implement your own.

I would like to have equal sizes for all text-lists.

 The RebGUI resizing model is pretty basic, it supports one resizeable 
 widget in each axis (horizonal and vertical) with any number of offset 
 adjustments (the #XY directives). More advanced schemes (such as 
 proportional or percentage based) are possible, but significantly 
 harder to implement (and require size/state information to be retained).

Graham, I'd thought using () in the template would enable RebGUI 
to evaluate the expressions automatically for you. Do you have a 
small example of what you're trying to do?

Robert: Your rev#21 changes to rebgui-edit.r nuked my rev#19 and 
rev#20 changes ... but the good news is that they collectively constituted 
the following line in the insert-char function:


 unless any [insert? tail? view*/caret newline = first view*/caret] 
 [remove view*/caret]


Should I put that line back in a new rev or do you want to bundle 
that in with any additional changes you are working on?

Ashley, an imperfect example ...

do %rebgui.r


test: {label "This is a label" (width) radio-group data [ "-" "+" 
] return label "Another label" (width - 5)}

go: func [ template [string!] 
	/local width
][
	width: 20
	template: compose bind to-block template 'width
?? template 
	display "testing ..." [
		(template)
	]
]


go test

do-events

it comes a cropper on the "-" ... ** Script Error: - word has no 
context
** Where: go
** Near: width - 5