Lazarus GUI app using RunCommandIndir pops up extra window...

[BosseB]

On Windows 7 x64 I have used Lazarus 2.0.0 + FPC 3.0.4 (64 bit) to create a GUI application for editing video files (cut and paste) using ffmpeg as the engine.
My application collects the data for ffmpeg and then launches the work.

The program works as expected except for one annoying thing:
Whenever I call RunCommandInDir() for an ffmpeg operation an ugly black command window pops up for a fraction of a second until a few seconds and then disappears again. Since many operations require several ffpmeg jobs this makes the application look stupid by flipping these windows on all the time...

Is there any way to avoid this to happen? I have searched and asked elsewhere too without result.
Here is one function I use a lot and it pops up the window for every iteration in the loop of cuts..

Code: Pascal  [Select][+][-]

1. function ExtractVideoSection(InputFile, OutputFile: string; Start, Duration: integer; OverwriteOutput: boolean = true): boolean;
2. var
3.   arguments: array of string;
4.   returnstr: string;
5.   executable: string;
6. begin
7.   Result := false;
8.   if not FileExists(InputFile) then exit;
9.   if (not OverwriteOutput) and FileExists(OutputFile) then exit;
10.  
11.   if FileExists(OutputFile) then DeleteFile(OutputFile);
12.  
13.   SetLength(arguments, 10);
14.   executable := 'ffmpeg.exe';
15.   arguments[0] := '-ss';
16.   arguments[1] := FormatTimeDiff(Start);
17.   arguments[2] := '-i';
18.   arguments[3] := InputFile;
19.   arguments[4] :=  '-to';
20.   arguments[5] :=  FormatTimeDiff(Duration);
21.   arguments[6] :=  '-c';
22.   arguments[7] :=  'copy';
23.   arguments[8] :=  OutputFile;
24.   arguments[9] :=  '-hide_banner';
25.  
26.   Result := RunCommandIndir(ExtractFileDir(OutputFile), executable, arguments, returnstr, [poWaitOnExit,poStderrToOutPut]);
27. end;

[ASerge]

Whenever I call RunCommandInDir() for an ffmpeg operation an ugly black command window pops up for a fraction of a second until a few seconds and then disappears again. Since many operations require several ffpmeg jobs this makes the application look stupid by flipping these windows on all the time...

...[poWaitOnExit,poStderrToOutPut,poNoConsole]...

[lucamar]

...[poWaitOnExit,poStderrToOutPut,poNoConsole]...

Which, as you may guess, means: use something like --

Code: Pascal  [Select][+][-]

1.   Result := RunCommandIndir(ExtractFileDir(OutputFile),
2.     executable, arguments, returnstr,
3.     [poWaitOnExit,poStderrToOutPut,poNoConsole]);

[BosseB]

Thanks, using poNoConsole fixed the problem.

However, I had read the help on RunCommandInDir() already and looked at the options too.
They are defined as follows in the Lazarus help page:

type TProcessOptions = set of (
  poRunSuspended,   Start the process in suspended state.
  poWaitOnExit,   Wait for the process to terminate before returning.
  poUsePipes,   Use pipes to redirect standard input and output.
  poStderrToOutPut,   Redirect standard error to the standard output stream.
  poNoConsole,   Do not allow access to the console window for the process (Win32 only)
  poNewConsole,   Start a new console window for the process (Win32 only)
  poDefaultErrorMode,   Use default error handling.
  poNewProcessGroup,   Start the process in a new process group (Win32 only)
  poDebugProcess,   Allow debugging of the process (Win32 only)
  poDebugOnlyThisProcess   Do not follow processes started by this process (Win32 only)
);

I had noted the comment on its applicability (bold and underlined above) and assumed it was not working here since I am building a 64 bit Windows application running on Windows7 x64.
It clearly states "Win32 only"...

So is the help file erroneous, it seems to work fine on Win64....

[lucamar]

You will very frequently find that people talk about "win32" when really referring to "Windows widgetset and API" in general. It's an historical artifact: referring to "win32" vs. "linux-gtk2" vs. "linux-qt", etc.

Most things that the docs (and wiki, and forum posts) talk about being "win32 specific" are really "windows specific" unless otherwise stated ... or unless it's clear that it's different in "win64".

[ASBzone]

I had noted the comment on its applicability (bold and underlined above) and assumed it was not working here since I am building a 64 bit Windows application running on Windows7 x64.
It clearly states "Win32 only"...

So is the help file erroneous, it seems to work fine on Win64....

Win32 was the Windows 32-bit subsystem and APIs in the era of 16-bit Windows (Windows 3.x and Windows for Workgroups v3.11)
Win32s was a slightly modified version of this subsystem

Windows 95 and later continued using the Win32 subsystem, all the way through 2005 when a 64-bit edition of Windows XP was released (and soon after, Windows Server 2003).

In all that time, Win32 has come to be synonymous with "Windows API".   

From a functionality standpoint, Win32 offered a lot more functionality than Win16, whereas 64-bit Windows offers more memory access and (in many places) more performance, but essentially the same features.

[BosseB]

Thanks for the clarification!
All now working as expected 

[lucamar]

Win32 was the Windows 32-bit subsystem and APIs in the era of 16-bit Windows (Windows 3.x and Windows for Workgroups v3.11)
[...etc...]

Not quite. Win32 was used to refer to the Windows NT API, of which a very small sub-set was added to Windows 3.1+ as win32s. Windows 95, 98 and Me used yet another (bigger) subset called WIN32C (for "compact"?)*; they were used to bridge common users (and developers ) from the Windows 3 era to the "everyone uses NT" era, which was achieved with Windows XP.

One has to give it to Microsoft: they do plan way ahead.


(*) Incidentally, that's why almost everone thought OS/2 Warp was better than Windows 95: it's a full-fledged 32-bit OS with the full OS/2 API, IBM's response to Windows NT 3

[metis]

@BosseB

The "ugly black command window" shows Infos about the running FFmpeg-Process, e.g.
about the Progress when a Stream is processed by FFmpeg.

If You'd like to access and display those Infos in Your App even if [poNoConsole] is set, see here:
http://forum.lazarus.freepascal.org/index.php/topic,43411.0.html
-> GoTo "RunFFmpeg".

'RunFFmpeg' is a small Tool to quickly check & run FFmpeg-CommandLines. You can run it with or w/o Terminal.
You can use any Version of FFmpeg's Command Line Tools, static or shared Builds:
[Grab] starts 'ffmpeg.exe' ('ffmpeg.exe' does not only Recordings, so [Grab] is not only for Grabbing),
[Info] starts 'ffprobe.exe',
[Play] starts 'ffplay.exe', each with its corresponding FFmpeg-CommandLine.

Hope this Code is useful for Your App. I wrote it with WinXP 32bit, but it should compile with Win7 64bit, too.
 

[ASBzone]

Not quite. Win32 was used to refer to the Windows NT API, of which a very small sub-set was added to Windows 3.1+ as win32s. Windows 95, 98 and Me used yet another (bigger) subset called WIN32C (for "compact"?)*; they were used to bridge common users (and developers ) from the Windows 3 era to the "everyone uses NT" era, which was achieved with Windows XP.

One has to give it to Microsoft: they do plan way ahead.

Much better recall than I have.    Thanks for the clarification.