Current directory and Dialog.RunExternal

[adimetrius]

Colleagues,
by convention, relative paths in BB are evaluated with respect to the BB working directory, thus 'Hr/Demo' stands for 'C:\Program Files\BlackBox\Hr\Demo'.
It seems, however, that Dialog.RunExternal does not fully respect this convention.

When BB is started with the '/USE C:\Herschel' option, the working directory (in terms of BB and Files module) is altered to be C:\Herschel. But Dialog.RunExternal('Hr/Demo/Elf/M.exe') brings up a host dialog box that says Hr/Demo/Elf/M.exe cannot be found. The file is actually found in C:\Herschel\Hr\Demo\Elf\M.exe, but obviously the relative path is evaluated with respect to C:\Program Files\BlackBox, as directed by the .lnk file.
I've looked around, and C:\Herschel (the /USE option) is kept in HostFiles.dir.startup.path: HostFiles.Locator. However it is not available to the programmer: both HostFiles.dir and it's type HostFiles.Directory are not exported.

I can't find a way to figure out the actual working directory of running BlackBox (as directed by the /USE commandline option). Is there one? If I could, I would've used it in calling Dialog.RunExternal.

However, i think that'd be a workaround; a better thing to do, rather, is to make Dialog.RunExternal follow the BB convention and start the passed command in the actual BB working directory.

What do you think? How would such amendment of Dialog.RunExternal affect existing software?

[Zinn]

Hello Adimetrius,
here there are a procedure which gets the working directory of BlackBox:

Code: Select all

	PROCEDURE GetWorkingPath* (VAR workingDir: ARRAY OF CHAR);
		VAR loc: Files.Locator;
	BEGIN
		(* BlackBox Working Directory *)
		loc := Files.dir.This("");
		workingDir := loc(HostFiles.Locator).path + '/';
	END GetWorkingPath;

I hope that helps
- Helmut

[adimetrius]

Helmut,

thank you for your suggestion, I have incorporated it into Herschel. It does look like a hack to me, though; but it seems there's no one to second my suggestion of a more elegant and platform-independent solution?

[Robert]

By coincidence I wanted to ask a question on this subject today, and then found this thread.

I haven't thought about this subject for years, and have forgotten everything I might have known! But I did write the following two routines that might be relevant:

Code: Select all

PROCEDURE  HomePath* (OUT home : ARRAY OF CHAR); (*  Server  *)
  VAR
    res, k  :  INTEGER;
  BEGIN
    res  :=  WinApi.GetModuleFileNameW (0, home, LEN (home));
    k  :=  LEN (home$);
    WHILE (k > 0) & (home [k] # '\')
                  & (home [k] # '/') & (home [k - 1] # ':')  DO  DEC (k)  END;
    home [k]  :=  0X    
  END  HomePath;


PROCEDURE  WorkPath* (OUT work : ARRAY OF CHAR); (*  Client  *)
  BEGIN
    work  :=  Files.dir.This ('')(HostFiles.Locator).path$
  END  WorkPath;

They DO feel like a hack!

Anyway, to my question. I have a (Windows) desktop link with the two fields:
Target: D:\BlackBox\1133\BlackBox.exe /Use D:\BlackBoxClient /PAR "Pipe A"
Start in: D:\BlackBoxClient

I want to do this programmatically, and tried

Code: Select all

Dialog.RunExternal ('D:\BlackBox\1133\BlackBox.exe /Use D:\BlackBoxClient /PAR "Pipe A"')

which seems to work.
So what does the "Start in:" field do? & and how do I make Dialog.RunExternal obey it?

[Robert]

... it seems there's no one to second my suggestion of a more elegant and platform-independent solution?

Actually I would like an elegant solution, but I am so confused by the entire subject I can't tell what is elegant!

I have a language problem: I think I have heard the terms: Home path, Start in path, Client path, Server path, Working path, Target path, Use path, and probably several others ... Scream!

[Zinn]

Dear Robert

BlackBox knows two directories: First the installation directory and second the working directory.
At the normal start of Blackbox the working directory is equal to the installation directory.

You can start BlackBox with the run parameter /use=any-other-directory then Blackbox started in server mode and the working directory is the any-other-directory. Every changes is written into the any-other-directory instead of the installation directory. The installation directory left be unchanged.

Here there is a little program which displays the installation directory including the program name, the working directory and which version of BlackBox are you using.

- Helmut

About.txt

(2.98 KiB) Downloaded 1486 times

[Robert]

This is a quote from "System User Maual" section "Server installation":

3) For each workstation, create a shortcut with the following contents:

Command Line (Target): <BlackBoxDir>\BlackBox.exe /Use <WorkDir>
Working Directory (Start in): <WorkDir>

where <BlackBoxDir> stands for the full path name of the directory where BlackBox is installed (on the server), and <WorkDir> is the path of the working directory of the actual machine (on the client or on the server).

I don't understand:
1 - What does the line "Working Directory (Start in): <WorkDir>" in the desktop shortcut do?

2 - When I use Dialog.RunExternal, rather than clicking a desktop icon, how do I do the same thing as the icon "Start in:" field? Maybe I don't need to, and passing the "Target" field to Dialog.RunExternal is sufficient (it seems to be!).

Thanks

[Robert]

However, i think that'd be a workaround; a better thing to do, rather, is to make Dialog.RunExternal follow the BB convention and start the passed command in the actual BB working directory.?

I am not an expert, so please forgive me if I'm talking nonsense - I'm trying to understand this for myself!

I think your suggestion would make it unnecessary to add "/USE <WorkDir>" to the Dialog.RunExternal string. This seems convenient, but I think it is a bad idea because it would be different to using the string directly from the DOS prompt (I haven't actually checked this!), and that could also be a cause of confusion.

However(I think) it would be a good idea to provide BlackBox procedures that give convenient access to both paths, the path where BlackBox.exe lives, and the <WorkDir>. Helmut & I have given (similar) ways to do this just above, but they do feel like hacks.

[adimetrius]

Colleagues,

Helmut's explanation did help me understand the issue better.

1) All these features 'live' in HostFiles, and HostFiles alone. This means it is not a BlackBox feature, rather, a platform feature (in this case, platform=win32)
2) 'BlackBox installation path' = path where BlackBox.exe resides. This is why Robert was helped by WinApi.GetModuleFileNameW: it does allow to find out where BlackBox.exe resides. This means that 'current directory', 'start in' of the desktop link, etc. have exactly NO relevance. I think the same WinApi call is also used in HostFiles.
3) I find it strange that to specify the working directory you have to use /USE key - I would expect the same term, to keep things simple(r)

I agree with Robert that the offered solutions are not as elegant as we're used to in BB; a more direct and excplicit way of discovering the paths could be a useful feature of HostFiles.

I was surprised to discover (2), because on Linux, the 'blackbox' directory is not necessarily the directory where the BB executable resides. Since i experiment with the Kernel quite a bit, i found it very useful that i could 'disconnect' the executable from the rest of BlackBox repository.

In working on the cross-platform BlackBox, we're experimenting with a three-layer approach. It may be an overkill for a range of applications; so we're keeping it in the platform level (the Host subsystem) and also making sure BB can work with just one or two layers, as is the case with versions <= 1.7