Page 6 of 10
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Thu Mar 17, 2016 10:45 am
by Ivan Denisov
Josef Templ wrote:Therefore I would suggest to add a trivial HostDialogs.Start as shown below.
Code: Select all
PROCEDURE Start*(name...); (* for backwards compatibility with BlackBox 1.6 *)
BEGIN Dialog.Run(name)
END Start;
This is debatable. From one hand there is compatibility, from another — the fix in the third party sources is obvious, so we can include this in some migration documentation.
If we will just add the code in sources and delete nothing BlackBox will grow as snowball.
For preventing mess (as it was with the previous voting) I am suggesting to here some more opinions here. And then if few members more will support this, we will add one simple procedure as an hot fix of master branch.
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Thu Mar 17, 2016 11:42 am
by Josef Templ
Ivan Denisov wrote:
This is debatable. From one hand there is compatibility, from another — the fix in the third party sources is obvious, so we can include this in some migration documentation.
I am not concerned about any required source code changes but about using HostDialog.Start
in links stored somewhere in text documents. They cannot be fixed.
- Josef
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Fri Mar 18, 2016 7:40 am
by Ivan Denisov
Josef Templ wrote:
I am not concerned about any required source code changes but about using HostDialog.Start
in links stored somewhere in text documents. They cannot be fixed.
Do you mean that this documents already somehow distributed and will be opened with 1.7 version later by some clients? So the developer has no access to this documents... In that case of course we should add this procedure. However does this really occurring?
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Fri Mar 18, 2016 9:03 am
by Josef Templ
Exactly.
> Is it occuring?
Nobody knows that precisely.
Generic rule to apply in that case: When in doubt, don't change.
This rule helps a lot for keeping the system and the persistent data stable.
"Start" added in issue-#104a.
For me this would now be ready for voting.
- Josef
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Fri Mar 18, 2016 12:16 pm
by Ivan Denisov
Josef Templ wrote:For me this would now be ready for voting.
The voting for merging 104a
is going. It would be nice if you support it. I am glade that you led my
suggestion about hot fix in the master and made the mess with voting again
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Mon Mar 21, 2016 4:52 pm
by Ivan Denisov
Zinn wrote:Why don’t we use the old implementation of the equivalent procedure until we all agree with the new implementation?
First I suggested to use an old implementation with Actions, however there were a lot of critics because of using them. The idea of actions is that they providing no BlackBox hanging up while start of applications. Then Alex Ilyin gave the idea of using threads as an alternative to Actions, because they solve the problem even better. Start process not pending by actions DoLater call. It is going in separate thread.
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Mon Mar 21, 2016 8:39 pm
by Robert
I have just tested the "Run" procedure in version 455.
I don't know enough to sensibly comment on the implementation; it seems to work fine.
But I don't like the function. It opens the "Dos Box" where the application makes some report, then closes it before anyone can read the report.
Please, can we make up our minds:
Either:
- Don't open this window
- Or let us read it
- Or give us the option.
Personally I want the option.
To keep the usual interface simple maybe Dialog could have a read/write BOOLEAN variable flag "openDosBox" which a calling application can set if it wants to. To make the procedure repeatable this flag could be automatically cleared every time Run is called.
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Tue Mar 22, 2016 4:47 am
by Ivan Denisov
Robert, some extra behavior can be obtained with exchanging a hook for external calls. In your case for latex you can use WinApi.SW_HIDE option (+ yours WinApi.CREATE_NO_WINDOW).
Code: Select all
MODULE ToolsSilentExtCall;
IMPORT SYSTEM, WinApi, Dialog;
TYPE
ExtCallHook = POINTER TO RECORD (Dialog.ExtCallHook) END;
CallName = ARRAY [untagged] 8191 OF CHAR;
CallNamePtr = POINTER TO CallName;
VAR
callNameTaken: BOOLEAN;
lastresult-: INTEGER;
PROCEDURE Open (lpParameter: INTEGER): INTEGER; (* runs in a thread *)
VAR
fileNamePtr: CallNamePtr; fileName: CallName;
hinst: WinApi.HINSTANCE;
BEGIN
fileNamePtr := SYSTEM.VAL(CallNamePtr, lpParameter);
fileName := fileNamePtr$;
callNameTaken := TRUE;
hinst := WinApi.ShellExecuteW(0, "open", fileName, NIL, NIL, WinApi.SW_SHOW);
RETURN 0
END Open;
PROCEDURE (h: ExtCallHook) Open* (IN fileName: ARRAY OF CHAR);
VAR t: WinApi.HANDLE; res: WinApi.BOOL;
win_fileName: CallName;
BEGIN
IF Dialog.IsWine() THEN (* for security: prevent executing arbitrary commands including arguments *)
win_fileName := "winebrowser " + fileName$
ELSE
win_fileName := fileName$
END;
callNameTaken := FALSE;
t := WinApi.CreateThread(NIL, 4096 * 4, Open, SYSTEM.ADR(win_fileName), {}, NIL);
IF t # 0 THEN
WHILE ~callNameTaken DO
WinApi.Sleep(1)
END;
res := WinApi.CloseHandle(t)
END
END Open;
PROCEDURE Run (lpParameter: INTEGER): INTEGER; (* runs in a thread *)
VAR
exeNamePtr: CallNamePtr; exeName: CallName;
info: WinApi.STARTUPINFOW; process: WinApi.PROCESS_INFORMATION;
BEGIN
exeNamePtr := SYSTEM.VAL(CallNamePtr, lpParameter);
exeName := exeNamePtr$;
callNameTaken := TRUE;
WinApi.GetStartupInfoW(info);
info.wShowWindow := WinApi.SW_HIDE;
lastresult := WinApi.CreateProcessW(NIL, exeName, NIL, NIL, WinApi.FALSE, WinApi.CREATE_NO_WINDOW, 0, NIL, info, process);
RETURN 0
END Run;
PROCEDURE (h: ExtCallHook) Run* (IN exeName: ARRAY OF CHAR);
VAR t: WinApi.HANDLE; res: WinApi.BOOL;
BEGIN
callNameTaken := FALSE;
t := WinApi.CreateThread(NIL, 4096 * 4, Run, SYSTEM.ADR(exeName), {}, NIL);
IF t # 0 THEN
WHILE ~callNameTaken DO
WinApi.Sleep(1)
END;
res := WinApi.CloseHandle(t)
END
END Run;
PROCEDURE Init*;
VAR extCallHook: ExtCallHook;
BEGIN
NEW(extCallHook); Dialog.SetExtCallHook(extCallHook)
END Init;
END ToolsSilentExtCall.
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Tue Mar 22, 2016 6:41 am
by Zinn
Ivan Denisov wrote:
IF Dialog.IsWine() THEN (* for security: prevent executing arbitrary commands including arguments *)
Sorry this line does not protect your system. Exchange in your rtf "Virus" file Open against Run and your works on Windows and Wine.
- Helmut
Re: issue-#104 calling URLs and commands (InfoCmds capabilit
Posted: Tue Mar 22, 2016 6:45 am
by Zinn
Ivan Denisov wrote:Zinn wrote:Why don’t we use the old implementation of the equivalent procedure until we all agree with the new implementation?
First I suggested to use an old implementation with Actions, however there were a lot of critics because of using them. The idea of actions is that they providing no BlackBox hanging up while start of applications. Then Alex Ilyin gave the idea of using threads as an alternative to Actions, because they solve the problem even better. Start process not pending by actions DoLater call. It is going in separate thread.
We need not Action and we need not Threads to support the additional function here. It works without them too and the program is easier to understand. Action & Threads don't increase the security.
- Helmut
Remember: I agree with the interface and I don't agree with the implementation here.