World: r3wp

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

But I think you're right, the fastest thing to do is derive your 
own drop-list widget.

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

Ok, so DROP-LIST calls CHOOSE, passing it DATA.
Then CHOOSE makes a popup FACE-ITERATOR, linking it to DATA.

The FACE-ITERATOR's PANE function just assumes the data is one item 
per row. (Or shows each complete row of the data.)

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

Official CHOOSE probably doesn't want to be modified, but you could 
just add the modified CHOOSE function into the drop-list.

I will post it privately to you unless anyone else is interested.

Another way of achieving the same effect is to simply populate %locale.dat 
with the required language/domain specific substitutions and let 
layout do its thing. e.g.:

	words: [
		"AAA" "My-AAA"
		"BBB" "My-BBB"
	]

then:

	drop-list data ["AAA" "BBB"]


I just don't see how changing radio-group and drop-list [only] solves 
anything. What about text-list, table, drop-list or any other widget 
that display's a value or values?

Well, it would solve Robert's immediate need from real life.
But it does beg for a more general solution.
Maybe each iterating face can have an optional map function.

Ashley, for tables I have always a hidden column with a record ID. 
This ID is used through all the program.


For drop-lists I "store" the text of drop-list/picked at the moment. 
Hence if you have several languages, at one time you store the DE 
version at an other one the EN version. So, one solution is, I have 
to translate to the "master" language that's used in the database.


But what if syntex changes? Than I have to update all old entries. 
Using IDs frees me from this but adds an other level of indirection. 
The common way would be to normalize my database model and use other 
tables to get IDs, and than store those etc. IMO that's the way to 
make apps complex and slow.

We have added a more "spophisticated" I18N system to RebGUI, that 
can handle not only strings in layout but at all places in the program.

If that's the case, then aren't ID's a moot point? (i.e. the issue 
you seem to have is internationalization, not ID's).

It's two things: position and text independend (which solve I18N 
as well) storage.

Fonts: I want to get some text / labels in "Arial Narrow" on the 
screen. How do I do this? I tried but don't know what I need to do.

Robert - what is your level of multilang apps? Only data, or also 
UI?