AltME groups: search

I'm using these hidden widgets to controll the low, high range of 
acceptable values in a widget, and to provide them with database 
field names

ie.form validation and not field validation

so, outcome refers to the database field, and the user has integer 
field for the data, with a low range of  0, and a high range of 28

I guess I could use a custom widget and use options instead

you have to highlight a spinner and type over it

then add spinner to hilight-on-focus and they can just type overtype 
the value directly.

Not at the moment. Should it? And if so, should it let them leave 
the widget without entering a value?

show?: false *should* work, haven't tracked down why not yet. Also, 
if you're going to be placing "hidden" widgets consider using box 
with a 0x0 size. This involved less processing and lets you use the 
data facet without having to "hide" the widget per sa. e.g.

	box 0x0 data "Text"

does what you want.

and also again all the templates

though my changes are getting fewer and fewer as rebgui improves 
:)

Probably not something that will ever be part of the base release, 
but feel free to check it in to SVN and add an entry to WidgetList. 
The pie-chart widget and Robert's chart widget probably fall into 
the same category. I'll eventually figure out a good way of providing 
a base + optional widgets download facility. What I really want is 
a checklist of widgets to download which dynamically builds a tailored 
%rebgui.r ... sort of a "would you like fries with that" type facility.

and can't use the mouse to take the caret elsewhere :(

and I did a show-focus to get to the edit-list

Ashley, View system has broken highlighting and caret positioning 
with center and right aligned text. It's been a problem for a long 
time.

why table and text-list are not hilight on focus too?

Ah, because they don't get keyboard focus like area and field do. 
The fact that they are not tabbable [yet] is a separate issue.

I'm getting a 5 second delay on using the "close" button in the spell 
checker, or on the final "add".  I wonder if it's better to close 
the spell checker window down first and then do the file maintenance.

Checks that face/text is in fact a string and has a length greater 
than one char. We don't really want to spellcheck an empty string 
or one with a single character in it. Why, is it causing a problem?

Button and many other widgets have an 'info option already. Any solution 
to disable a widget dynamically would have to be generic and done 
via functions like:

	set-disable
	set-enable


On a related note, I'm thinking a request-progress function might 
be handy. Would have the following format:

	request-progress 10000 [foreach f read %. [...]]
	request-progress/cancel 10000 [foreach f read %. [...]] [...]


Advantage would be that it is modal and provides useful feedback. 
The /cancel block provides a "cleanup" routine if the window is closed 
the cancel button is pressed. Without the refinement no window close 
button would be present and no cancel button. Useful?

yes, I know about the modal request functions, and I have to write 
my own non-modal ones

Spell

 checking 'a' and 'I', note uppercase only, would be handy.  Then 
 math gets in the way  :)

I'd be 'either or' on that one.  No vote.


Wait, I take that back.  I haven't been in a math class for 25+ years 
now.  :)  I vote yes on one-letter words, IFF those words are a, 
A and I.

write my own non-modal ones
 ... what do you do about drop-list and edit-list then?

if those words are a, A and I
 ... is that an [English] language assumption?

Am I ever glad there are more thorough people in the REBOL community 
than your's truly.  I'll shut up now, and then try and figure out 
how much I weigh in kilograms.  :)

set-disable, set-enable - I welcome it. Some time ago I wrote disable-face, 
enable-face, which simply put transparent face with whatever effect 
block in front of widget you wanted to "disable". It did not block 
the keyboard, but Anton fixed it IIRC, and those two small functions 
are on rebol.org.

Those were handy, but I don't recommend that approach anymore. I 
now recommend that each widget have a "ghosted" flag. Depending on 
whether the flag is set, the widget draws itself differently and 
also responds differently to events.

Like RebDB and the SQLite Driver I want to get it to the point where 
"it just works", and fixes/enhancements are rarely required. Currently 
it does most of what *I* need it to do, so I'm focusing on nailing 
the few remaining bugs and getting the documentation up to scratch 
for a 1.0 release. I'm envisaging a lot of changes once R3 is released 
so this won't happen until after that.

as for R3 - we don't know for sure, but maybe View will not contain 
any significant changes. My opinion is, that VID and desktop should 
be separate packages, and that View should contain only general gfx 
functionality ...

Build #83 Released. For more information see:

	http://www.dobeash.com/RebGUI/release.html#section-8

and:

	http://www.dobeash.com/RebGUI/user-guide.html

Includes changes from builds 73-83, plus new dictionary files.

If you look at the source code for chat.r you'll see a commented 
out show face/pane/1 and show pane/1. Uncommenting either of these 
will fix all display problems for chat, BUT, subsequent widgets will 
not render correctly as the show "eats" subsequent resize events. 
You can see this with the following code:

	display "" [
		after 1
		button "One"
		chat #HW data ["a" none "b" none 1-Mar-2007/10:00:00]
		button "Two"
	]

where button 2 is not drawn correctly.

Build #85 uploaded with above spellcheck changes and an improved 
anagram algorithm (about 10 times faster).

An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'clear
    arg2: 'series
    arg3: [series! port! bitset! none!]
    near: [clear f/text 
        all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0] 
        f/line-list:
    ]
    where: 'clear-text
]

the new table appears

 ... tables aren't new, there're one of the widgets I have yet to 
 code review (although I have made some face-iterator changes which 
 handle row selection and on-click actions).


clear-text is not used by anything in the base distribution. Looks 
like something is doing a 'clear-text without providing a face argument.

Looks like I set it to integer and it displays okay, but then clear-text 
fails

Assigning a non-string value to face/text is not a good practice. 
It just means more work for View (which has to dynamically form the 
value) and might break several things that depend on face/text being 
none! or string!

otoh, it makes less work for users not to have to form dates and 
numbers being displaying them in widgets

and let the accessor do the job

Looking at my code, it's a form that loads the data from a database, 
and then uses a routine to go through all the widgets and set the 
data.  Just need to add a 'form to it.

Well, 1.0 is aproaching, and I am getting feeling it will miss on 
some very important styles. But that is also about how each of us 
is used to code his apps. I would like to know, what are you e.g. 
Graham missing mostly with your rebgui based CRM?

and I would like to be able to set colors on rows of a table.

it is a pity Cyphre is busy. I asked him to adapt grid, and he also 
promissed to extract tree out from drop-tree. But otoh I am glad 
he works on some parts of View for R3 :-)

What I mean is, if I use the chat widget and build a window with 
it, I don't get the distortion.  I do if I use tour.r

Found my table error ... I was bringing up a modal window to delete 
a row, and once I deleted it, I did a unview/only face/parent-face 
on the on the button when I should have done a hide-popup.  This 
completely killed the events system.

spellcheck ... it's certainly something I miss in ALtME!
why e.g. Chat widget appeared?
 Carl asked for it first.


Graham, back to your modal windows and BEER compatibility issues 
... does this still happen with Beta 2? The reason I ask is that 
the initial modal window implementation was poor (in large part to 
get around REBOL/View limitations); but since REBOL/View 1.3 the 
View popup system has been completely rewritten (by Gabriele I think), 
and the RebGUI implementation is now simple and "standard" (in that 
it uses the same functions as VID). It may in fact have fixed the 
issues you were having.

you probably won't believe, but this version of AS-PAIR looks like 
being 20% faster than the current one:

as-pair: func [
    "Combine X and Y values into a pair."
    x [number!] y [number!]
] [
	1x0 * x + y: 0x1 * y
]

stange I would not have thought that 'ADD and + would have any speed 
differences.

yes  :-)  and supports all  :-) very cool

Regarding the action block on a tab panel.  It seems to me that it 
must complete before the panel is displayed.  Can there be an option 
to display the panel first, and then perform the action?

I have an async routine that displays all the chat messages in table 
on a panel.  This triggers in the action field of the panel, but 
even though it is async, it takes a finite time, and so slows down 
the display of the panel.

well, not /insert .. perhaps /ins

set 'set-text make function! [
	"Set and show a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/ins
	/no-show "Don't show"
	/focus
][
	unless string? face/text [exit]
	either all [ ins face/caret ][
		insert skip head face/text face/caret form text
	][	
		insert clear face/text form text
	]
	all [
		face/para
		face/para/scroll: 0x0
		all [face/type = 'area face/pane/data: 0]
	]
	face/line-list: none
	unless no-show [either focus [set-focus face] [show face]]
]

Worthy addition, although I'd call it /caret and the following line 
should suffice:

	insert at face/text face/caret form text


Not that 'at treats values less than 0 as head and values greater 
than length of string as tail.

Something like:

set 'set-text make function! [
	"Set and show a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/caret {insert at cursor position}
	/no-show "Don't show"
	/focus
][
	unless string? face/text [exit]
	insert either all [ caret face/caret ][
			at face/text face/caret 
	][	
		either caret [ tail face/text ][	clear face/text ] 
	] form text
	all [
		face/para
		face/para/scroll: 0x0
		all [face/type = 'area face/pane/data: 0]
	]
	face/line-list: none
	unless no-show [either focus [set-focus face] [show face]]
]

tried setting the widget/data: now/date and doing an 'init

Like the set-text change (and code re-factoring).


Not sure about the alignment question, have an example in VID of 
what you're trying to do?

Calenday quetion is easy:

	cal/date: 1-Feb-2006
	poke cal/options 1 1-Feb-2006
	show cal

data is the currently selected date
options/1 the default date

I had a 


calendar widget1 return widget2 and I wanted widget2 to align with 
the right border of the calendar

so now I have

calendar panel blue data [ widget1 return widget2 ]

Remember how we wrapped current-word and caret handling in attempt 
blocks? Well, I've had plenty of caret errors to track down but not 
a single current-word error. Then I recall you had that problem where 
you set face/text to a non-string value ... could the current-word 
problems you experienced be related to that?

trap and forget ...

I'm trapping and writing these errors out to %rebgui.log, does your 
log file contain any current-word errors? (search for "word trap" 
if there are lots of entries)?

But at least you haven't had a current-word error since installing 
the latest builds. It's just that looking at the current-word function, 
it's only called from one place, and you already have to have focus 
and caret with a valid string before the function is called, i.e. 
I can't see how it *could* fail [now]. I'll probably leave the attempt 
in there for a couple more builds/weeks, but if it traps no errors 
I'll remove it as fixed.

you can click inside f, and type and the caret values does not change

I primarily want to click inside a body of text to place the caret, 
and then push a button to insert a block of text

otherwise text insertion is going to be hit and miss

click inside a body of text to place the caret, and then push a button 
to insert a block of text

 Ah, got it. The solution is simple then. We add a line to set-text 
 (after the string? test) that reads:


 all [view*/caret none? face/caret face/caret: index? view*/caret]

It's inserting at the head of the face and not at the caret after 
clicking on the text in the area

Then run the following:

	display "" [
		f: field
		field
		button [set-text/caret f "X"]
	]


Click in f, type some text, click or arrow to the middle of the text 
and press the button. Text is inserted at caret.

So, running the text above I click into f, type "ab", press the left 
arrow key once and then the button. What I see is an "X" inserted 
between letters "a" and "b" (i.e. "aXb") with the cursor positioned 
between the "a" and "X". Is this what you see? Is this "correct"?

Or do you expect the cursor to be positioned between the letters 
"X" and "b"?

but if you now move the cursor to the head of the text, and click 
button, it still inserts as before.

and this mirrors what happens when you type

I type "ab" ArLeft and press button to get "aX|b"
the ArLeft, ArLeft and press button to get "X|aXb"

Is this what you get?

not me .. and that was a fresh checkout :(

and create-distribution.r

Build#88 uploaded to SVN with major caret/focus fix. This fixes numerous 
problems related to clicking out of a field/area with focus. To be 
on the safe side, I've left the caret and current-word traps in place 
for the moment. Please delete your %rebgui.log files and report any 
further occurrence of these types of errors (after upgrading to build#88 
that is). Lucky build number to solve this with too! ;)

Couple of deep design questions. Run the following code:

display "A" [
	button [
		display "B" [
			f: field on-unfocus [false]
			button [print "Click"]
			do [set-focus f]
		]
	]
]


1) Click the button to open display "B" ... type some text, then 
click the OS close button ... then try the same thing again.


What you should see is that you can't enter any text the 2nd time. 
This is due to the fact that the 2nd time set-focus is called it 
fails to unfocus so is left in limbo. Not sure what to do about this 
case.


2) Run the sample again. Click button to open display "B" and click 
the button.


Note that the button's action fired as clicking a button does not 
shift focus (i.e. you can click a button and continue typing in a 
field). The question is: even though we are not tabbing out of the 
field, should the button's action have fired. This question becomes 
even more relevant when the button action does something like open 
a new display (or close the existing one) ... should this action 
be allowed to proceed even though there is a failed unfocus action 
pending?

Ah, you fix one problem only to discover a bigger one! Anyway I've 
uploaded build#89 which addresses the two specific issues above:


1) Clicking the close button on a window now forces an unfocus but 
*without* triggering the on-unfocus action (or a show).


The /close refinement of display must now return true or false to 
proceed or not with the close operation.


2) Clicking a button only fires its action if it is not the current 
focal face and the focal face's on-unfocus action returns true


Try these with the test code posted above. You should see that it 
now behaves as you would expect. But now try the following code:

	display "" [
		field
		calendar
	]


Click on the field and start to type, then click on the calendar 
and continue typing! Why does this happen? It happens because when 
we detect the 'down event we have no way of knowing whether it originated 
from the field or the calendar. %display.r *should* be able to have 
a detect function that (among other things) does a:

	if all [
		find [down up alt-down alt-up] event/type
		face <> view*/focal-face
	][
		code to check on-unfocus
		code to do an unfocus
	]


but this will not work because of a view bug that causes face to 
be the window face *not* the face that originated the event. Urrgh. 
At this time I can't see how to trap and process mouse click focal 
changes. Might have to delve into the VID sources again to see how 
(if) it was solved there.

Oh this is just too funny. Found where it's "solved" in VID. %view-vid.r 
and the 'insert-event-func with the following comment:


;	!!! This next line is a hack, because we really need to know what 
face the event

 ;	is directed toward.  We need a way to get that info, but it's not 
 available here.

Anyway, try the following in VID:

	view layout [at 0x0 field at 0x0 btn]

Start typing, click the button, and then continue typing!

Borrow the same hack from VID and hope http://www.rebol.net/cgi-bin/rambo.r?id=3867&
is fixed!

Build#90 uploaded to SVN with mouse focus hack borrowed from VID. 
Run this script:

	display "" [

  field on-unfocus [either (length? face/text) > 3 [true] [false]]
		button [print "click"]
		calendar
	]


Click in the field and type a character, then try clicking the button 
or calendar, continue typing and then click the button and calendar 
again.

I'm hoping today's builds fix *all* outstanding focus/caret problems, 
many of which have been around for a long time now. ;) If that's 
the case then I'll do a public build and the pace of changes will 
slow.

On windows, no-title replaces the windows title-bar and blue 3 pixel 
border with a 1 pixel black border. no-border in conjunction with 
no-title removes the black 1 pixel border. no-border does nothing 
by itself (at least on my WindowsXP box).

Any chance of capturing control and shift Function keys?

and I buy a beer to person, who makes ctrl tab, and ctrl shift tab 
working (tab widget) :-)

Any chance of capturing control and shift Function keys?

 I certainly don't want to have 36 function key handlers, but enhancing 
 the function key handler spec to support refinements should be easy 
 enough; so:

	make function! [face] spec

becomes:

	make function! [face /control /shift] spec

does Alt work? (for menu)
 ... see http://www.rebol.com/docs/view-system.html#section-5.9

Short answer, no. But if R3 supports it I will.

who makes ctrl tab, and ctrl shift tab working

 ... easy enough to trap these keystrokes. Figuring out what to do 
 with them then is the tough part!

Also, cursor key to change focus on buttons

 ... yep, keyboard focus control is one of those long-standing issues 
 I'd like resolved. But mouse issues come first for me (i.e. until 
 the focus/caret/mouse system is 100% I'm not interested in enhancing 
 the keyboard focus system beyond basic tab support.

what to do is easy - at least in Windows (but I would expect mac 
and linux too), you switch tab focus ... ctrl shift tab goes in reverse 
order ....

really? ctrl plus tab is trappable in rebol view engine

 ... I think so. I already trap tab (via event/key) and control is 
 just a state (which is trapped elsewhere). No reason they shouldn't 
 work together.

but at OS level, when your dialog has tabs, and you want to navigate 
them using keyboard, you use either accelerator keys (we can have 
them, but unless rich-text is available, we can't underline accelerator 
key (the same goes for menu)), you use ctrl tab, ctrl shift tab, 
to change tabs (talking about tab widget) ....

Ah, you're talking about tab-panel tabs and focus ... I was talking 
about shifting focus with the tab key. Yes, it would be nice if that 
worked.

Yeah, I just got around to testing this and no dice. Ctrl & Shift 
work with function keys though. If you want to see what other combinations 
work then you can use the following script (based on %keycodes.r 
that someone wrote years ago):

	insert-event-func func [f e] [
		all [e/key print [mold e/key e/shift e/control]] e
	]
	print ""
	view layout [text "Start typing"]

Build#93 released and available. Includes all fixes from builds#83-93 
plus a new on-edit action handler. Release notes available here:

	http://www.dobeash.com/RebGUI/release.html#section-9

Yes. Technical difference between it and on-key is that on-key is 
called prior to keystroke processing, whereas on-edit is only called 
if the keystroke actually changed the text (including a change in 
capitalization ... i.e. it does a strict-not-equal? comparison).

I think I see the problem.   If you highlight from right to left 
in a field, where the word you are highlighting is left aligned, 
then if your mouse pointer leaves the widget, the highlight disappears 
immediately.  If you highlight from left to right in a field, where 
the word is left aligned, you are more likely to stay within the 
widget, and the highlight sticks.  if however, your mouse drifts 
outside the field, it will also then lose the highlight.

but double click highlighting only works on one word .. and not when 
spaces separate words.

FYI: Lad and I have done a regression test environment for RebGUI. 
With this you can write test cases and have the environment run them 
for you. With logging etc.

drop-list: I face the same problem as with check-group, where I need 
an ID for the entries. For example:
	- I have a drop-list with country names
	- My app supports DE and EN language

 - Depending on the language, the drop-list has different data and 
 shows different texts

 - to avoid a database lookup, internal LUT, I would like to get back 
 an ID of the entry
	- this frees me to use the (changing) text representation

Couldn't the data block *index* of the currently shown string be 
stored in an attribute of the drop-list face ? When the action is 
called, you could then access the index and refer to your list of 
ids which you maintain separately (and however you like).

This is interesting to me because I will write a VID drop-down list 
shortly, and the application requires showing only a certain field 
from a multi-field row of information, but without losing the association 
with the row. The displayed text is not a key field in the row in 
my case either.

Yes, not the perfect solution. I want to keep IDs and Strings together.

Can the data change while the drop-list is open ? ie. you click the 
down arrow to open the list, then some other asynchronous event in 
your program changes the data and asks the drop-down to refresh itself. 
(This is pretty extreme, but, just in case.)

Robert, I have it working. I derived 
	drop-list.r -> drop-list-Anton.r     3 lines changed and 1 added
and 
	choose.r -> choose-Anton.r     1 line changed