hasvalue does not allow tags

Started by lbo, November 04, 2018, 09:23:18 AM

Previous topic - Next topic

lbo

Hi Mario,

as you suggested in https://www.photools.com/community/index.php?topic=8420.msg59169 I post the bug report:

"hasvalue" does not allow tags. Instead of parsing them, it simply passes the tag source. The hasvalue counterpart "default" does support tags. Examples:

"default" works:
{File.MD.XMP::exif\GPSDestLatitude\GPSDestLatitude\0|default:x<Bold>x</Bold>x}

"hasvalue" works not (tag source is output instead of bold formatting):
{File.MD.XMP::exif\GPSDestLatitude\GPSDestLatitude\0|hasvalue:x<Bold>x</Bold>x}

A workaround is to output a placeholder text with "hasvalue" and use "pereplace" to make a tag from it:

{File.MD.XMP::exif\GPSDestLatitude\GPSDestLatitude\0|hasvalue:substme;pereplace:substme==x<Bold>x</Bold>x}

Oliver

Mario

#1
By default, variables replace unsafe characters like < and > and & when used in a XAML context for safety. That's why pereplace exists.

I've checked your variable

{File.MD.XMP::exif\GPSDestLatitude\GPSDestLatitude\0|default:x<Bold>x</Bold>x}

in the Var Typ app and it correctly returns

x<Bold>x</Bold>x

when the file has no GPS data. When you use this in a XAML context (e.g. file window tooltip or panels) IMatch will make the var parser to escape all unsafe characters for XAML so the output will be xXx (with a bold X). The same happens when you use this in a custom template in a file window layout. This will produce a bold X as well. See:

-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

lbo

default allows tags. Using tags in default is suggested in https://www.photools.com/3906/custom-icons-file-window/

hasvalue is the counterpart of default so it should work the same.

In https://www.photools.com/community/index.php?topic=8420 you asked me to file a bug report:
QuoteOpen a bug report. I can then spend time with this for one of the next releases.

That's what I did now.

Oliver

Mario

hasvalue allows for tags like < and > as I demonstrated above.
I don't understand the problem, sorry.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

lbo

This is the code to check in a in custom template of a file window layout:

{File.MD.XMP::exif\GPSDestLatitude\GPSDestLatitude\0|hasvalue:x<Bold>x</Bold>x}

Oliver

Mario

Works. The output is x <Bold> x </Bold>. In a XAML content, characters unsafe for XAML usage like < and > and & are automatically sanitized. hasvalue has no special logic to overcome this, of this is what you are expecting.

From the help: IMatch already escapes variables in features which use XML or XAML (e.g. file window tip or slide show overlays or text export).

Otherwise tag data (or other variable content) containing unsafe characters like < or > or "John & Jill" will break file window layouts, file window tips etc because it produces invalid XAML.
The pereplace variable function can be used to overcome this, see the help for more info.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

lbo

In your post 2018-11-04, 09:52:48 you write that rendering the bold tag (IOW outputting a bold X) is the correct behaviour of default.

In your post 2018-11-06, 10:12:51 you write that outputting the tag source "x<Bold>x</Bold>x" is the correct behaviour of hasvalue.

What is the reason behind treating "default" and "hasvalue" different?

To me, hasvalue and default are exact counterparts and I see no reason whether they shall treat tags different.

Oliver

Mario

#7
I have no idea, this code is two years old. I dont know, too many users want too many different things at the same time, from totally remote parts of the application.
I will look into this and may fix the default. hasvalue is processed much earlier in the queue and will be sanitized. Maybe I have added this default handling as a special case for some users. I don't know at the moment.

I doubt that this problem affects many users and so I will keep this in the bug report list for when there is more time.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

sinus

From my point of view it is indeed the case, that not a lot of users will affect this.
There is a "workaround" for this, like Oliver wrote, quite a long time and this works nice.

My impression is, every time, if you change this variables-stuff for users (including my wishes in the past  8)), I had to edit a lot of variables, because they worked not more.
That is why I understand nowadays, that you must be careful to change things.
Best wishes from Switzerland! :-)
Markus

Jingo

Quote from: sinus on November 06, 2018, 01:22:59 PM
From my point of view it is indeed the case, that not a lot of users will affect this.
There is a "workaround" for this, like Oliver wrote, quite a long time and this works nice.

My impression is, every time, if you change this variables-stuff for users (including my wishes in the past  8)), I had to edit a lot of variables, because they worked not more.
That is why I understand nowadays, that you must be careful to change things.

The Mantra of programming... one change here can have a cascade affect on other parts of the software downstream... sometimes in places where you least expect it! 

lbo

Quote from: Mario on November 06, 2018, 01:08:33 PM
I will look into this and may fix the default. hasvalue is processed much earlier in the queue and will be sanitized. Maybe I have added this default handling as a special case for some users. I don't know at the moment.

See https://www.photools.com/3906/custom-icons-file-window/ before you remove tag evaluation from "default".

Quote from: Mario on November 06, 2018, 01:08:33 PM
I doubt that this problem affects many users and so I will keep this in the bug report list for when there is more time.

You asked me to file this bug report. I don't need it (anymore) but I feel it would be the right thing to make hasvalue behaving like default.