How can I do what Launch does?
[1/4] from: sanghabum:aol at: 15-Apr-2001 7:28
In another thread, Carl S. writes:
> Launch has a rule: you can only launch from the main REBOL process.
> This prevents launch loops.
That touches precisely on something I was trying to figger out the other day.
I've got a set of scripts (a.r, b.r, c.r). a.r uses DO to call b.r and c.r.
But it doesn't make sense for my intended user to in any way execute b.r or
c.r directly.
So, if they do, I want to tell them not to, something like:
if not (top-level) [throw "Please run a.r to start the application"].
But I haven't found the best way of writing top-level.....
-- I could use value? on a global variable. But global variables are
generally a Bad Thing in my book, so I'd like to avoid them.
-- I could scrabble round the System object for something that shows I'm top
level or not. But a quick look, didn't find me anything.
-- I could avoid the problem by giving b.r and c.r a different suffix (b.rll
and c.rll?). But who knows what effect that'll have when the user
double-clicks them?
So, whatever check Launch is making, I'd like to be able to make something
similar.
Any ideas how?
Thanks,
Colin.
[2/4] from: carl::rebol::com at: 15-Apr-2001 10:03
This should do it for you:
top-level?: does [none? system/script/parent]
-Carl
[3/4] from: agem:crosswinds at: 15-Apr-2001 20:28
pdp [{launch enabled:}
not equal? mold :launch mold func [] []]
pdp [{top-level:}
none? system/script/parent/parent]
see the script below (save it under its name..)
[rebol [
title: "can i launch? am i toplevel?"
file: %launchlevel1.r
]
uv: does compose [unview/all do (system/script/header/file)]
file: system/script/header/file
; file: %123
text1: copy []
&: func [s] [repend text1 ['h3 s]]
& mold now/time
pdp: func [block] [
& mold block
& mold do block
]
pdp [{launch enabled:}
not equal? mold :launch mold func [] []]
pdp [{top-level:}
none? system/script/parent/parent]
trap: func [] [
request/ok reform [
"my filename schould be" mold file ".."]
]
view/new layout append copy text1 [
across
button "test launch" [
either not exists? file [trap] [launch file]]
button "test-subscript" [if error? try [do file] [trap]]
button "close" [unview]
]
do-events
]
>In another thread, Carl S. writes:
>
>> Launch has a rule: you can only launch from the main REBOL process.
>> This prevents launch loops.
>
>That touches precisely on something I was trying to figger out the
other day.
>I've got a set of scripts (a.r, b.r, c.r). a.r uses DO to call b.r and
c.r.
>But it doesn't make sense for my intended user to in any way execute
b.r or
>c.r directly.
>So, if they do, I want to tell them not to, something like:
<<quoted lines omitted: 3>>
>generally a Bad Thing in my book, so I'd like to avoid them.
>-- I could scrabble round the System object for something that shows
I'm top
>level or not. But a quick look, didn't find me anything.
>
>-- I could avoid the problem by giving b.r and c.r a different suffix
(b.rll
>and c.rll?). But who knows what effect that'll have when the user
>double-clicks them?
>
>So, whatever check Launch is making, I'd like to be able to make
something
>similar.
>Any ideas how?
<<quoted lines omitted: 4>>
>[rebol-request--rebol--com] with "unsubscribe" in the
>subject, without the quotes.
volker
volker
[4/4] from: sanghabum:aol at: 17-Apr-2001 15:10
Carl:
> This should do it for you:
>
> top-level?: does [none? system/script/parent]
>
> -Carl
Thanks! Not quite, but enough of a clue to find something that does do what I
want.
Your top-level? means "Am I being typed at the Command Prompt?"
My a.r is already one level down from your top cos it has been invoked by
being double-clicked. I need to check the level in b.r which is DO'd from
a.r. That's another level down.
Fumbling around in the system script area helped me hack this slightly
inelegant test that does the trick:
DoubleClicked?: does [error?
try [system/script/parent/parent/Parent]]
which can be used in b.r:
if DoubleClicked? [Throw "Please run a.r to start this application"]
There is a lot of magic stuff in the system object. And, as far as I can
tell, very little documentation on it. I know you guys are up to your orbs in
development, but do you have a plan to develop a guide to the system object?
At the very least it'd be gracious if Probe could somehow indicate the a
field is release-dependent. That way, it's my fault if I discover and use a
short-lived data item
Thanks again,
Colin.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted