New plugin search operator 'not defined'

[MVV]

To be able to search for files which doesn't have some plugin value we need new search operator like 'not defined' (or 'absent') which will match when plugin returns ft_fieldempty (or maybe also other errors too). E.g. currently it is not possible to search for files w/o product version string - all search operators fail.

[tbeu]

I hope to see this in TC8. Currently there is no workaround to find/select files returning ft_fieldempty.

[tbeu]

Christian, can you please comment on this suggestion.

[ghisler(Author)]

Sorry, TC8 RC1 is now feature-complete, I will not add any new features at this time. I haven't found a good solution for this yet, because not all plugins use the ft_fieldempty result, but return something like an empty string or 0.

[MVV]

Christian, if plugin returns empty string or 0, we can check it using additional check, but we can't check if plugin doesn't return any value at all...

[tbeu]

Sorry, TC8 RC1 is now feature-complete, I will not add any new features at this time.

OK, might be too late for now. But when this feature was first suggested two years ago it was not.
In my case users of my plugin ImageMetaData need to search for image files not containing GPS metadata. There is simply no way or workaround to do so.

[tbeu]

This wish came up again at http://www.ghisler.ch/board/viewtopic.php?t=40861. Any chance to see it implemented in next version?

[ghisler(Author)]

I have re-added it to my list.

[tbeu]

Nice, thanks!

From contplug.h:

Code: Select all

#define ft_nosuchfield -1   // error, invalid field number given
#define ft_fileerror -2     // file i/o error
#define ft_fieldempty -3    // field valid, but empty
#define ft_ondemand -4      // field will be retrieved only when user presses <SPACEBAR>
#define ft_notsupported -5  // function not supported
#define ft_setcancel -6     // user clicked cancel in field editor
#define ft_delayed 0        // field takes a long time to extract -> try again in background

I noticed that I use ft_fieldempty and ft_nosuchfield in a confusing way for ImageMetaData plugin. If a field cannot be found it returns ft_fieldempty whereas it probably shout return ft_nosuchfield?? Not sure what is the appropriate solution here. WDX Guide displays nothing (empty string) for ft_fieldempty but text "ft_nosuchfield" for ft_nosuchfield (and text "ft_fileerror" for ft_fileerror). Therefore, a new search feature might also consider ft_nosuchfield and ft_fileerror beside the proposed ft_fieldempty.

[MVV]

If field is not supported for such format, plugin should return ft_nosuchfield.
If field value is empty, plugin should return ft_fieldempty.
However it is a question which value plugin should return if field is supported but is not present (e.g. in case of optional tags).

[ghisler(Author)]

I guess that the new option should handle both ft_nosuchfield and ft_fieldempty the same way. ft_nosuchfield is meant for the case where you have a plugin supporting multiple file types (e.g. mp3, jpg etc) and ask for a field which isn't supported by that particular file (e.g. ID3 tag in jpg, EXIF in mp3). ft_fieldempty is meant when the field exists (e.g. ID3 in mp3) but is not set, and returning an empty string would be wrong (e.g. numeric field).

[tbeu]

And what about the optional fields (e.g. EXIF in jpg)? ft_nosuchfield or ft_fieldempty? It is matter of taste but I'd prefer ft_fieldempty.

[MVV]

It is good idea to handle both ft_nosuchfield and ft_fieldempty in case of such operator, so it will work with both absent and empty optional fields.

Maybe ft_fileerror should be handled too?

[ghisler(Author)]

No, ft_fileerror is meant for read errors, e.g. because the file is currently opened exclusively in a different program. This doesn't mean that the field isn't present, it could as well be contained in the file (just not accessible).