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

Merged to the master branch
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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?
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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 :)
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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.
Ivan Denisov
Posts: 1700
Joined: Tue Sep 17, 2013 12:21 am
Location: Russia

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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.
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#104 calling URLs and commands (InfoCmds capabilit

Post 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.
Post Reply