World: r3wp

your main routine

not the gui

if I put it into parens or 'do block into VID, it gets called during 
layout phase ...

why does it have to be in vid??

OK, so I do:

forever [
   if disk is detected [
        view/new copy-screen
        copy-dir source target
]

Now where do I put do-events?

'copy-dir is recursive, I can't start event loop there ..... I need 
to somehow start function from the copy-screen section. It is just 
that I don't want to have it assigned to button :-)

I remember that we did some timer trick in the past, but can't remember 
now ....

view/new copy-screen
hide copy-screen

forever [ if screen detected [ show copy-screen do-stuff hide copy-sceen 
]]

so no do-events?

somewhere :)

run it in the task bar

and when you detect the disk, then bring up the main gui

I mean system tray

Graham - I used one trick, I defined new style in VID, called init, 
set rate to 1and defined engage block. After first call, I removed 
timer, but it worked in a bit weird way. In my copy routine I used 
little wait, but it did not work properly ...

Pekr;  did you show the face after changing the rate?  I got caught 
up by that one recently, the timer fires at old rate until show was 
called.  It is documented, but who reads those.  :)

yes, I used show ...

Thought so...wanted to mention it...just in case.

but it is possible my code could be messed-up ....

I really miss delayed after-init method in VID. 'do nor parens can 
make it, as those are executed during layout evaluation, not after 
'view is called ...

petr, while you are busy copying, you are not handling events, so 
no do-events there. you can call wait 0 every iteration if you want 
to respond to events while copying.

delayed after init is the same as doing something AFTER view/new

And just think...everything is about to change and we get a whole 
new can of worms to dig through.  The one comment Carl made about 
'hard-won knowledge' has me a litlle, umm, exitedly anxious for the 
docs.

hmm, don't see much change in a case like this, you still do the 
layout, view/no-wait it (new ref name instead of /new), and do the 
copy. maybe, you'll want to copy in a bg task, but that's another 
story.

Excitedly anxious for docs...   But, take your time.  "when do we 
get it, when do we..."  :)

Gabriele, I do following:

copy-dir: func [from to][recursive copying function here]
copy-screen: layout [layout of screen code here]

forever [ if new drive is detected and contains particular directory, 
view copy-screen, which should start copy-dir function]


.... somehow can't get it working properly. View/new can't help me 
here imo ....

Gabriele - how could I do it with view/new? I can't start copying 
after it, because I want to update screen. I can show some elements, 
but e.g. buttons will not be active, unless do-events is being run. 
That is why I complicated my script by implementing "delayed" copying 
= view copy-screen, there is an 'init style with rate 1 and engage 
defined. I check if it is a first run, and if so, I set rate to none, 
call show, and that is the place from  where I call my copy-dir function 
.....

petr, if copy is running, events are not processed, no matter how 
many do-events you put there

you have to do view/new, then inside copy-dir you need to call wait 
0 every now and then (eg. every file you copy) if you need your buttons 
to work.

even if you call copy-dir from engage, events are not processed while 
inside copy-dir unless you call wait

ah, so wait 0 causes processing of events?

those that are pending, yes. you can wait a little more to allow 
more to be processed, if you don't care about slowing down your copy.

How are you detecting the the disk being inserted. Are you accessing 
the os. Also, would this work for flash disks?

yes, it works ...

it is very simple principle ... well, it is not even a detection. 
When my script runs in the background, it does:

root: %/
drives: read root

later on, I simply check:

forever [
  wait interval
    foreach disk difference read root drives [
    ]
]

... and difference on block will throw you new disk ....

That seems simple. I wanted to create an auto cd burner. That routine 
would help!

can I somehow have layout defined in the manner, that I can:


1) reinitialise it (I can imagine something like store-screen: [copy-dir-screen: 
layout []] do store-screen

2) how can I "unset" it, "uload" it, whatever, to be able to reset 
all its words?

like this?
window: func [param1 param2 param3 ..][
	layout compose/deep [btn "Exit" [unview face/parent-face]
]

Thanks, that might work, but not sure it is what I want. Maybe I 
don't need it, so here come further questions:

- I want to run infinite loop script
- I want small screen to be displayed during copy

- I want to keep memory low, so I want to "unload" all screen related 
objects from memory


Now - is that possible? With above wrapping function, by calling 
it, I can get new/fresh layout, so variables being reinitialised. 
But when the copying is done, can I remove objects defined by layout 
from memory? Unsetting 'window will just unset the function, but 
I am not sure it following would help?

window: does [copy-screen: center face layout []]
forever [
view/new window
copy-dir
unview copy-screen

unset 'copy-screen (and other VID defined words referring to styles)
recycle
]

?

hmm, above does not free any significant memory ....

Pekr;  This is in free-mem.r from the library by DocKimbel and Shadwolf...I 
haven't played with it, and I don't know if it's any better than 
unset with newer REBOLs
; the free mem function
free-mem: func ['word] [set :word make none! recycle]

unset in 2.7.5.4.2 frees memory,  1.3.2.4.2 unset does not but make 
none! 0 does lower system/stats on a recycle.   I think make none! 
2000'000'000 will work too, but that seems kinda funky.  :)

What would be the best strategy to take, to achieve following? Imagine 
app with say 20 forms. It is insane and unnecessary to keep everything 
in memory. We should have even option to prevent tabs from doing 
so.


So I am thinking of a method to load/unload screens (forms), but 
freeing a memory. Of course you want to remember the state of widgets. 
So - can I somehow save the form, state of its widgets, unload it 
from memory, and load and reinitialise it at will?

memory is cheap

:-)

That might be a solution :-)

what I am asking for though, is kind of cocneptual aproach to the 
topic, if you would think memory constrained environments for e.g. 
Just curious, what the possible aproach could be ....

other than that, I do agree with your argument :-)

how about defining the layouts and widget variables inside a function?

I do that a lot