Bug when running TextPipe filter as shell extension

[dfhtextpipe]

In recent months, TextPipe has exhibited the unintended processing of all matching files found in %USERPROFILE%
even though the filter has been started as a Windows shell extension to process a file in a completely different folder.

To prove this was happening, I created a dummy file to act as bait for this behaviour.
"C:\Documents and Settings\David\Honeypot.txt"

Several of my filter are designed to process files matching *.txt
The output file extension gets changed by one such filter to .vpl.txt

Selecting a file elsewhere (even on another drive) and using the Windows shell command to select the required filter,
I find that repeated starts produce more and more unwanted output files in my userprofile, even though I had not selected anything there!
I end up with

Honeypot.vpl.txt
Honeypot.vpl.vpl.txt
Honeypot.vpl.vpl.vpl.txt

etc.

This is really weird behaviour that should not occur. How can this be prevented?

Best regards,
David Haslam

[DataMystic Support]

Hi David,

A shell extension filter should NOT specify any filenames as these get overridden by what you choose within Windows Explorer.
- Perhaps we should change TextPipe to remove any existing files in the list first?

In v8.4 TextPipe's file list is NOT processed relative to the current path, hence the default dir is probably your user folder.
In 8.4.1 these can will relative to the filter location. If you specify files from the command line then they are relative to the current folder.

Naturally you will end up with repeated files, because
Honeypot.vpl.txt also matches your file wildcard of *.txt - so you will get a new output file for each.

[DataMystic Support]

Please try the TextPipe Pro 8.4.1 beta in the secure area

[dfhtextpipe]

I don't have a license for the Pro edition.

David

[dfhtextpipe]

Dear Simon,

You wrote, "- Perhaps we should change TextPipe to remove any existing files in the list first?"

I think something should be done to warn the user when any filter specified as a Shell extension has any active entries in the files list.

Perhaps there should be an option in Preferences to ignore all entries in the files list when the filter is started as a Shell extension?

Best regards,
David

[DataMystic Support]

Or perhaps /CLEARFILES should be defaulted in the Shell Ext dialog to remove the existing files?

[dfhtextpipe]

That would not make sense - you can be editing the Shell Extensions with other filters open in TextPipe that are not called by Windows Shell.

The user would be confused, and you could end up removing files for the wrong filters.

I still think that an automatic ignore for specified files would be preferable when TextPipe is called by a Shell command.

David

[DataMystic Support]

Or perhaps /CLEARFILES should be defaulted in the Shell Ext dialog to remove the existing files?

I mean this command line option could be defaulted in the dialog to automatically remove the files. The user could remove it if they wished. Your thoughts?

Did you see the new version of this dialog?

[dfhtextpipe]

Dear Simon,

I hadn't understood you before.

/CLEARFILES can be specified in the fourth column of the Shell extensions dialogue, separately for each filter.

Now that I realize what you meant, yes - I agree that this would be a useful default.

The change should be carefully explained in release notes.

Best regards,
David Haslam

[DataMystic Support]

Ok how about a warning in the status log if a command line has existing files in its Files To Process list?
e.g.

Code: Select all

Warning - Files specified in the Files to Process list of this filter have been ignored

or

Code: Select all

Warning - Files found in the Files to Process list of this filter

[dfhtextpipe]

Simon,

The first proposal is one I would prefer.

David.

[DataMystic Support]

As it turns out, TextPipe has no way to distinguish filters triggered from a Shell Extension versus filters run from the command line.

We're adding a new command line option /fromshellext so that it can detect this.

[DataMystic Support]

This is now ready in 8.4.2.