World: r3wp

I can't actually get focus to the face either :(

My old send-keys stuff should be around somewhere. If not, let me 
know and I'll zap it to you.

did it not rely on the console being opened to work?

Gregg, please send it to me

Graham, sent.

Thanks .. looks like send-keys solves my problem too :)  I needed 
to send a backspace to a rebgui field to initialize it and this works

for those who don't know how to change the title of a window in R2....

rebol []

win: view/offset/new layout [

 button 400x20"change window name" [ win/text: random "ogiue goiueng 
 oesigneso ginue sogine sgioun " win/changes: [text] show win]
] 200x200

do-events

The following code cause an error if you click on the window (XP 
SP2) :

view layout [box effect [ draw [
    pen none navy
    line-pattern 2 7 2 3
]]]

Does others could confirm the problem ?

it just quits here in 2.7.7.

It's known bug. At least Maxim was talking about it with Cyphre in 
OSX group a few days ago.

Tested with View 2.7.7 & 2.7.8 on Win7/32-bit, it quits too here.

I always get :

Instruction at "0x7c920cce" use the memory address "0x40080000". 
The memory can't be "read".

(rougthly traduce from the French message !)

yes, its a BUG in AGG, using more than 2 values in line pattern will 
cause the crash.  its the oldest AGG bug I know of.


spoke with cyphre, its possible that this will be fixed in next release 
of R2, which shoudn't take more than a few weeks IMHO.

How does one capture whether a window is maximized or not?

I can see a maximize and a minimize event, but no restore event. 
And face/changes is cleared, when the event handler reads it. Not 
very useful.

face changes is used for the internal show to optimise if/what it 
should redraw. as such its a "write only" property, reading from 
it makes no real sense.


for example if you set changes to [offset] it will move the window 
MUCH faster than if you change offset & show without it.

I have a problem. Basically I need to know how to interupt a function 
that is looping. 

So this is what happens: The user presses "start" button which calls 
the printing routine. I want to be able to allow him to stop the 
process if he wishes by pressing a "stop" button. The issue is the 
face is only recording my attempts to stop. Any thoughts?

I usually set a flag with a button and try to read the flag in the 
loop. I'm not sure if it's easy to get an immediately responding 
button, though.

perhaps if you wait a short period prior to reading the flag in the 
loop.

Yes, I've tried to do that but it doesn't seem to work.

I'll put a wait and see

OK, I'm getting close.

Yup, the wait does the trick. Thanks Henrik.

ok, cool

yes, the wait allows the event system to act like an async system. 
 


just be careful though, you can get lost in concurrency and get apps 
which close all windows but don't actually close the rebol process, 
which ends up in an event deadlock.    :-)

Yes, I actually saw that in my tests as well. For now this one "wait" 
seems to be doing its job and I just hope it is not system-dependent 
in terms of the time I have set the wait for.

Can someone confirm this issue: secure allow permits all access, 
but library access still pops up security window.

>> secure allow

== [net allow library allow shell allow registry allow envr allow 
file allow]

>> dll: load/library %REb-Excel.dll
** Access Error: REBOL - Security Violation
** Near: dll: load/library %REb-Excel.dll

The problem still there even I start rebol.exe with -s option.

But if I start rebol.exe with --secure option then it doesn't pop 
up security check window. I tested this on Windows XP/2008.

So it looks -s and --secure don't behave same. Which can be a bug 
in current R2/View.

I've never had the problem. (even on w7)

I always use -qs.

secure allow should behave like that, right?

AFAIK yes.

if we don't use --secure allow or -s.

so maybe there is a bug within the secure function.  did you check 
on RAMBO?

yep, I checked rambo, no ticket for this.

I've never seen this either. But all my scripts that use load/library 
are started with -s... (or encapped)

that is strange.. I'll test it again in a few days, the PC is on 
a customer place..

This example, in REBOL/View Developer's Guide was working before, 
but now gradmul effect doesn't give the expected result. I tested 
it on View V2.7.7.3.1 and 2.7.8.3.1

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow
        effect [gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

hmm.. if I give a second color for VH2 then it works as expected. 
Some lastest changes affected this I think.

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow red
        effect [gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

because the face is transparent, and modifying it (not creating new 
images) you have to merge the background... this change occured a 
long time ago (draw V2 IIRC).


in your second example, it works only because you set the face color, 
which is then multiplied. 

first example, fixed:

view layout [
    backdrop effect [gradient 1x1 180.0.0 0.0.100]
    vh2 "Layout Definition:" 200x22 yellow
        effect [ MERGE gradmul 1x0 50.50.50 128.128.128]

    vtext bold italic "Layouts describe graphical user interfaces."
    button "Remember" effect [gradient 0.0.0]
]

Ok, thank you. I understand. Earlier versions of 2.7.x it wasn't 
like this as I remember. (or am I getting older?:) )

yeah, its been like that a long time, its just an edge case which 
people don't hit often.   you probably where using faces with colors 
and you didn't realize it.

There is a very annoying bug on View (2.7.8.3.1), can anyone confirm 
that? Please see the code below:

fnt: make face/font [
	name: "Courier New"
	size: 14
	align: 'left
	valign: 'top
	color: white
]


f: make face [color: blue / 2 edge: none size: 300x200 text: "" font: 
fnt]
window: layout/size [] 500x400
insert window/pane :f
loop 500 [insert f/text " "]
append f/text "test"
view window

It doesn't matter how many space character you put in to face/text, 
it always shows the text after spaces, on the second line.

I tried f/line-line: none etc. If I replace spaces with anything 
else then it works as expected. But space chars somehow ignored by 
the face.

I can only find a workaround, I use #{A0} (no-break space, alt + 
0160) character instead of normal space #{20}. Then it works ok.

no-wrap ?

as-is ?