"Open with..." with a switch, how to?

[DNSB]

Originally Posted by RbnJrg

I made a bat file with the following command:

MyProgram.exe -u %1

and I saved all as "MyBat.bat". If I drop a .xhtml file on that .bat, all works fine but if I want to proccess a .xhtml file with the same .bat by means of "Open with..." nothing happens. What am I doing wrong?

Since you mentioned that the batch file and the executable file are in the same directory, could you try modifying the batch file to:

%~dp0MyProgram.exe -u %1

The %~dp0 variable points to the drive and path of the batch file which is the same location you have the .exe file located. Otherwise, you'll need to either have the path to the executable in one of Window's path variable or specify the full path to the the executable.

[DiapDealer]

I fear the situation is much more dire. In fact, I'm honestly not certain .bat|.cmd files ever worked with the Open With feature before Windows 10. Something with Windows 10 seems to have changed, but all examples of using QProcess::startDetached() to run batch files on Windows that I've run into seem to suggest that it's "cmd.exe" that needs to be launched. And that the batch file needs to be one of the arguments to cmd.

Something like:

return QProcess::startDetached("cmd.exe", {"/k", "C:\Path\to\mybatchfile.bat"}, "C:\Working\Dir");

If true... then the Open With feature of Sigil is going to need a bit of an overhaul to support launching exes AND bat|cmd files on all supported versions of Windows.

[RbnJrg]

Originally Posted by DNSB

Since you mentioned that the batch file and the executable file are in the same directory, could you try modifying the batch file to:

%~dp0MyProgram.exe -u %1

The %~dp0 variable points to the drive and path of the batch file which is the same location you have the .exe file located. Otherwise, you'll need to either have the path to the executable in one of Window's path variable or specify the full path to the the executable.

Many thanks but also it failed

[RbnJrg]

Originally Posted by DiapDealer

I fear the situation is much more dire. In fact, I'm honestly not certain .bat|.cmd files ever worked with the Open With feature before Windows 10. Something with Windows 10 seems to have changed, but all examples of using QProcess::startDetached() to run batch files on Windows that I've run into seem to suggest that it's "cmd.exe" that needs to be launched. And that the batch file needs to be one of the arguments to cmd.

Something like:

return QProcess::startDetached("cmd.exe", {"/k", "C:\Path\to\mybatchfile.bat"}, "C:\Working\Dir");

If true... then the Open With feature of Sigil is going to need a bit of an overhaul to support launching exes AND bat|cmd files on all supported versions of Windows.

But the "Open With" feature is there from years. Someone before must have faced the issue of running a program with a switch, from Sigil, and under Windows 7. So, if it were an old "bug" (it doesn't seem a bug according to your words), already someone would have written about it.

[BetterRed]

Originally Posted by RbnJrg

But the "Open With" feature is there from years. Someone before must have faced the issue of running a program with a switch, from Sigil, and under Windows 7. So, if it were an old "bug" (it doesn't seem a bug according to your words), already someone would have written about it.

I use open with quite a bit for editing embedded images and mp3s - especially now I can have up to five editors per file type. I occasionally edit xhtml with Notepad++ (or Bowpad if I'm bored), or now PageEdit. But I've never wanted to pass any extra arguments to any of my external editors.

I doubt more than 20% of Sigil users use the Open With feature. And some people, including me on occasions, just shrug when something doesn't work and find another way. Not saying that's what you should do - just saying I'm not surprised it hasn't been reported until now.

BR

[DiapDealer]

You're the first person (@RbnJrg) I can recall having ever asked about launching external programs with additional parameters.

Besides ... it wouldn't be the first time a different version of Qt behaved differently than the previous one. We haven't been building Sigil with 5.12.3 for very long in the grand scheme of things. It's entirely possible it may worked with Qt5.6.3 on Windows 7. Who knows.

The point is that we allow Windows users to select bat and cmd files for Open With, so it either needs to work (on all supported versions of Windows) or we need to limit Open With to exes.

[DiapDealer]

For what it's worth; subverting the Open With feature to launch batch files, that in turn launched python scripts that could modify the files in Sigil's scratch directory was how I created my first Sigil "plugins"--before there was such a thing as a Sigil plugin framework.

And since I was doing that on Windows Vista, I'm fairly certain Open With was perfectly capable of launching batch files on XP/Vista/Windows 7 at some point (especially considering that the way Open With launches external programs hasn't really changed since its inception). So I'm betting this is Qt's fault.

I've got an idea to fix it, though. Just need to find a little time.

[KevinH]

I am not sure how this works for Windows:

if (QFile::exists(filePath) && QFile::exists(application)) {
        QStringList arguments = QStringList(QDir::toNativeSeparators(filePath));
        return QProcess::startDetached(QDir::toNativeSeparators(application), arguments, QFileInfo(filePath).absolutePath());
    }

According to the docs:

static] bool QProcess::startDetached(const QString &program, const QStringList &arguments, const QString &workingDirectory = QString(), qint64 *pid = nullptr)

This function overloads startDetached().

Starts the program program with the arguments arguments in a new process, and detaches from it. Returns true on success; otherwise returns false. If the calling process exits, the detached process will continue to run unaffected.

Argument handling is identical to the respective start() overload.

The process will be started in the directory workingDirectory. If workingDirectory is empty, the working directory is inherited from the calling process.

If the function is successful then *pid is set to the process identifier of the started process.

See also start().

the third parameter is the working directory the application should be started from. Doesn't it need to be converted to native separators too?

As I read the Qt docs, this will change to that working directory, before launching the application (full path to the application) with the arguments being the full absolute path to the file to be edited.

Not sure what would happen if working directory was given with forward slashes. If wherever that ends up, the user has no executable or write permissions, it would fail I think?

Not sure why this works in Windows 10 unless the working directory parameter is massaged somehow.

Or am I missing something?

[DiapDealer]

I don't think you're missing anything. That overloaded function has been used the way it's being used since Open With began. And as I mentioned, I know it has worked with .bat files on other versions of Windows in the past. So I think it's probably just Qt being stupid for some reason with 5.12.3.

I'll see if converting the 3rd parameter to native separators makes any difference.

[DiapDealer]

I think I have this fixed now in the master branch. @RbnJrg: PM me if you want a beta-build of Sigil to test-drive.

[RbnJrg]

Originally Posted by DiapDealer

I think I have this fixed now in the master branch. @RbnJrg: PM me if you want a beta-build of Sigil to test-drive.

Great!!