World: r3wp

word you were checking used to remain high lighted

 ... by virtue of a focal-face bug. I eventually want to do the highlighting 
 with draw.

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 ....

Shift-tab (i.e. back tab) already does that.

shift tab? for fields etc.

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.

ctrl+tab is not trappable in Rebol (under Windows) at the moment.

Haven't we had this conversation like, 10 times ?

Anton - yes, and? :-)

ctrl tab was mentioned "by the way". But other hot keys can be fixed/added.

Ok, fair enough.

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"]

So, we can include code to assign the control/shift function keys?

Yes, I'm adding this to the next build.

Build#92 uploaded to SVN. Adds event support to function code handlers 
as follows:

	ctx-rebgui/on-fkey/f3: make function! [face event] [
		prin "f3 "
		if event/control [prin "Ctrl "]
		if event/shift [prin "Shift "]
		print ""
	]

This is going to be tricky.  Have to create some intermediate function 
to then call the appropriate function ( normal control or shifted 
)

is it possible to have progress as a part of the UI, not separate 
window? (as with Calednar)

ah, request-progress uses progress widget, forget it ....

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

on-edit is like a dirty? face  ?

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).

.

Doesn't seem to be able to highlight text going from right to left 
( it loses it instantly ).  Only works reliably from left to right.

Huh? Are we talking about highlighting in general or a specific widget/case?

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.

Also, the caret should move to the beginning of the word you are 
attempting to highlight

Ashley, possible to improve the highlighting so that it works as 
well as in Altme?

It's doable, but note that caret placement does not work as described 
above (either in RebGUI or AltME). Remember that RebGUI also supports 
double-click highlighting (which might make the above request a moot 
point).

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

As last time, my radio-group change wasn't liked. We will derive 
a special kind of drop-list.

Robert, how would you like your drop-list strings to be associated 
with your id's ?
1)
	data: ["apples" "bananas" "cherries"]
	ids: [3 15 220]
or
2)
	data: [ [3 "apples"] [15 "bananas"] [220 "cherries"] ]
or
3)
	data: [ ["apples" "bananas" "cherries"] [3 15 220] ]

or something else?

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).

Robert, give us some of the actual strings you put into the drop-list.

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.

drop-list:	data [1 "apples" 1 "bananas" 2 "cherries" 3]

Like in radio-group. Preselecting entry 1.

index: Changes if you have entries order changes. Alphabetical sorted 
list of same things in different languages can have different order. 
Solution must be position independent.

Why do you want some of my strings? The solution must work for all 
strings.:-)

Can the data change during the life of the drop-list ?

Alright, I don't need your strings :)

Yes, it can. That's why I need the IDs to be data independent.

Right.

Robert, looking at drop-list.r, it appears to me (*if* you can guarantee 
unique strings in your data) that you can maintain the selected id 
externally using the on-click action.

or does that become annoying in your app ? I imagine it would become 
annoying if you had more than, say, four drop-lists in your app.

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

This is something that potentially affects many list-type gadgets/widgets.

You want to be able to connect the widget to your original data, 
without expecting it in any format, but also provide the widget with 
a function which maps the desired cells from each row into the form 
the widget likes (for its "view" of the data).

(As possible with the original VID list style.)