World: r3wp

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 ?

t: join head insert/dup copy "" " " 500 "test"
view layout [text t white blue]

t: join head insert/dup copy "" " " 500 "test"
view layout [text t white blue 'as-is]

Just to make Graham's suggestion explicit.

The word doesn't have to be literal:

view layout [text t white blue as-is]

No it doesn't change the result.
To test it give a width for the text:

t: join head insert/dup copy "" " " 500 "test"
view layout [text 100x400 t white blue as-is]

test
 is still on the second line.

I tried as-is, line-list: none, I need to use wrap?: yes. Otherwise 
I have to my own wrap function which I don't have time to do.

Here is the difference:
t1: join head insert/dup copy "" #{20} 500 "test"
t2: join head insert/dup copy "" #{A0} 500 "test"

view layout [text 100x400 t1 white blue as-is return text 100x400 
t2 white red as-is]

I would call that a feature, not a bug.  The (normal) breaking space 
allows word wrapping to split between words, rather than in the middle 
of words...

How can you call that a feature? The text field is 100 pixels width, 
I put 500 space chars and then a word after that, and the word appears 
on the second line of the text field. Where is that 500 chars? Even 
if you insert new spaces (let say 1000 more) the word position doesn't 
change.

If you think it as a html document (all whilte-spaces treated as 
one space char) then why it stands on the second line?