World: r3wp

So, going to have to trap this in the 'current-word function in rebgui-edit.r

Means I have to click twice sometimes into a field, but at least 
it doesn't crash on me anymore.

make object! [
   code: 303
   type: 'script
   id: 'expect-arg
   arg1: 'max
   arg2: 'value1
   arg3: [number! pair! char! money! date! time! tuple! series!]
   near: [view*/caret: offset-to-caret parent-face min max]
   where: 'action
]

Another intermittent area problem ..

Ashley, I'm allowing users to create their templates by loading in 
their own rebgui display code ( I don't have a fancy layout editor 
like you do!).  This works, but I can't tab between the widgets though. 
 Is there some way I can get the focus system to work on user templates?

Should work, how are you loading and "executing" the templates? Do 
you have a small pseudo-code example?

template: copy somearea/text
		template: compose/deep bind template 'wide

		display "title" compose/deep [
			(template)
		]

Sorry for the interruption. Is there a way to link fields in RebGUI? 
I've got an app for volunteer fire departments that needs quite a 
few tabs.  I want certain fields replicated across multiple screens. 
 Right now it is all manual, with code like  set-text i-incharge 
newname  set-text ins-incharge newname etc peppered all over the 
app when I have common fields across screen.

s/screen./screens./

Graham, following code works for me:

	display "A" [
		t: area
		button [display "B" to block! t/text]
	]

so it's not a problem specific to the focus system.

Is there a way to link fields

 Short answer is no, but you can structure your data into objects 
 so multiple widgets refer to the same word or path.

Hmm.  I see it works in your example, but not my working code :(

Ashley; I thought through that, but I'm not sure how that would work.

f1: field
f2: field


How could the f1, f2 widgets refer to the same text?  (Text eventually 
destined for a RebDB database)

Again, sorry for the interruption.

Love your stuff by the way.  Thanks muchly.

btiffin, what I do with common fields is keep them on the same screen, 
and let the tabs only show the different fields

Ashely, I'm using custom fields ( basically text, and label fields 
with different names, but same function as standard text and label 
fields ).  If I use them in your example above, the tabbing fails. 
 So, I guess the tabbing code looks at the widget type before it 
can shift focus to it ?

My next problem is, I want to be able to create a calculation field 
based upon the contents of my custom fields.

For instance, this formula DAS28 = 0.56 * sqrt(tender28) + 0.28 * 
sqrt(swollen28) + 0.70 * ln(ESR) + 0.014 * GH calculates a disease 
activity score in arthritis.

I looked at the nano-sheets but they use 'do which is not going to 
be safe.  Since this is not a Rebgui issue, I'll move this to the 
core group.

re Custom widgets and tabbing. You may want to have a look at the 
following blocks in the edit object:

	tabbed
	hilight-on-focus
	caret-on-focus
	action-on-enter

You can reference these within your init code as follows:

	insert tail ctx-rebgui/edit/tabbed 'my-widget

cool

btiffin, feel free to interrupt, that's what this group is for. ;)

A simple example of sharing the same word is:

	v: "Hello World!"
	display "Test" [
		f1: field v
		f2: field v
	]


but once the display is substantiated then f1/text and f2/text contain 
their own copies of v. Tying them back is a manual process.


If you are copying values between a database and RebGUI "forms" then 
you may want to take a look at the get-input and put-input functions, 
they were added to make forms management easier (it saves you from 
having to assign widgets to words).

This is pretty cool now, I have it working so that a user can assign 
a calculation to a templated field ...

Now to work out this tabbing issue.

this DISTANCE? version looks twice as fast as the one currently distributed:

distance?: make function! [
	"Returns the distance between two points."
    p1 [pair!] "First point"
    p2 [pair!] "Second point"
][
	p1: p1 - p2
	p1: p1 * p1
    square-root p1/x + p1/y
]

thanks ladislav, I'm JUST working on this stuff for liquidator... 
man you fell in just at an appropriate time  :-)

Thanks, adding to next build.

build#51 committed to SVN. Adds a persistent global UI settings system 
with a new request-ui requestor. UI settings are saved in %ui.dat. 
Also modified spinner (replaced two buttons with single left/right 
click button) and slider (allow arrow grouping to be set globally). 
Next build will be a bug fix build (I've hit similar problems to 
Graham with area and drop-list). If anyone wants to create some %ui.dat 
files for WinXP, OSX and Linux (even if the resemblance is only passing), 
feel free to drop me a copy and I'll include them in the next build.

Has the problem with modal requestors raised in Dec been sussed yet?

I vote for listbox key navigation to not scroll under the horizont 
:-)

Yes to the modal requestors problem(s), and I think they are related 
to some of the drop-list issues. Listbox key navigation is far, far 
down my list of priorities.

Ashley, I again would like to send you our enhanced version. We have 
extended the RESIZING to include proportional resizing, enhanced 
the widgets, made a new one graph-widget (for graph layouting) and 
so on.

Ok?

Sure, but manually merging enhancements is a real pain compared to 
SVN development ... hint, hint. ;)

build#52 committed to SVN. Includes following fixes:

	- Info option now prevents tabbing

 - Added action-on-tab block to behaviors (works in same manner as 
 action-on-enter)
	- Fixed modal requestor problem

Graham, have you managed to pin done the field and area problems 
you were having? I haven't been able to reproduce either of them.

If I script switching panels and setting focus to an area field ... 
it often crashes.

build#53 committed to SVN. Button widget rewritten to take full advantage 
of AGG and fix some anomalies (e.g. actions now fire on button up 
instead of button down, replaced 'active facet with options [info], 
hover effect no longer "sticks" when a popup is called from a button, 
etc). And all this in 1/4 of the code! ;)

nice!

Robert, is there a tree widget available yet in your version?

I thought there was a tree widget embedded inside another widget 
of Cyphres

The spinner widget now using alt click .. is that a problem for OSX 
?

This seems to be slightly anomalous behaviour.  When a modal requester 
is present, every other widget works ( in other windows ) except 
the drop/edit list.

Probably not best practise, but I have scattered "attempts" throughout 
the Rebgui code to stop may apps crashing.

My apps

eg. I have this in area.r

						attempt [ ;;GC
						; Keep caret inside the visible part of the area
						view*/caret: offset-to-caret parent-face min max 

       (caret-to-offset parent-face view*/caret)	; get the current position 
       of the caret

       (sizes/font-height * 0x1)					; minimum, plus height of one line 
       of text, to keep caret fully visible

       (parent-face/size - (face/size * 1x0) - (sizes/font-height * 0x1)) 
       ; maximum, subtract height of one line of text

						]

spinner widget now using alt click .. is that a problem for OSX
 Nope, OSX maps that to CTRL-click

The build I'm working on reverts spinner to a more "normal" behavior 
(I've worked out how to get half height arrows)
slightly anomalous behaviour ... modal requester

 The underlying View popup/modal system has some subtle bugs, some 
 of which will hopefully be fixed in R3.
scattered 

attempts" throughout the Rebgui code" ... Odd, I've never needed 
this. Is it only in more recent build(s)? I'd really like to identify 
and fix the underlying cause(s).

In the function 'current-word, in rebgui-edit.r

I have to trap with 

if series? str [ .. ]

In process-keystroke, I have this

					f: either event/shift [
						back-field view*/focal-face
					][
						attempt [ ;;gc
							next-field view*/focal-face
						]
					]

Hmm.  The new version of process-keystroke has a lot more code in 
it.