World: r3wp

It's same as Rebolek's right version

Also it looks that Pekr's version is even more moved to left and 
top

And I can see one important bug - it's not possible to change language 
(CTRL+ALT) in Rebol window.

I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and 
validation too, but get this error when clicking on a button in the 
dialog demo:

** Script error: path win-gob/text is not valid for none! type

** Where: any view either create-dialog request-user do switch applier 
apply if

foreach if do-face if actor all do-style if do-event do-event do-event 
either ap

plier wake-up loop applier wait do-events if view catch either either 
applier do


** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s...

Thanks for posting though Henrik!

validation is not tested with the new styles, so there may be some 
things going wrong. thanks for the report.

It looks like the feature for keeping several draw blocks in the 
same style was removed or changed by accident. this means that the 
validation icons won't work, so I have to find a different way to 
test validation. I want to separate the dialog code from validation 
and then make a proper validation test window, so you can look at 
the code and see how it works.


Furthermore, there is a database extension, I want to test more: 
Parts of validation (the scoping part) was inspired by this one and 
I think it would be good to get this out in the open, as it can be 
extended either to a file database or any SQL database by the community. 
The point of it is to make it very simple to connect the logic of 
a form to a database record and it works a bit differently from setting 
up a regular form.

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!