World: r3wp

Pekr ... I may be wrong here, but doesn' t .Net call Windows libs, 
too?

Hi!
How to keep selection after show for text-list?

F.ex. code changes text-list data, for selected row, than after show 
a-text-list, selection of selected row disapears.

O'k found myself - selection is in face/picked and they should be 
equal of elements in face/data:
F.ex:
face/data: [ "peas" "apples" ]
face/picked: [ "apples"]
the above statement shows selection in face after "show face" 
face/picked: [ "apple" ] 

the above statement do not show any selected row after "show face"

I've noticed that the 'resize event automatically causes a SHOW, 
as far as I can see. This seems to me is a little silly, since there 
is no chance to resize your GUI before this SHOW and you need to 
show the GUI twice, slowing down the display process by a factor 
of 2. Is there a way to resize the GUI before 'resize does the SHOW 
or disable the SHOW on 'resize event?

maybe feel/redraw ?

Henrik, that doesn't sound right to me. What's the code in question 
?

Actually, I think you are right:

view/new/options window: layout [box: box] 'resize

window/feel: make window/feel [detect: func [face event][if event/type 
= 'resize [box/color: red] event]]
do-events

The box color is only revealed to be red on the second resize. So 
it looks to me like the SHOW happens *before* the detect function 
is passed the 'resize event.

Let's try Gabriele's suggestion:

view/new/options window: layout [box: box] 'resize
window/feel: make window/feel [

 detect: func [face event][if event/type = 'resize [print "detect 
 'resize" box/color: red] event]

 redraw: func [face action position][print "redraw" if face/size <> 
 face/old-size [print "changed size" box/color: blue]]
]
do-events

This is printed:
	redraw
	changed size
	detect 'resize

Wow! What a revelation. It looks like REDRAW is called first, then 
SHOW, then DETECT is called.

Thanks for asking that question, Henrik !  I've been blithely using 
DETECT all this time and not noticing that it was doing a SHOW first. 
I'll try using REDRAW instead of DETECT from now on and see how it 
performs.

yes, that is one of the things I had to work out in GLayout too... 
 :-)

anton, but when you resize the window with mouse and by changing 
the size of the window face, I think the order might actually change.

I remember having a hell of time trying to resize the window properly 
without it causing a cascade of resize/show events...

(where talking a few years ago so my memory is rusty)

Ok, here's an issue that's just come up for me:

view layout [field [print "validate 1"] field [print "validate 2"]]

If you type in a field, then press TAB it prints "validate" - Good.

if you type in a field, then press SHIFT-TAB, it does not. - Bad. 
<----

This behaviour is specified in the EDIT-TEXT function in CTX-TEXT, 
in the TAB-CHAR handler.

I seem to recall someone actually asking for this behaviour. I think 
they wanted a way to "reverse out" of a field without validating 
it.

This seems wrong to me. I would have thought Shift-TAB would be just 
like TAB, except going in the opposite direction. I want to always 
validate when leaving the field.

It would be better if undo was implemented for the field. When all 
the changes are undone, then the face/dirty? field should be reset 
and the face/action can avoid validating unnecessarily.

The ESCAPE key could be used to undo all changes (and so avoid validating) 
before the user TABs or SHIFT-TABs out of there.

ie. I don't want to leave a field with unvalidated data in it.

I have a decimal-field, which is just a field whose action just cleans 
the face/text and ensures that it can be converted to a decimal.

If the user can just SHIFT-TAB after making changes to the field 
then the validation in the action block is skipped and the field 
is left showing invalid data.

The line in the TAB-CHAR handler in EDIT-TEXT which is causing all 
the trouble is this one:
	if not event/shift [action face face/data]

This line is gonna get the knife, if I have anything to do with it.

So I might make a RAMBO bug report on that.
Anyone have any comments before I do ?

this is a difficult issue. personally, i prefer tab and shift-tab 
to not do any validation, while enter does. it's not always a good 
idea to not let users go away from a field just because it is invalid.

however, since this depends on the application etc., i think the 
best solution is to call the action on enter, and just call face/refocus 
on tab / shift-tab. then you can make refocus do the same as the 
action, or not.

Gabriele - will there be anything improved in regards to keyboard 
and R3? Key-up event, ctrl tab, multiple keys pressed?

there are no details on this currently. but, this part should be 
in the open source part, so as long as people can manage to let it 
work consistently across platforms, i'm sure it can be done.

Anton, gabriele, thanks alot for those tips! Maxim also told me that 
the feel must be set every time you view the window.

yes, view can change win/feel

i think that the latest versions don't, but there may still be cases 
where that happens.

to be safe, you can view/new, change feel, then do-events.

Gabriele, I see your point: The user might want to enter some data 
in a field, but part way through think of something else and leave 
the field to attend to it, then return to the original field to complete 
the data entry. Finally the enter key will do the face action which 
can validate the field.

I think your solution using REFOCUS is a good one.

Henrik, welcome. Just look in source of VIEW to see how it sets the 
window feel. Gabriele is right, nowadays it shouldn't cause much 
trouble.

Are we still going with 'feel like it exists today, even for R3?

I hope it will allow more granular events.

I hope too. I don't like mega monstrose 'feel. It does not scale 
well. On one hand, you can code everything from one place, on the 
other hand, it is more handy for "style authors", than end-users 
...

Ah, but maybe by "more granular" you meant receiving events more 
often?

No, more different kinds of events.

I think personally that FEEL is very non-accessible to users and 
non-extensible. You can't easily add a simple thing to a feel, like 
when you create a style from a specific face. If you want single-key 
actions from a text field, you have to dive into the feel code, study 
it, know how feel and events work and then add your code. This is 
probably more an issue with the feel code itself, rather than the 
concept of FEEL.

Ah, then we are on the same wave. But I was not able to defend my 
opinion to e.g. Anton in the past :-) So surely rebollers will differ. 
For your own kind of style, e.g. animation, you might prefer current 
aproach. But I visited recently my friend, who started to learn Delphi 
some 2 months ago, and he already did nice app in it. The most missed 
feature of SDK is - no screen painter, lack of crucial styles, lack 
of proper style behavior (just try list-down here in AltME, you can't 
close it by clicking outside, esc, etc.?), and most ppl are really 
used to - on-double-click, on-left-click, on-over, whatever ...

There should be a ton of placeholders inside the feel code, to let 
you easily set those placeholders from within layout. I know this 
is possible to do.


view layout [field 100 single-key-action [print face/key]] or something

maybe: feel [

ah, enter ;-)

LIST-VIEW has a lot of different actions that let you set what it 
should do in particular situations easily. Every single VID element 
should have that. In fact there should be an abundance of placeholders 
for actions, every one that we can think of.

feel: [
on-single-key            [block of code]
on-left-mouse-click [block of code]
on-double-click        [block of code]
]

yes, very simple.