World: r3wp

something like this

if enface.exe myscript.r  -o myscript.exe [
 myscript.exe
]

but using the cmd shell syntax

I don't think so Graham. Normally I do it all from REBOL and wait 
for the output file to appear.

When I launch an encapped script (.exe) from AltME, I get it run 
from a parent parent .. directory, like the root of the world, rather 
than the directory the .exe is in, but with .r I get the real current 
directory.  Is there a way to get the real directory easily from 
the encapped script (.exe)?

Try system/options/path.

Or failing that, first split-path system/options/boot ; they should 
be the same.

yes, first one fails, so I have to split-path on the second.  Thanks.

I was just guessing :)

I had to do some conditionals to make it operate the same as a script 
vs. .exe but I think I have that working.

How does the first one fail? What does system/options/path turn out 
to be?

The Script.r works from current directory, no monkey-shines (if I 
use system/options/boot then it uses the diretory where View is) 
encapped script.exe uses


change-dir first split-path system/options/boot ;so it then thinks 
it's in the same folder as the script.r which in fact is actually 
is.

...comes from studying script.r (religious joke)

Which folder do you need? The system/options/path is supposed to 
be the current directory from which you started the script. Is that 
the case with a encapped script?

(remember I am launching it from AltME...so there is an extra level 
of cornfusion)

It seems to think it is in the altme-root of the world.

so systems/options/path was not the same even though they were synce'd 
in the same AltME files/folder

I suspect that AltME is starting applications from its current directory 
(the root dir of the world), while starting documents from their 
directory. A REBOL script is just a document as far as AltME is concerned.

In that case the script.r was right, but the script.exe was giving 
the C:/program files/alme/worlds/gop-gasflation/   instead of  C:/program 
files/alme/worlds/gop-gasflation/files/folder

Yeah, so we have to blame both.

I suspect that applications are started using call and scripts with 
shellexecute.

you _are_ a supicious person, aren't you.  Comes from dealing with 
software.  I know it jaded me, too.

Diagnosis is detective work :)

but in America, we cannot execute shells because of suspicion, we 
must call for proof by the script of the law.

anyway, I did do a conditional run so the code works both ways, except 
that I have to edit the script to make it encap.  ( #include %view.r 
 ;that sort of thing)

Not sure, but I may have planted the initial seed for SDK...I was 
raving to Carl about the MKS toolkit awkc (awk compiler).  However, 
for awkc I don't have to edit the awk script before compiling.

Do you want the current directory or the script directory? For the 
script directory, try system/script/path.

The current is system/options/path.

I want it to run and process files in the current directory.  However, 
I already been there, done that, and it ain't worked.

I fixed by doing this:

either none? find system/options/boot "imagesave.exe" [ 
	print %. ;script
][
	print change-dir first split-path system/options/boot ;encap
]

the prints were only there to be sure.

If you run a program by double-clicking it from explorer, the working 
directory is set to the directory the program is in. Otherwise the 
working directory is either the directory you are in in the command 
prompt, that set in the shortcut properties, or the working directory 
in your program you are starting the program from. I use this to 
make file management tools that work on the current directory all 
of the time.

Apparently the system/script settings aren't getting set from encapped 
apps (after testing). The system/options/path setting is the current 
directory that the program or script is called from, while system/script/path 
is the current directory inside REBOL. When REBOL runs a script it 
sets the system/script settings a little different that it does when 
the script is encapped, but the system/options settings are basically 
the same, with the exception of the name of the file in system/options/boot. 
If you want to distinguish between the two situations, check for 
whether system/options/script is a file (script) or none (encapped).

Keep in mind that the "current directory" of REBOL is different from 
that of Windows, and both can be different from the directory the 
program or script is in. Pick the directory you want to use and go 
for it.

If you want the script/program directory, try this:

 change-dir first split-path any [system/options/script system/options/boot]

that's essentially what I am doing. There are these gotchas in the 
SDK that surprise you when your script works, you build and it breaks. 
 awkc doesn't do that.  That's what I was saying...just some feedback, 
ya know.

How do you change the publisher(?) information on an .exe produced 
with SDK? (So it doesn't say "REBOL Technologies...")   I remember 
doing it before with some tool, but I can't seem to find it at the 
moment.

You need to edit the VERSIONINFO resource.

Are there any good freeware tools to do this?

ResHacker has been around for a long time. Unsupported now, but works 
against most PE files. ResourceTuner seems more up to date, but costs 
(they have a trial I think).


There are some other links here: http://www.thefreecountry.com/programming/resourceeditors.shtml

http://www.dobeash.com/RebGUI/cookbook.html#section-2.3

Could anyone explain, what does following stupid hack mean?


;-- Must be done prior to loading anything that requires fonts on 
Linux.

layout [text "imanXwin kludge"] ;-throw this one away soon-- okay?

open-events

It actually prevents SDK from rebface + rebgui usage. So instead 
of fixing crashes we do like above?

IIRC, it initializes X or something.

what about changing the hack to the resulting layout object. shouldn't 
that work the same way?

http://en.wikipedia.org/wiki/Kludge

hmm, interesting henrik, it could work .... so you think that e.g. 
make face! or rebgui equivalent should be sufficient?

well, LAYOUT is a mezz and everything that happens to build that 
face is a mezz, so there should be a way to extrapolate a new hack 
that doesn't require VID.

the way I see it, try a simple make face [text: "simplerhack" font: 
make face/font []] I don't know if the font object is directly available 
in rebface, but try it.

ok, but when my friend on linux commented those lines out, it crashed. 
The question is why? Isn't rebgui initialising x-win in some way 
too?

I will try to look for some equivalents and let my friend to try 
it ....

actually I think it is. when we were fixing 2.7.6 for OSX Leopard 
we had a very similar problem and I had to build rebface with a face 
that loaded a font. it was done entirely without VID.