World: r3wp

Smaller example works here too.

must be doing something else bad ..

confidential code?

display "Test" [
	group-box "Box1" data [
		field 100 return
		field 100 return 
	]
	do [	
		foreach f face/pane [
			if f/type = 'group-box [
				foreach t f/pane [
					t/text: copy "hello"
				]
			]
		]
	]
] do-events

works fine

not confidential code .. just very long!

maybe i can dig to the important points.

i am sometimes good at probing.

hang on ....

maybe i find the bug.

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?