World: r4wp

also, i get that x: [ append [] 1 ] then 'do x do x' differs from 
x: [ append copy [] 1 ] 'do x do x'

henrik: so if i load the script, then do it, rather than doing the 
file?

makes sense, hadn't considered that

so: best practice is to consider everything to be inside a block, 
and hence copy even toplevel literals?

not even needed. you may DO the same script several times for the 
same effect.

in the

    a: []


it is so, that if you do not "reuse" the literal block then it does 
not matter whether you copy or not

by "reuse" I mean if you do not keep the code and reevaluate it once 
again

right

but of course,

>> x: load %foo.r 
== [
    foo: [] 
    append foo 1
]
>> do x
== [1]
>> do x
== [1 1]
>> foo
== [1 1]

which was henrik's point

actually not

oh!

and by "keep the code" I mean "keep the code as a block", if you 
keep it as a string then it does not matter

do %foo.r
do %foo.r

will produce something you may not intend.

well, if there are side effects, sure

but with the above, i get the anticipated result,

>> do %foo.r
Script: "Untitled" (none)
== [1]
>> do %foo.r
Script: "Untitled" (none)
== [1]
>> foo
== [1]

ladislav: yep, understood

sorry, MarcS. you are right again. I better take a nap...

so to get back to pitfall vs. stylistic - i notice that carl's scripts 
(makedoc, blog) tend not to copy 'global' literals

whereas, for example, the source for vanilla does

However, when writing something like:

a: []


into a file, you may not be totally sure that somebody does not LOAD 
your code and try to evaluate it twice....

yep

so unless you're certain (!) that that won't occur, better to be 
safe and copy?

Yes, copy looks safer....

thanks for the help

Henrik: I've registered on http://hmkdesign.dkBugs database (curecode), 
I got an error when I create a new account but I think it created 
my user. Can you check it please?
My username is "endo".

I've setup a new Cheyenne (r179) with html-008.r included, playing 
with html dialect.

now validated... also validated 3 other registrations from 2009... 
I guess they are in for a surprise email. :-)

Why can't  a button hide itself? Looks like /SHOW? is always set 
TRUE on exit from an action facet:
    view layout [b: button "hide me" [hide b print b/show?]]
   (esc)

   print b/show?   ;; expect FALSE if button clicked, but always get 
   TRUE


My ungainly work-around is to move the button well out of the visible 
area:

   view layout [b: button "hide me" [b/offset: -100x-100 - abs b/offset 
   show b]]

(the abs and -100s allow me to reverse the action to put it back 
where it was)

AFAIK, it's because the action is run on mouse down, and the mouse 
up event causes a redraw, which will then show the button again.

action is run on mouse up.  I can't figure out why face won't stay 
hidden... but its probably because Carl used redraw.   first thing 
I do when I build new styles is to clear the redraw.

you are right. the problem is probably that the action is run before 
the redraw takes place. but it's been a few years now since I worked 
on this problem.

IIRC feel/redraw does a show on a face which forces it back on.

just about every time I've had to fix something with VID it was related 
to the fact that redraw is being used.  its a very bad design... 
redraw should never have been put into the feel.   its also a big 
slowdow, since it forces every face to redraw itself when you show 
a pane.

slowdown

A button can remove itself: lokk here:
a: layout [b: button [remove find a/pane b show a]]
view a

Did you understand how it works?

but here you removed the button...  hiding it , leaves it there.

Thanks guys...MaxV that's the overkill solution :-)

Another question ... I'vd like a field action facet to be triggered 
on field exit.
But I can find two cases (under windows) when it isn't:
1. ctrl+tab out of the field, rather than tab
2. right click another face, eg a button


   view layout [field 100x100 [print "field was exited"] button "click 
   me" [print 'left] [print 'right]]


Any ideas for making the field action trigger in all cases? Please!


(Right now my workaround is to do a bulk check on all fields when 
the user clicks a main action button like SAVE, but that means they 
may see multiple field-exit messages all at once, and later than 
they'd expected).

(oops new VIEW/VID group now open for such questions).

Any good reason why DEHEX won't touch %00 ?  It's the only one of 
the 256-single-byte values it leaves hexed rather than dehexed
   dehex "%00 %6f%64%64%3f"

that is a strange bug

Yes, it is thanks. I stumbled across a case where I had to run DEHEX 
twice because it skipped a few values the first time.

Sadly, not been able to replicate that in a one-liner, so it may 
have been something stupid I did.

Works in R3.

it is a bug in R2 2.7.8

nice that its fixed in R3

Just 2.7.8? Not earlier versions?