AltME groups: search

From the earlier soundex discussion. There's something else called 
Edit Distance, which is more directed towards spelling errors:

http://en.wikipedia.org/wiki/Edit_distance

E.g., with some older scripts, I used 'panel, for grouping buttons, 
as it allowed me for kind of "sub-layout" (reset coordinates). My 
typical screen will feature "menu buttons" (as I don't want to use 
menu, as none is standard in VID yet and choise is ugly - both in 
look and in behavior), grid, and I want "Add, Edit, Delete" buttons 
(probably on the right side of grid, alligned to top of grid vertically 
etc.

because ctx-text/edit-text uses /data, not /text.
not updated because of error.
                if flag-face? face return [
                    if flag-face? face hide swap-text 

                    if flag-face? face tabbed [focus next-field face] 
                    action face face/data 
                    exit
                ]

Its now in the beta-sdk, dont know how public that is. and you can 
get the source by "probe ctx-edit" from a fresh console. but without 
comments then.

no, simply put - go to Desktop, right-click any icon or file, choose 
"Edit"

TAB key is handle in ctx-text/edit-text. It is used only in face 
that input text (field & area) and works with the 'tabbed flag.

view/new layout [
	the-field: field feel [

		;;;; 
		engage: func [face act event][
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]
				key [
					edit-text face event get in face 'action
				]
			]
		]
		;;;;

	]
	new-field: field
]
focus the-field
do-events

Oh no! We get an error message! "edit-text has no value".
Where is EDIT-TEXT ? It is not defined in the global context.
If you go looking in the system you will eventually find it here:

	CTX-EDIT/EDIT-TEXT


What happened ? The original EDIT-TEXT word, as found in the FIELD/FEEL, 
is bound to CTX-EDIT 

(it's not found in the global context, open a new console and try 
it), but we only bound our new EDIT-TEXT 
word to a new function context (ie. our ENGAGE).


So how do we keep the original bindings of a function, when making 
a copy of it ?
SECOND gives you the body of a function.

	second get in svv/vid-styles/field/feel 'engage


We should COPY that, which keeps the bindings, then modify that copy. 
*Then* we can create the function:

	; copy the engage function body
	body: copy/deep second get in svv/vid-styles/field/feel 'engage

	; <-- modify the body here

	; make the new function
	engage: func [face act event] body

Let's test that to see which keys we want:

view/new layout [
	the-field: field feel [

		use [body at-key-block key-block][

			; copy the engage function body

   body: copy/deep second get in svv/vid-styles/field/feel 'engage


   ; modify the copy to move the block with the EDIT-TEXT word in it
			; to a new IF then-block
			at-key-block: next find select body [switch act] [key]
			key-block: at-key-block/1

   change/only at-key-block compose/only [probe event/key if true (key-block)]

			; make the new function
			engage: func [face act event] body

		]

	]
]
focus the-field
do-events

view/new layout [
	the-field: field feel [

		use [body at-key-block key-block][

			; copy the engage function body

   body: copy/deep second get in svv/vid-styles/field/feel 'engage


   ; modify the copy to move the block with the EDIT-TEXT word in it
			; to a new IF then-block
			at-key-block: next find select body [switch act] [key]
			key-block: at-key-block/1
			change/only at-key-block compose/only [
				if find "-0123456789.^H^-" event/key (key-block)
			]

			; make the new function
			engage: func [face act event] body

		]

	]
	new-field: field
]
focus the-field
do-events

view/new layout [
	the-field: field feel [
		engage: func [face act event] bind bind [
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]
				key [
					edit-text face event get in face 'action
				]
			]
		] in ctx-text 'self in system/view 'self 
	]
	new-field: field
]
focus the-field
do-events

Say, you wanted to edit in situ text that was running along a curve, 
spline.

I thought of this little idea regarding the editor: Currently, it's 
depending on running a script from file, if you want to test something. 
But I was wondering if it were possible to edit data directly with 
it and just store it in memory?


Sometimes I like to debug a function without having to save it to 
a file and then run a program stored in a different file to run the 
test, e.g. Ctrl-E is useless.


It would be nice to directly in the editor, create a big function, 
say from a paste and do a few edits, press Ctrl-<something> and have 
that evaluated directly. Then you could quit the editor and use the 
function directly in the console without having to save any files.


Also if you want to re-edit the function, type in something similar 
to:


editor 'my-big-function and the editor would pop up with the function 
source and the word its bound to.

ok, it seems to be possible with text, using the first option, but 
not state:

f: "REBOL"

view layout [field with [text: f]] ; displays field with "REBOL" 
in it. If I edit the field, the contents of f is changed

g: true

view layout [toggle with [data: state: g]] ; displays a toggle that 
is set true. If I click it to false, the contents of g is _not_ changed

hmm... how would I properly patch ctx-text's edit-text function?

It seems that I loose bindings on that function if I:

set in ctx-text 'edit-text func [newfunc]

edit-text binding : IIRC you have to bind it to ctx-text and maybe 
system/view too.


set in ctx-text 'edit-text func [args] bind bind [newfunc] ctx-text 
system/view
(or something of this kind)

Working on the editor, I think the bar at the bottom works well http://www.geocities.com/kealist/edit.JPG

btw - lock-lst should be preserved for real locking, I would maybe 
introduce - no-edit, or no-select flags ... just a naming convention 
...

and the header is HDR, list is LST, edit is EDT

but I can tell you what our 300 users are used to, working with 3 
grids we introduced within last 10 years, what they valued most - 


- column resizing was not an issue at all - proper grid can calculate 
size to set it automatically - we had two modes, auto column-width 
adjust, or static, set in config

- drag and drop was rarely used for columns. You can do it othe way 
around - let users to choose which columns they want to see, in what 
order. Let them save the config!!! Without it, forget about your 
grid being powerfull - what ppl are looking for is comfortable view 
of their data. Each person is used to slightly different view

- horizontal scrolling is a must. How cbut I can tell you what our 
300 users are used to, working with 3 grids we introduced within 
last 10 years, what they valued most - 


- column resizing was not an issue at all - proper grid can calculate 
size to set it automatically - we had two modes, auto column-width 
adjust, or static, set in config

- drag and drop was rarely used for columns. You can do it othe way 
around - let users to choose which columns they want to see, in what 
order. Let them save the config!!! Without it, forget about your 
grid being powerfull - what ppl are looking for is comfortable view 
of their data. Each person is used to slightly different view

- horizontal scrolling is a must. How cbut I can tell you what our 
300 users are used to, working with 3 grids we introduced within 
last 10 years, what they valued most - 


- column resizing was not an issue at all - proper grid can calculate 
size to set it automatically - we had two modes, auto column-width 
adjust, or static, set in config

- drag and drop was rarely used for columns. You can do it othe way 
around - let users to choose which columns they want to see, in what 
order. Let them save the config!!! Without it, forget about your 
grid being powerfull - what ppl are looking for is comfortable view 
of their data. Each person is used to slightly different view

- horizontal scrolling is a must. How cbut I can tell you what our 
300 users are used to, working with 3 grids we introduced within 
last 10 years, what they valued most - 


- column resizing was not an issue at all - proper grid can calculate 
size to set it automatically - we had two modes, auto column-width 
adjust, or static, set in config

- drag and drop was rarely used for columns. You can do it othe way 
around - let users to choose which columns they want to see, in what 
order. Let them save the config!!! Without it, forget about your 
grid being powerfull - what ppl are looking for is comfortable view 
of their data. Each person is used to slightly different view

- horizontal scrolling is a must. How cbut I can tell you what our 
300 users are used to, working with 3 grids we introduced within 
last 10 years, what they valued most - 


- column resizing was not an issue at all - proper grid can calculate 
size to set it automatically - we had two modes, auto column-width 
adjust, or static, set in config

- drag and drop was rarely used for columns. You can do it othe way 
around - let users to choose which columns they want to see, in what 
order. Let them save the config!!! Without it, forget about your 
grid being powerfull - what ppl are looking for is comfortable view 
of their data. Each person is used to slightly different view

- horizontal scrolling is a must. It is so basic feature, I wonder 
why noone is requesting it? grids based upon list show its main flaw 
- non ability to scroll horizontally. Real life apps do consist of 
more fields usually then you can fit into your screen ;-)

- sometimes users requested split-view, so that few left columns 
got locked and did not scroll horizontally ....

- proper keyboard handling is a must - enter=edit, ins=insert record, 
del=delete record, move by arrows, pgdn, pgup, end home, ctrl plus 
pgdn, pgup, home, end, left, righ ....

0.0.21 of LIST-VIEW uploaded.

Changes:

      Fix: Fixed an instance where LIST-VIEW would crash with empty OUT-COLS
      New: FONTS block to set font objects for each column

      Fix: Got rid of the grey color bar at the bottom of the list view,

        when the list height didn't add up to the rows. Thereby, you no longer
        need to set COLORS/4 manually.
      Fix: Background color in COLORS was not used

      Fix: When using ROW-FACE, FIT = FALSE and the columns weren't filling
        out the header, the last text field would be darkened.

      Fix: Sometimes when HDR-COLS was not defined, LIST-VIEW would crash

      New: SHOW-EDIT now allows to select which column to focus on

    Main file is available at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.r
    Demo and testcases available at:
    http://www.hmkdesign.dk/rebol/list-view/list-demo.r
    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view/list-view.html

yeah, however there might be a slight confusion: Currently the -HERE 
functions take in account filtering and sorting, so that you always 
edit or retrieve the right row regardless of these settings. the 
other functions get and put directly in DATA. The behaviour would 
either need to change or I'd have to add another refinement

I think the 'textinfo function is used for that (used in ctx-text/text-edit). 
But we have no infos on how to use it and what it does exactly.

Did anyone try to patch the behaviour of area? Especially I'd like 
to have:
- autoindent

- doubleclick on words in the area to do something interesting - 
e.g. look up in dictionary, use like a wiki word, ...
- maybe add additional shortcut keys.


I've tried to patch ctx-text/edit-text, but only was able to get 
no change at all, or crashes. Seems to be a bind problem:
ctx-text/edit-text: func[][] ;no change

ctx-text/edit-text: func[] bind [] in ctx-text 'edit-text ; unknown 
word ...

Can I lock FIELD ? (something like field/edit?: no)

And the ability to edit previous messages to correct errors.

You need quotes around the association, like this: "%1". Edit the 
file type in the Folder Options control panel.

Ok, point me to the word PARSE, on a wiki, where I can edit the page 
about it, or add my two cents, it is very possible I'm just blind 
here...

A) Those pages are wikified. I guess it's a matter of getting access 
to edit them.

Yes. But needed is only the line in rebgui-edit.r

using the original files from rebgui, I need to only make one change 
in rebgui-edit.r ?

Yes, another change in edit too, the
  0x2 + ;? heuristic patch

There where to lines outcommented in %rebgui-edit.r . keeps caret 
visible now. (do not know if that has sideeffects.)

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

shadwolf
	tabpanel with scrollable header - being added to 0.3.8
	menu - see note below
	listview - being added to 0.3.8

 treeview – data structure should be simple & consistent with other 
 widgets ... sub-blocks are the obvious way to go but I'll leave the 
 implementation choices to you ;)

Menu Widget


I am of the opinion that a menu widget is more trouble that it is 
worth as:


1) Its use is being discouraged in modern UI design (toolbars have 
made them obsolete to a great extent) - they feel just so Win95 these 
days

2) Mac OS X does not use them at all (at least at the application 
window level)

3) A fully-fledged menu widget is practically a UI in its own right 
with menu entries having icons, toggles, key shortcuts and various 
other mini widgets

4) The underlying REBOL popup system needs fixing first (this also 
impacts the edit-list, drop-list and context-menu widgets)

5) It's just too complex to meet the definition of a simple RebGUI 
building block widget - our time is better spent on other widgets 
that are required

6) How many users clamour for menus these days? Most folks I've met 
prefer pressing a single button / icon and positively detest multi-level 
menu selection

All my opinion, so feel free to disagree.

we discussed this point  at the treview begining  ...  we have  [[ 
widgets desc ] [  datas to apply to widgets ]] this struct allows 
dynamic datas changes and sortings with low cpu use. treeeview is 
over  code is tiny and all is there to add more dynamic widgets  
but as  we  want to make a grid widget i don't see the meaning of 
adding to treeview the capability to get edit fields  -> note: actual 
fields can be turned as editable on a certain  key + mouse shortcut 
instead of have a special editable widget. Last source are on  http://www.rebolfrance.info/articles/regui-cooking-widgs

BTW is this edit-bug with downkey fixed by Ashley?

How's this for focus / unfocus trigger logic?

1. Add two user-definable action handlers to ctx-rebgui

	app-focus-action: func [face] [true]
	app-unfocus-action: func [face] [true]

2.Modify the ctx-rebgui/edit focus and unfocus functions:

	unfocus: has [face][
		if face: view*/focal-face [
			unless face/unfocus-action face [return false]
		] 
	...

	focus: func [
		"Focuses key events on a specific face."
		face [object!]
	][
		unless unfocus [return]
		if face/show? [
			unless face/focus-action face [return false]
	...

3. Extend the standard rebface definition

4. Add the following to the layout function:


 focus-action: either attribute-focus-action [make function! [face 
 /local var] attribute-focus-action] [:app-focus-action]

 unfocus-action: either attribute-unfocus-action [make function! [face 
 /local var] attribute-unfocus-action] [:app-unfocus-action]

which would then let us write code like:


 ctx-rebgui/app-focus-action: func [face] [face/text: form random 
 1000]

	display "" [
		field
		field focus [face/text: form now/time/precise]
		field
	]


The logic is simple: "Execute the default focus / unfocus functions 
(which in turn default to true) *unless* a focus / unfocus function 
has been provided for the face. When a focus / unfocus event is called 
execute the assigned handler function *first* and only proceed if 
it returns true."

Does this meet the design requirement?

too many bugs at first try to bother to test it further


1) I have clearly indicated this is prototype functionality - constructive 
feedback on the design direction is most welcome

2) The only bug you have indicated is in the on-unfocus action of 
the last field - presumably you have verified that app-level on-focus 
and on-unfocus works (the 3 fields in the group-box) and that on-focus 
(the random number field) also works


LED's - these were originally coloured Red, Green and empty but a 
few people pointed out that these colors are not color-blind friendly. 
One option is to revert to the original color scheme but have the 
LEDs also change shape (red octogon, green circle, etc).


Area - functionality has been improved, not fixed. I'll reopen 48 
(not tested adequately) ... but the whole edit / feel thing needs 
a minor overhaul prior to 0.4.0 (some of the problems relate to View 
itself and these need to be isolated and RAMBO'ed).

hmm, what is the problem with slider? would we have to have something 
like hook to edit function and by each keypress to examine if we 
should redraw sliders? sounds complicated and would be slow probably?

IIRC there is some automatic in rebgui. but that automatic changes 
the text-offset back when the edit-function changes it.

RebGUI goes Beta! With the fixing of some long running area / scroll 
/ slider bugs I've finally reached a stable enough release candidate 
for 0.4.0 Beta; so, from a REBOL/View console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r


Also note that the demo directory includes a nifty new pie-chart 
widget demo (thanks Robert).


I've also separated the 0.3.x and 0.4.x issues into separate sections: 
http://www.dobeash.com/it/rebgui/issues.html#section-2.3

Changes in this release include:


 Scrolling fixed (all area scroll / slider problems should be fixed, 
 and a couple of minor field scrolling issues were also fixed)

 set-locale function to dynamically change locale files / dictionaries
	pie-chart widget added

 slider width reduced by 1/5 for area, table, text-list, drop-list, 
 edit-list (looks better)

 table column arrows made smaller and darkened, plus right-most arrow 
 moved to table boundary (more space for column heading text)


and an important one from 0.3.9 that I omitted to mention last release:


 drop-list / edit-list now size to the smaller of number of items 
 or available space in the bounding parent face (so no more lists 
 that disappear off the edge of a face / window)

Enjoy!

I added them back in 0.3.2. Note that case does not matter: #"a" 
will match both "a" and "A".


keycodes were a part of VID, which the source of 'display seems to 
use

 ... correct on the first count, but keycodes in VID are implemented 
 via the global events system which is not used in RebGUI (for those 
 who are interested and have the SDK sources; have a look at %view-vid.r 
 - Carl's comments make interesting reading).


RebGUI uses a much simpler (and dare I say more efficient) approach 
whereby the layout function (%rebgui-layout.r) collects keycode / 
face pairs and places them in a keycodes block at the window level 
(%rebgui-display.r). These keycodes are used by the 'process-keystroke 
function in %rebgui-edit.r. All this is very different from the way 
in which VID does this.

ESC can be fixed by changing the last few lines of 'process-keystroke 
(in %rebgui-edit.r) to read as follows:

;			#"^[" [
;				;	ESC
;				hide-popup
;			]
		][
			either all [
				event/key = #"^["
				find view*/pop-list view*/pop-face
			][
				hide-popup
			][
				;	if key is assigned to an action do it
				if any [
					not view*/focal-face
					find [button] view*/focal-face/type
				][
					if f: select face/keycodes event/key [f/action f exit]
				]
			]
		]


Only the last of multiple keystrokes provided is used; but note that 
SPC is already mapped to button (so specifying #"^M" would give it 
two mappings ... a keystroke mapping and it's base "SPC activated 
on focus" default).

Hopefully, one day one will be able to use it for e.g. resource planning 
systems. Use left and right mouse buttons to edit the periods and 
the right mouse button to scroll the plan around. The bird-view in 
the widget's top left edge isn't editable in the sense that it would 
yet allow scrolling, but that's it's intended use, of course.

Here is a bug report:

** Script Error: Expected one of: pair! - not: none!
** Where: edit-text
** Near: margin: face-size - caret
either

The first step to getting the collaborative documentation up is to 
migrate the widget specific documentation across; and this gives 
us the opportunity to reformat and expand upon the content. But what 
template to use? If you have an opinion on this then cruise along 
to http://trac.geekisp.com/rebgui/wiki/WidgetList#areaand click 
"Edit this page" to play around with the content and formating of 
this single entry (area). Once we are happy with the format I'll 
use it as a template to bring across all the other widget descriptions.

this is a temporary "fix" for line 549 in rebgui-edit.r

if none? caret: caret-to-offset face view*/caret [ return ]

I put up some preliminary changes to the modal popup handling for 
RebGUI. By manually replacing the original files (but keep them in 
a safe place!) with


 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-widgets.r

 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-dialog.r


you should be able to try them. You'll notice a different and more 
common behaviour of drop- and edit-lists. For the existing styles 
as can be found in the tour script, I haven't experienced unexpected 
results so far. But I'm curious to hear if incompatibilities arise 
in more complex applications that need to be addressed.

line-list is the culprit. Replace the 'show-text and 'clear-text 
functions in %rebgui.r with the following:

show-text: make function! [
	"Sets a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/focus
][
	face/line-list: none
	insert clear face/text form text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	either focus [ctx-rebgui/edit/focus face] [show face]
]

clear-text: make function! [
	"Clears a widget's text attribute."
	face [object!]
	/no-show "Don't show"
	/focus
][
	face/line-list: none
	clear face/text

 all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
 0]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

Graham, this patch to the area/pane (slider) action makes things 
better:

				action:	make function! [face /local pos new] [

     ;	don't alter scroll if the last function to touch it was edit-text!!!
					unless parent-face/key-scroll? [

      parent-face/para/scroll/y: negate parent-face/text-y - parent-face/size/y 
      + 3 * data

						if system/view/caret [
							system/view/caret: 
								offset-to-caret parent-face 
									new: min max 
									(pos: caret-to-offset parent-face system/view/caret)

         0x0 ; <-- should add height of one line of text, to keep caret fully 
         visible

         parent-face/size - (face/size * 1x0) ; <- should subtract height 
         of one line of text
						

       ;print [parent-face/size pos new parent-face/para/scroll/y index? 
       system/view/caret]
						]

						show parent-face
					]
					parent-face/key-scroll?: false
				]


It also needs this patch to work correctly, near the top of rebgui-widgets.r:


 ; Unfortunately, offset-to-caret returns end of the string when offset 
 is between two lines, 

 ; which is only possible when indent/y > 0. This ought to be submitted 
 to rambo as a rebol/view bug.
	; I would not use indent until it is fixed.

 ; offset-to-caret needs to work correctly to allow the new area widget 
 functionality of keeping
	; the caret visible when scrolling. -Anton


 ;default-para-wrap: make default-para [origin: 2x0 indent: 0x2 wrap?: 
 true]

 default-para-wrap: make default-para [origin: 2x0 indent: 0x0 wrap?: 
 true]

Well, the event arrives first in the window feel, so look in there:
>> win: display "" [] ; now press escape
>> probe win/feel
make object! [
    redraw: none
    detect: func [face event][
        switch event/type [
            key [edit/process-keystroke face event]
            move [mouse-offset: event/offset] ...

hence
>> probe get in ctx-rebgui/edit 'process-keystroke

Enhancement request posted to trac: there should be a setting to 
switch the drop down and edit lists to popup rather than drop down 
if there is no space below the widget.

Ideally, and this is similiar to what you stated above, drop/edit 
lists that can't otherwise fit their contents by drop-down should 
then drop-up if the space above the widget is greater than the space 
below. This should be the default behaviour (i.e. display as many 
lines as possible, with a preference for 'below').

The 'edit-text func (in %rebgui-edit.r) traps ESC. Comment out the 
show-focus and it works. /dialog "works" as ESC is trapped at the 
window level and does a hide-popup.

Hmm. I tried out commenting out the ESC mapping in rebgui-edit.r 
without much luck.

** Script Error: Cannot use path on none! value
** Where: edit-text

** Near: if caret/y < (edge/size/y + para/origin/y + para/indent/y) 
[scroll/y: round/to scroll/y - caret/y sizes/
font-height]

;These two work:

display "" [f: field "hello" button "clear" [clear f/text system/view/caret: 
none show f]] do-events

display "" [f: field "hello" button "clear" [clear f/text ctx-rebgui/edit/focus 
f]] do-events

I think either:

- clear-text should check to see if head face/text and head system/view/caret 
are the same. If so, then obviously caret needs adjustment.
or

- edit-text should handle the error, since clear-text is potentially 
not the only function which can leave the caret inconsistent with 
face/text.

in rebgui-edit
	tabbed: [area field edit-list password button]

    tabbed?: make function! [face [object!]] [all [find tabbed face/type 
    face]] ; [che] Returns TRUE if a face itself (not one of it's pane's 
    subfaces) is tabbable (NONE otherwise).

Well, it's referred to a few times in rebgui-edit.r

Yes to the first question and http://www.dobeash.com/RebGUI/edit.html#section-3
to the second ;)

First cut attempt at set- functions to replace various show- functions:

set-attribute: make function! [
	face [object!] "Window dialog face"
	attribute [word!] "Attribute to set"
	value [any-type!]
	/no-show "Don't show"
	/focus
] [
	face/:attribute: case [
		string? value		[
			face/line-list: none

   all [face/type = 'area face/para face/para/scroll: 0x0 face/pane/data: 
   0]
			form value
		]
		series? value		[copy value]
		attribute = 'color	[either word? value [get value] [value]]
		true				[value]
	]
	unless no-show [
		either focus [ctx-rebgui/edit/focus face] [show face]
	]
]

set-attributes: make function! [
	face [object!] "Window dialog face"
	attributes [block!] "Block of attribute/value pairs to set"
	/no-show "Don't show"
] [
	foreach [attribute value] attributes [
		set-attribute/no-show face attribute value
	]
	any [no-show show face]
]

Used like this:

	display "" [
		b: box
		button "A" [set-attribute b 'color red]
		button "B" [set-attributes b [color blue effect arrow]]
		button "Clear" [set-attributes b [color none effect none]]
	]

wiki: Yep, how to edit wiki pages? Didn't find any way to switch 
to edit mode.

How to edit Wiki pages?

 If you have source access you automatically have Wiki edit access. 
 Follow these steps:

	1) http://trac.geekisp.com/rebgui
	2) login
	3) Click WidgetList
	4) Scroll to end of page and click "Edit this page"
	5) Make changes then click "Submit changes"

I have source access but I don't see the "Edit this page" link. The 
last I see is "Download in other formats:"

Hmm, I just logged on as "robert" and I see four buttons above that 
link titled:

	Edit this page
	Attach file
	Delete this version
	Delete page

What OS / Browser are you using?

ATTENTION: rebgui-edit.r was not yet merged. Latest revision doesn't 
include older changes. We will do this ASAP. But rebgui-edit.r is 
required in this version otherwise all other changes done by us might 
not work.



FIXED *rebgui/pad: Now only works for horizontal padding. Padding 
should happen depending on the layout direction left-to-right or 
top-to-down.
	Cyphre: now PAD works according to the AFTER settigns. Example:
	display "Test" [
		after 3
	    field
		pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	]
	Robert,let me know if it works like you wanted.

FIXED *group-box: When setting a new title group-box/text: "new-title" 
the surounding frame needs to be adjusted to the new text-width.

FIXED *drop-tree: When selecting different quick-access buttons directly 
one after the other, the drop-tree shouldn't close

FIXED *drop-tree: Highlighting the pressed quick-access button with 
green, the hovered one as is in orange. To give user visial feedback.

FIXED *general: a way to sepcify "align ['left]" for all further 
widgets to avoide repeation. Idea: Add disaply keywords: left, right, 
center
	Cyphre: added keyword TEXT-ALIGN left/right/center. Example:
	display "Test" [
		text-align right
		after 3
	    t: text 20 "test 1"
	    field "test 2"
	    field "test 3"
	    text-align left
	    field "test 4"
	    field "test 5"
	    field "test 6"
	]

FIXED *drop-list: an option that will show the list layered above 
everything (like the tree list of drop-tree).
	Cyphre: added drop-list/popup-mode: 'inside(default) or 'outside
	note: the same works for drop-tree

FIXED *drop-tree: changing state of the drop-tree (a new entry was 
selected) should only be done if the ACTION code returns TRUE. Otherwise 
the old state is kept, the drop-tree is closed and nothing happens. 
This allows the code to check for some pre-conditions before changing 
the state, and give some feedback to the user. Much like the on-unfocus 
functionality of RebGUI.

FIXED *drop-tree: pressing the quick-access numbers doesn't work 
any more as the drop-tree closes now if the mouse is clicked outside 
the drop-tree

FIXED *table: table/selected returns NONE if the table is empty and 
no record is selected. If there was one recrod selected at any time, 
than table/selected returns [none none <repeated for number of columns>]. 
If not row is selected at any time, table/selected should just return 
NONE.

FIXED *table: If a table is re-used in that the table is reused with 
code like:
	insert clear table/data [...]
	people/redraw

and there was a row selected before, than the internal state is still 
in "row selected" but the new row isn't highlighted. Here internal 
state and GUI don't match.

FIXED *drop-tree: clicking a "+/-" in the tree only open/closes the 
tree without calling the action for the node

FIXED *drop-tree: Re-add whole line selection and hovering functionality 
(so that mouse does not have to be over text)

FIXED *drop-tree: Add an option to get big fast-selction keys aligned 
left-to-right
	Cyphre: added drop-tree/expander-mode: 'big(default) or 'small

FIXED *button: Add an option to disable a button my-button/active: 
true/false, if disabled the button is drawn greyed-out
	Cyphre: usage is my-button/active: true/false show my-button

FIXED *field: Support number datatypes for TEXT so that things like 
field-a/text + field-b/text can be used

 Cyphre: you need to set field/edit-mode: 'numbers to activate this 
 behaviour for field(othervise it works like a normal field)
	2nd implementation uses own styel: number-field

FIXED *radio-group: Add an API that allows to provide a new DATA 
specification block at runtime or a way to alter the text of the 
radio fields at runtime.

 Cyphre: now you can just change the data content and do show on the 
 radio-group like:
		my-radio-group/data: ["item1" "item2" "item3" "item4"]
		show my-radio-group

 Note that it won't react on change of number of items. Just change 
 of texts.

FIXED *radio-group: Add a way to select one radio field at run-time
	added accesor select-item item [integer!] usage:
		my-radio-group/select-item 2
		show my-radio-group

 note: you can get the selected item using my-radio-group/picked, 
 you can get the text of selected item using my-radio-group/selected

FIXED *drop-tree/grey-out: Can it be done in that we only show the 
text in a light grey instead of black? Like Windows does it.
	Cyphre: now the masked text is light grey

FIXED *on-focus / on-unfocus: If FALSE is return from the ACTION 
and the user clicked somewhere on the screen, the focus is still 
in the "field" but no cursor bar is visible

FIXED *drop-list: IIRC in your widgets it was possible to start typing 
and the selection list was filtered. A mandatory feature for the 
drop-list :-))

 Cyphre: added drop-list/editable? flag to enable/disable editing 
 of the drop-list field

 also added drop-list/auto-fill? flag which enables automatic text 
 filterin from the selection list

FIXED *general: add hover tooltip help option to every widget (global 
patch)

 Cyphre: added TOOL-TIP facet to rebface object. If TOOL-TIP is set 
 to string! value a tooltip is shown when mouseover such widget.
	example:
		display "test" [
			button "press me" tool-tip "press this button to continue"
		]

FIXED*drop-list: proivde a much better selection-list opening algorithm 
especially for long lists. Open upward, downward, middle like so 
that as much entries are shown for the given screen space. And an 
option that will show the list layered above everything (like the 
tree list of drop-tree).
	Cyphre:

 -added droplist/lines - can be 'auto (default) or integer! to force 
 number of shown lines in droplist

 -added droplist/droplist-mode - can be 'auto (default) 'upward, 'downward 
 or 'middle to force way how the list is popped up
	you can use various combination of those settings.
FIXED*table: Add an API that allows to select a row at run-time.
	Cyphre: Usage is for example:
		my-table/select-row 5
		show my-table

FIXED*table: Add an API to table that allows to change the columns 
layout at runtime: my-table/reset ["Column 1" left 0.25 "Column2" 
center 0.75]

 Cyphre: I added the functionality byt the API call is my-table/set-columns 
 ["Column 1" left 0.25 "Column2" center 0.75]

FIXED*drop-list: fire action only if selection was made/changed, 
at the moment action fires if clicked on field too

FIXED*general: on-un/focus should be fired if user clicks an other 
widget, not only if carets leaves the widget when TAB is pressed

FIXED*table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

FIXED*table: align header text like data (left, center, right) at 
the moment always left
FIXED*table: TRAC #21

FiXED*TRAC #5 Cyphre: should be fixed but please test it and let 
me know.
FIXED*TRAC #6

when I save the form contents, I just go through the pane and grab 
all the values for the widgets I have viz: radio-groups, and edit-lists.

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?

reset: func [ value /local type ][
    foreach f face/parent-face/pane [
        if f/type = 'group-box [    
            foreach widget f/pane [    
                type: form widget/type
                switch type [
                    "field" [ show-text widget copy "" ]
                    "area" [show-text widget copy "" ]
                    "edit-list" [ show-text widget copy "" ]

                    "radio-group" [ widget/select-item value]                
                ]
            ]    
        ]
    ]
]

rebgui-edit.r: We have merged it and IIRC Cyphre wanted to sync it. 
But I check the repository.

I am having a bug in a program interfacing RebGui to RebDB.

The problem is the following. The behaviour of RebGui'following commands 
having a strange effect on the data managed with RebDB:

my clear-UI function do clears a rebgui interface (simply a set of 
fields) to the RebDB data.

But clearing the 'text fields, it does also clears the values in 
the RebDB database.

At first I was using RebGui clear-text command, and tried the other 
View version just to check.
Both are doing the same thing.

Why clearing the interface fields does clears the data in the database. 
 clear-UI does not ask that.

And no instructions to do that appears in the clear-UI function, 
which is not calling any other function either.

It looks like the 'text field of the fields objects in RebGUI works 
as a direct reference to the database.

And nowhere my code calls by reference. I cannot explain that behaviour, 
nor find any hints in my code as to what causes that behaviour?

Any explanation or ideas on where to look for the cause of that behaviour?


UI-fields: [Funiqueid Fchristen-name Fsurname Fbirth Fname-prefix]
clear-UI: does [
	foreach f UI-fields [
		clear get in (get f) 'text
		show (get F)
	]
	ctx-rebgui/edit/focus (get 'Fchristen-name)
]

One version is in http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=install-edit-tools.r

the idea is to call 'refocus-edit before doing something. then you 
have the caret in both system/view/caret and face/caret. 'unfocus 
saves the caret in caret/face, so if rebol changes the focal-face 
it is keept.

'caret? is used to fetch the caret, as face/caret can still be none.

so use 'refocus-edit instead of 'focus, 'caret? to access the last 
caret.

if you want to change something, refocus and change system/view/caret. 
since the next unfocus will store that inside the face.

Normand, sounds like you want to use the hilight-on-focus block: 
http://www.dobeash.com/RebGUI/edit.html#section-2.3

Here is a litle demo how to access the caret even if on-unfocus is 
called. eg a buton is pressed. or user edits in a find-area and wants 
to search in the edit-area. works by overriding on-unfocus and  saving 
caret in face. unfortunally i was not able to do it the other way 
around. i can restore the face-caret on on-focus, but something unfocusses 
later when i do that by a button. http://polly.rebol.it/test/test/rebgui/../../test/rebgui/edit-area.r.

as in http://polly.rebol.it/test/test/rebgui/../../test/rebgui/edit-area.r

And his error-message said in "into-widget". Thats in %rebgui-edit.r 
, looks for a tabbable face and is recursive.

so the problem lies in rebgui-edit.r

Ingo .. check this as in http://polly.rebol.it/test/test/rebgui/../../test/rebgui/edit-area.r

It does not solve my problem, though:

edit-area keeps the current focus, while unfocused (to access it 
from the button)

I want the button click to focus on the area (at the new position), 
but at mouse release, the focus switches back to the button.

** Script Error: caret-to-offset expected offset argument of type: 
any-string
** Where: edit-text
** Near: caret: caret-to-offset face view*/caret attempt

Here is the code segment:

do show-cc: make function! [] [
display "CRITICAL CHAIN To-Do List Maker Version 1.0.0" [

    ;banner "0:00:00" rate 1 effect [gradient 0x1 0.0.150 0.0.50] 115x24

    ;feel  [engage: func [face act evt] [face/text: copy to-string round 
    (session-time + (difference now/precise time-start)) show face]]
    tab-panel #HW data [
        "Projects" [
            label "Project Name:" project-name: field  144x5

            label "Priority:" priority: drop-list 30 #W "1" data ["1" "2" "3" 
            "4" "5" "6" "7" "8" "9" "10"] 10x5
            return

            label "Objectives:" label "                                      
                                                                             
                                        Exchange Rate" exchange-rate: field 20x5
            return
            area 200x50
            return
            label "Deliverables:" 
            return
            area 200x50
            return
            button "Save" [show-text ex-status "Saved"]
            button "Add" [show-text ex-status "Edit"]
            return
        ]
        "Tasks" [
            ;(print [form project-name/text])

            ;label "Project:" display (form project-name/text) 80x5 ;[show-color 
            ex-dr1op-list to word! face/text]

            label "Project:" t-project-name: text (form project-name/text) 80x5
            ;ex-drop-list: box 20x20 black
            label "Task Name:" t-name: field 79x5
            return
            label "Description:" 
            return
            t-description: area 200x50
            return

            label "Vender/Work Place:" t-vw-place: drop-list "Black" data ["Grand 
            Hardware" "Mega Mall" "Pasar Lima"] 64x5

            label "Resources Needed:" t-resource: drop-list data ["Bus to Manado" 
            "Louis A. Turk" "Caleb Turk" "Samuel Turk" "Compaq SR1520NX"] 64x5
            return

            label "Total Hours Required:" t-hours: drop-list data [0.2 0.4 0.6 
            0.8 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 
            15.0] 14x5
            label "Cost:" t-cost: field
            return
            return
            button "Save"
        ]

Ok, here it is: 


rebol [
    title: "CRITICAL CHAIN To-Do List Maker"
    owner: "Louis A. Turk"
    rebol: none
]
either exists? %session-time.txt [   ;for digital timer
    session-time: to-time read %session-time.txt
][
    session-time: 0:00:00.000
    write %session-time.txt session-time
]
time-start: now/precise
do %rebgui.r
;WHAT IS rebgui-ctx.r and where do I get it?????????????
unless value? 'ctx-rebgui [
	either exists? %rebgui-ctx.r [do %rebgui-ctx.r] [do %rebgui.r]
]
set-colors
tab-size: 120x55
fonts: reduce [font-sans-serif font-fixed font-serif "verdana"]

if exists? %project-list.txt [project-list: read %project-list.txt][write 
%project-list.txt [] project-list: []]

do show-cc: make function! [] [
display "CRITICAL CHAIN To-Do List Maker Version 1.0.0" [

    ;HOW CAN THE FOLLOWING TWO LINES BE CONVERTED TO WORK WITH RebGUI????????

    ;banner "0:00:00" rate 1 effect [gradient 0x1 0.0.150 0.0.50] 115x24

    ;feel  [engage: func [face act evt] [face/text: copy to-string round 
    (session-time + (difference now/precise time-start)) show face]]
    tab-panel #HW data [
        "Projects" [
            label "Project Name:" project-name: field  144x5

            label "Priority:" priority: drop-list 30 #W "1" data ["1" "2" "3" 
            "4" "5" "6" "7" "8" "9" "10"] 10x5
            return

            label "Objectives:" label "                                      
                                                                             
                                        Exchange Rate" exchange-rate: field 20x5
            return
            area 200x50
            return
            label "Deliverables:" 
            return
            area 200x50
            return
            button "Save" [show-text ex-status "Saved"]
            button "Add" [show-text ex-status "Edit"]
            return
        ]
        "Tasks" [

            ;WHY DOES THE FOLLOWING LINE ALWAYS DISPLAY A BLANK STRING?????????

            label "Project:" t-project-name: text (either <> "" project-name/text 
            [(form project-name/text)]["ERROR: Project NAME field is empty."]) 
            80x5
            label "Task Name:" t-name: field 79x5
            return
            label "Description:" 
            return
            t-description: area 200x50
            return

            label "Vender/Work Place:" t-vw-place: drop-list "Mega Mall" data 
            ["Grand Hardware" "Mega Mall" "Pasar Lima"] 63x5

            label "Resources Needed:" t-resource: drop-list "Louis A. Turk" data 
            ["Bus to Manado" "Louis A. Turk" "Caleb Turk" "Samuel Turk" "Compaq 
            SR1520NX"] 63x5
            return

            label "Total Hours Required:" t-hours: drop-list data [0.2 0.4 0.6 
            0.8 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 
            15.0] 14x5
            label "Cost:" t-cost: field
            return
            return
            button "Save" []
        ]
        "Venders/Work Places" [
            label "Vender/Work Place Name:" vw-place: field 152x5
            return
            label "Street Address:" vw-street: field 171x5
            return
            label "City:" vw-city: field 103x5 
            label "State" vw-state: field 38x5 
            label "Zip:" vw-zip: field 23x5
            return
            label "Phone 1:" vw-phone1: field 29x5
            label "Phone 2:" vw-phone2: field 29x5
            label "Fax:" vw-fax: field 29x5
            label "Email:" vw-email: field 48x5
            return
            label "Contacts: " vw-contacts: field 181
            return
            label "Notes:" 
            return
            vw-notes: area 200x50
            return
            button "Save" []
        ]
        "Resources" [
            label "Name:" r-name: field 100x5
            return
            label "Cost:" r-cost: field 30x5 

            label "per" r-label: drop-list data ["Hour" "Day" "Week" "Month" 
            "Year"]
            return []
        ]
        "Make Lists/Charts" [
        ]
        "How To" [
        ]
        "Help" [
        ]
    ]
]
] ;end show-cc
do-events

Download and install a dictionary file: http://www.dobeash.com/RebGUI/edit.html#section-4.2

- display now returns face

 - clear-widget uses radio-group/select-item and table/text-list select-row
 - table/rows attribute added to complement table/cols
 - text-list/rows attribute added
 - get-input and set-input funcs added


These later functions allow you to easily get and put values into 
a display or tab-panel, even one containing nested grouping widgets 
such as 'group-box or 'tab-panel. Handles the following input widgets: 
area check check-group drop-list edit-list field group-box password 
radio-group slider tab-panel table text-list.


The /type refinement of get-input is usefull in design/debug mode 
to get a formatted list of widget type/value pairs.

Example code to demonstrate the use of these two functions.

d: display "Test" [
	after 3
	area "area"
	check true
	check-group data ["check" true]
	drop-list data ["drop-list"]
	edit-list data ["edit-list"]
	field "field"
	group-box "group-box" data [
		field "field"
	]
	password "password"
	radio-group data [1 "radio-group"]
	slider data .5
	tab-panel data ["A" [field "Tab-panel"] "B" []]
	table options ["col" left 1.0] data ["row1" "row2"]
	text-list data ["line1" "line2"]
	button [a: get-input d b: get-input/type d halt]
	button [

  put-input d ["Text" true [false] "A" "B" "text" ["xx"] "" 1 1 ["Bob"] 
  [1] [2]]
		show d
	]
]

personalgb: group-box "Personal" 77x35 data [  
    label "AA:" ethnicfld: edit-list 50 "Caucasian" 
data [

re: area hilight. Refer rebgui-edit.r

	;added AREA too according to Robert's request -Cyphre
	hilight-on-focus: [area edit-list field spinner]

 caret-on-focus: [area drop-list edit-list field grid password spinner]
	action-on-enter: [drop-list edit-list field password spinner]


All of these can be modified at runtime by reference to ctx-rebgui/edit/<block>/<word> 
... the bigger question is what constitutes a reasonable set of default 
values.


re: radio-group. Robert's changes forced labels to be strings. I'm 
pretty comfortable with this change as label expects a string argument 
and a radio-group is a collection of labels. On the other hand, the 
reason I changed drop-list (to form all values) is that it is not 
reasonable to expect an arbitrary list of values to all be strings 
(e.g. a list of postcodes), and/or to expect the developer to maintain 
their string state. I'm open to counter arguments on this one though.

I've added this to rebgui-edit.r feel -> engage -> switch

				alt-down [
					if face/type = 'area [
						face/action face
					]
				]

to allow me to bring up a context menu on the area widget.

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

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

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.

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

Causes? So far you've mentioned three:

	Clicking too fast/repeatedly in a field
	Sporadic area errors
	Tab-panel with focus in multiple panels

All these point back to the edit object.

in 'edit-text .. I have a large attempt block from		caret: caret-to-offset 
face view*/caret to show-face

I've just noticed something odd with tabbing inside a tab-panel. 
It tabs through all widgets on every pane!? I need to look at Cyphre's 
edit (cyclic?) changes I think.

American or British? Dictionaries can be found here: http://www.dobeash.com/RebGUI/edit.html#section-4.2