World: r3wp

Nice picture there, Terry! The  "look-out" within the 'O' reminds 
me of some pictures, I made with my Amiga500 many years ago. :-) 
But we didn't have such nice colour fading back then. Very nice!

Is it possible to check on keyboard key-pressed and key-released 
events, like you can with mouse-button down and up? I need that for 
e.g. movement in games.

there is trouble with keyboard in rebol. I am not sure, but IIRC 
Cyphre can talk about that. You can't catch key-up event for e.g., 
no ctrl plus tab, etc keys ...

We already asked RT for new abstracted keyboard handler .... they 
tried to stay compatible, but not having some key combinations is 
not solution too ...

There's a fine example in the feel how-to: http://www.rebol.com/how-to/feel.html

But it will only catch key-press events, as I see it. So again, is 
it possible to catch key-release events, anyone?

I think not ....

You can look for Cyphre's Shadow of the beast demo -  it is nice, 
it also shows parallax scrolling to some degree, but keyboard is 
real limitation ....

ok, will have a look.

Yes, his demo only catch key-pressed events too, so it seems, release 
events isn't supported yet. Well, I'll stick with that for now then.

I was once working on a game, and to make the character move, I used 
the basic code

of the "raw key press" button on http://www.rebol.net/plugin/tests/test.html

It worked quite well, the character kept moving as long as the key 
was held.

the main problem is lack of 'key-up' (and maybe 'key repeat') events. 
But the key-up is the most fundamental one. Without this we aren't 
able to make multi-keypress control. So for example when user is 
holding up-arrow he is not able to move to left by pressing left-arrow 
simultaneously.

Moreover REBOL is using some high level OS keyboard handling routines 
so if you have setup key repeat delay too long on your system...this 
will affect your control in Rebol app too...so if user wants to go 
left he press the left-arrow but the 'repeat' events are sent after 
the delay (from os setup) so the action is delayed..very annoying.

I can see, it must be hard to support these features on all platforms. 
It's rather deep down in the OS.

Maybe it is not easy(or time consuming) to implement but it would 
be cool to have it at least on main platforms(win, linux macosx). 
btw Flash has the same functionality so why not Rebol?

exactly - we can't use the least denominator forever ....

Maybe we should get some example source codes for each platform.

You know the "btn" style? How do you adapt that to say, a toggle 
button?

someone has to build the images used.

view layout [btn "hi" "ho" with [flags: [toggle]] feel (get in get-style 
'toggle 'feel)]

james: that's a just a starting point to show that applying the toggle 
feel to the btn gives you the desired effect. I'd probably stylize 
in real usage.

same again with an action block

view layout [btn "hello" "goodbye" [print face/text] with [flags: 
[toggle]] feel (get in get-style 'toggle 'feel)]

My humble attempt to improve upon Gabriele's original rich text style 
can be found at http://www.dobeash.com/files/render-rich-text2.r
... supports strikeout and color. Suggestions for improvements (both 
functional and efficiency) more than welcome.

I have united two previousliy existing styles, which were very similar; 
PAIR-EDIT and INTEGER-EDIT into a single source file. Now a CREATE-EDIT-STYLE 
function takes a datatype argument (eg. pair!) and generates the 
appropriate style. A bit of extra work and it supports also  decimal!, 
so you can have a decimal-edit style as well... I'm proud of this 
optimizing - only possible using Rebol. The final source is only 
a little over the size of the original pair-edit, so it is a very 
good increase in efficiency.

I will publish at some time... earlier if someone is interested.

It seems that demos for /View 0.9 (0.8?) are still available:
http://www.rebol.com/view/advanced.rip
http://www.rebol.com/view/face.rip
http://www.rebol.com/view/demos.rip
http://www.rebol.com/view/users.rip

Most code don't work in current /View, but there's a lot of information 
and examples on low-level face access.

I have a window that I want to make a dialog box .... so I do an 
inform on the layout.

Is it possible to make the resultant window resizable ... a la ... 
view/options layout [......] [resize]

Yes

the /Options refinement of layout simply sets a couple of flags in 
the face...

help layout
USAGE:

    LAYOUT specs /size pane-size /offset where /parent new /origin pos 
    /styles list /keep
/tight

DESCRIPTION:

     Return a face with a pane built from style description dialect.
     LAYOUT is a function value.

ARGUMENTS:

     specs -- Dialect block of styles, attributes, and layouts (Type: 
     block)

REFINEMENTS:
     /size

         pane-size -- Size (wide and high) of pane face (Type: pair)
     /offset
         where -- Offset of pane face (Type: pair)
     /parent
         new -- Face style for pane (Type: object word block)
     /origin
         pos -- Set layout origin (Type: pair)
     /styles
         list -- Block of styles to use (Type: block)
     /keep -- Keep style related data
     /tight -- Zero offset and origin

No options keyword ?

sorry refinement

You should be able to set these options manually with something like...

lay: layout [text "testing"] 
lay/options: [resize]
view lay

My bad, I meant the /Options refinement of VIEW

Another thing ..... running on WinXP under view from 1.2.5 & upwards 
....
view/options layout [btn "Test"] [resize]

.... gives me a window that is only partly filled in with the default 
background color?

Is that me .... cant beleive I havent ssen it before?

I have

I think that this is in RAMBO but I'm not certain...

your code with the options against the layout works with inform ... 
thanks Ammon.

You're welcome. ;~>

Phil -- how do you set your background colour?

Oh, ignore...

Phil, that bug has been around for ages. I guess not important enough 
to fix yet :) But I don't remember anyone analysing it thoroughly.

Is it the same under Linux ??
Under windows, this one works fine :

lay: layout [btn "Test"]
print lay/size
view/new lay
print lay/size
do-events

And this one give the result PhilB mention :

lay: layout [btn "Test"]
print lay/size
view/new/options lay [resize]
print lay/size
do-events

Notice that the size is not changed. So View think the window is 
not as large as Windows does. Looks like Windows set the window size 
to it's own minimum size.

Funny! With 1.2.1 the not filled part is white, with 1.2.48 it's 
filled with what is in the background (like if it was transparent) 
:-))
But it's not ! Just move the window :-[

(tested under WnXP)

Yes, I observed this behaviour long ago. It should be added to RAMBO, 
if it has not already.