World: r3wp

several draw blocks in the same style is a must, or I really don't 
know, how you want to support a bit more dynamic styles ....

yes, I'm sure just something was disabled. I built a new version 
today, but it's less stable than the current build, so I'm not going 
to release it.

Tried some latest build today, and the problem with wrong placement 
of caret is gone now ....

It was caused by some difference in window size handling between 
XP and Vista/W7.

Hmm... and Vid handles it already?

probably so, because I did not change executables, so it has to be 
part of r3-gui.r3 ....

Oldes, language change bug is being looked at now

is "changing language" a new feature of w7  ?

this this mean that 25 years late, they actually allow the OS & apps 
to be installed in any language? like every other decent OS out there?

any... should read as... all languages at the same time...

Maxim, keyboard language

ah... well.   so it still sucks.  :-D

this is not much needed feature, imo, but any fix is good :-) We're 
still waiting for R3 GUI to be at least on par with Carl's VID 3.4. 
What's needed in order to experiment with writing own styles?

language switching is MUCH needed feature... I constantly switch 
languages in all of my apps.

I don't have to do that. Windows does that on its own perfectly fine. 
Which doesn't help my blood pressure. :-)

you can already write your own styles.  though I found issues with 
using sub-gobs in your face/gob.   the event and other systems try 
to use them as faces... which is wrong.  

I had to patch various event handling funcs so they ignore gob/data 
= none

Maxim, that would be an important issue to fix as soon as possible.

yes... especially since AFAIK the idea of gobs is to use many sub 
gobs for a single face...

well, actually the faces do contain other faces, in a VID style configuration, 
but it may very well be that event handling is not done correctly.

do styles generally use one bog + one or multiple draw blocks, or 
multiple gobs + one or multiple draw blocks can be used? I remember 
Gab's VID used multiple gobs for one style, no?

I don't explicitely want to use a face within a face...  for graphics, 
I want multiple gobs in a single face... so event detection, which 
starts at the gob, should allow us to have a state where if its user 
data is none, its just ignored from the stand point of the generic 
face handler...  at some point, it will hit the actual parent gob 
which IS the face, and event handling should occur there.


just ignoring the none user data is all event detection rountines 
in the r3gui you posted, did just that. IIRC.

is = in

Pekr, AFAIR, a single gob is used per face. Several gobs were manually 
managed by the style writer in Gabriele's VID3 and was part of why 
styles were harder to write. I don't think, however there is much 
that prevents the style writer from writing a style that uses several 
gobs.

I find it easier to use many gobs for many styles... especially when 
mixing different gob types to form a single face.

well, I found it harder, so this is a relief. :-) but inside a style, 
I think it's possible to freely use any number of gobs.

yep.. as long as the event problems noted above are fixed... is already 
works well  :-)

Maxim, if you have some fixes for R3 GUI, please, share them with 
me.

oh it was mostly hack and slash rambo stye fixes... the most important 
is just adding a sub to any style and trying to make it go thru events... 
its easy ... it crashes until all events flow thru gobs which have 
user data set to none.

subgob

New r3-gui.r3:

http://94.145.78.91/files/r3/gui/r3-gui.r3

My domain seems to be gone. Will have to fix that later...

I will begin working on database reactors soon and will want to review 
it with the community.

database reactors? what is that? I mean - how will it link to particular 
db?

sort of, yes. write a form and add a few keywords and you can add, 
edit and delete records in a db.

interesting ... I can't imagine how it will work. Each of us uses 
different DB, different relations, different aproach to things ....

what would be interesting would be to have the community write a 
simple flat-file database backend for it

Pekr, the reactors link to some functions, which then in turn create 
the specific procedures for adding, editing and deleting in a table 
for a specific database.

I would like to better see more styles, keyboard navigation, editing, 
tabbing, etc. :-)

sounds good, don't forget update ...

this is also just one approach, one strongly advocated for by Robert 
and if done right, it will be quite fast to work with

db-reactors is high priority, so I have to work on it now.

Pekr, tabbing is beign worked on right now

maybe db-*, as for naming convention, as I can imagine e.g. delete 
or update reactor for some non DB related purposes too?

Rebolek - cool then!

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

what is 'skip for the field? Is it for tabbing to ingore the field?

The trick is that a panel acts like a record. You specify the record 
object in OPTIONS. Then any named field, checkbox, slider or whatever 
participates in the record unless the option SKIP is true.

SKIP allowed reading the record, but not writing back changes, such 
as a "last updated" field, which you don't want to write back.

then there are OBTAIN and EMIT reactors, which are siblings to the 
SUBMIT and ACQUIRE reactors.

http://94.145.78.91/files/r3/gui/db-reactors.r3

This shows a simpe skeleton of what it's made of.

The SKIP and RECORD options are scoping, so if you define a panel 
with SKIP, everything inside it is skipped on EMIT.