issue-#104 calling URLs and commands (InfoCmds capabilities)

[Ivan Denisov]

http://redmine.blackboxframework.org/issues/104

Many components are using links to Internet pages or to mail applications with "mailto:".

Now several different approaches are coexisting:
InfoCmds.Start (CPC by Zinn)
http://zinnamturm.eu/downloadsIN.htm#Info
i21sysCalls.Open (OberonCore components collection)
http://oberoncore.ru/bbcc/subs/i21sys/calls
CpcCalls.Open (MOLPIT components collection)
http://gitlab.molpit.org/molpit/blackbo ... /Calls.odc

I am suggesting to add such feature to basic BlackBox.

[Zinn]

it is already done in issue-#86 improvements in RTF import.
There Josef adds the HostTextConv.ShellExecute.

Now I know 5 different implementations.
Here they are in the order as long as I know them:
(1) InfoCmds.Start
(2) LibMisc.ShellExecute
(3) i21sysCalls.Start
(4) HostTextConv.ShellExecute
(5) CpcCalls.Open

Why does your CpcCalls.Open uses Actions?
Robert's version shows errors via popup menu.
Which version do you prefer?

- Helmut

[Ivan Denisov]

Actions are required, because without them execution paused until called app will not start.

We can add Open and Start procedures to Dialog. I prepared demo:
http://blackboxframework.org/unstable/i ... a1.431.zip

Now links from About dialog are opening the Internet pages.

Changes:
http://redmine.blackboxframework.org/pr ... 115335d51f

The hook is good choice, because it allow to change realization and block this dangerous call capabilities for applications with critical security.

Code: Select all

TYPE H = POINTER TO RECORD (Dialog.ExtCallHook) END;

PROCEDURE (h: H) Start(c: ARRAY OF CHAR); BEGIN END Start;

PROCEDURE (h: H) Open(c: ARRAY OF CHAR); BEGIN END Open;

PROCEDURE LockExtCalls*;
VAR h: H;
BEGIN
	NEW(h); Dialog.SetExtCallHook(h)
END LockExtCalls;

[Ivan Denisov]

Dear Center members, are there any comments for this issue?

[Josef Templ]

This is too fast.
I cannot look at so many issues in parallel.

- Josef

[Josef Templ]

The redmine issue should be cleaned up.
It should describe the problem not the solution.

Since the issue does not describe the problem I cannot find out what it is all about.
I can guess that it is about opening external links asynchronously.
Then the question arises if this is what the user expects.
Sometimes it may be appropriate sometimes not.
In some situations there will not be a big observable difference.
If you have asynchronous links only you can never make them synchronous,
the other way round would be possible.

The next question is the error handling.
Sometimes you want to get a result code, sometimes
you are happy with a default error reporting or none at all.

The next question is the working directory.
Sometimes it is required to specify the current directory explicitly,
sometimes not.

To summarize, this issue seems not well thought out yet.
For a general purpose feature all the parameters of WinApi.ShellExecute may
be required and this issue is more or less a BB API around ShellExecute.

In my application I had to interface with several external tools and
I always use synchronous operations. I ended up with a procedure like this which was OK for my needs but
it does not cover all params of ShellExecute:

Code: Select all

	PROCEDURE ShellExecute*(op, file, params, dir: ARRAY OF CHAR);

.

- Josef

[Zinn]

Hallo Josef,
Ivan’s aim is to add 2 procedure for easy use

(1) Dialog.Open(fileName: ARRAY OF CHAR); -- which is equivalent to HostTextConv.ShellExecute(path: ARRAY OF CHAR); -- It does not exist in BB 1.6
and
(2) Dialog.Start(exeName: ARRAY OF CHAR); -- which is equivalent to HostDialog.Start(name: ARRAY OF CHAR); -- It is for internal use only in BB 1.6

How to provide this facilities in BB 1.7 ?

As you pointed out the questions are:
Do we need hook?
Do we need asynchronous call?
Do we need error messages?
Or need we 2 simple procedure to do this tasks?

Adding a res return value is not possible, because we would like to use both procedures inside links.
- Helmut

[Robert]

Hallo Josef,
Ivan’s aim is to add 2 procedure for easy use ...

I think we want a third!

For my own use I have a Start command; see below and an example of using it to run the LaTeX equation editor program.
I am not posting this as a good example of how to code it (I do NOT claim to be competent with WinApi), but as an example of the kind of functionality I would like to see as part of BlackBox 1.7 so I can have easy access to a well written version.

The third routine I think is required does not run the program (LaTeX here) but checks if it is available. This provides good feedback before the user tries something that will definitely fail. Again, I have posted an example of the type of thing below.

Code: Select all

PROCEDURE  Start (cmd : ARRAY OF CHAR; showDosBox : BOOLEAN);
  VAR
   info    :  WinApi.STARTUPINFOW;
   res     :  INTEGER;
   proc    :  WinApi.PROCESS_INFORMATION;
   create  :  SET;
   dosCmd  :  ARRAY  256  OF  CHAR;
  BEGIN
    WinApi.GetStartupInfoW (info);
    IF  showDosBox
      THEN  dosCmd  := 'cmd /k ' + cmd; create  :=  {}
      ELSE  dosCmd  :=  cmd$; create  :=  WinApi.CREATE_NO_WINDOW
    END;
    res   :=  WinApi.CreateProcessW (NIL, dosCmd, NIL, NIL, WinApi.FALSE,
                                         create, 0, NIL, info, proc)
  END Start;


PROCEDURE  TexToDvi*;	(*  Converts .tex to .dvi  *)
  BEGIN
    Start ('latex' + latexOpts + pathName, showDvi IN dlg.opts)
  END  TexToDvi;

Code: Select all

PROCEDURE  PathFindOnPathW* (file : Win.PtrWSTR; VAR [nil] dirs : Win.PtrWSTR) : Win.BOOL;

-----  Separate Module ----

PROCEDURE  Find (IN name : HostFiles.FullName; OUT isOk : BOOLEAN) : BOOLEAN;
  VAR
    res  :  INTEGER;  (*  Idea from Bernhard Treutwein, January 2009  *)
  BEGIN
    IF  Shlwapi.PathFindOnPathW (name, NIL)  #  WinApi.FALSE  THEN   RETURN  TRUE
    ELSE
      Dialog.GetOK ('Failed to find : ' + name,
        '', '', '', {Dialog.ok, Dialog.cancel}, res);
      isOk  :=  res  =  Dialog.ok;
      RETURN  FALSE
    END
  END  Find;

[Ivan Denisov]

Since the issue does not describe the problem I cannot find out what it is all about.
I can guess that it is about opening external links asynchronously.

To summarize, this issue seems not well thought out yet.
For a general purpose feature all the parameters of WinApi.ShellExecute may
be required and this issue is more or less a BB API around ShellExecute.

This issue is adding feature of opening URLs to BlackBox. Also exe call is implemented more safe way for developer can block or filter such calls. I made HostDialog.Start private and removed HostTextConv.ShellExecute. They were the holes in security.

This realization was shaped by OberonCore team: http://oberoncore.ru/bbcc/subs/i21sys/calls (It includes also the hack for Wine).

I think that the basic idea is quiet clear. It is not the wrapper around ShellExecute. Running of EXE files is done by CreateProcessW function.

[Ivan Denisov]

I think we want a third!

With suggested realization (ExtCallHook) you can use several realizations of Dialog.Start exchanging them by installing different hooks (Dialog.SetExtCallHook). So I think that we do not need to add some specific cases. This Start is simple as possible and it inherits the 1.6 HostDialog.Start implementation. So better to keep it as it is.