Closed hypetsch closed 4 months ago
Hi @hypetsch, thanks for reporting.
As far as I understand, you are using a ControlTemplate within a Style.
The style is then used e.g. for a Label. I am not sure a Label is a ContentControl (which can have sub-elements).
The error message seems a bit like conflicting FontFamilies from the Label and the IconBlock.
I guess, for styling a label a more simpler way would be to use the "fa:ToText" markup extension, cf.
Hi,
thx for the quick response. After some quick tests it seems that the "ToText approach" fixes our problem, so many thanks for the hint.
...fyi, we are migrating a .Net Framework 4.8 app to .NET8 and therefore switched to your package by trying to keep the changes as small as possible. Btw, as far as we saw it the exception happens during style switch because of "the current style being removed and not the new one added"...
...of course I don't know your library in detail, just thought that it would maybe make sense to set the fontfamily on the OnIconPropertyChanged only if it is not empty. I would asume that this could avoid the exception.
Again, many thx & feel free to close the issue.
@hypetsch great that it helped.
Wow, interesting. I just recently pushed some code changes for updating the package to net8 (did not release yet).
FYI: This is still a bug. I've encountered it several times over the past few weeks, including today.
In one of my debugging sessions, I saw that the font-lookup mechanism (TypefaceFor()
) produced bad results when the Icon
property changed from a real value to None
(i.e., default(IconChar)
). I didn't have time to dig further, but I suspect that's the root cause of this bug, and that the style changes were only triggering that behavior.
I just managed to reproduce it with code that looks like this:
<fa:IconBlock Icon="{Binding SelectedUser.Icon, Mode=OneWay}" />
Importantly, the view model declares SelectedUser
as nullable, and some things do set it to null
:
public User? SelectedUser { ... }
When that property gets set to null — importantly, it doesn't start as null — FontAwesomeSharp then explodes with an empty font-family error, seemingly because Icon
is then default(IconChar)
and it doesn't know what to do with that.
I successfully fixed my local case by declaring a FallbackValue
, which avoids the transition-to-default that seems to be the root cause:
<fa:IconBlock Icon="{Binding SelectedUser.Icon, Mode=OneWay, FallbackValue=CircleQuestion}" />
While that workaround does work, it's probably worthwhile for someone more familiar with the logic of it to dig into TypefaceFor()
and figure out why it can't handle the default properly, but I think that's the actual cause of this bug.
Hope this helps!
Hi @seanofw ,
Thank you for digging deeper and sharing your insight. 👍
Makes totally sense! default(IconChar) ~ enum-defaults always fall back to numerical zero which blow up then! At first glance I would suggest to return a "null-Image" in this case.
Feel free to reopen and/or submit a PR.
I'm not entirely sure as to the expected behavior, but do you think the fix could be as simple as just changing this
internal static Typeface TypefaceFor(IconChar iconChar)
{
return Orphans.Contains(iconChar) ? null : Typefaces.Find(iconChar.UniCode(), out _, out _);
}
to
internal static Typeface TypefaceFor(IconChar iconChar)
{
return Orphans.Contains(iconChar) ? Typefaces[0] : Typefaces.Find(iconChar.UniCode(), out _, out _);
}
? That would change the semantics slightly, in that TypefaceFor() would no longer return null to indicate failure, but reading through the usages, maybe there's no actual need to indicate "failure" in this case: Having IconChar.None
map to character code 0 of any of the actual fonts might be good enough: That character code is likely unmapped, so you'd end up with either nothing at all being displayed, or a missing-character rectangle, both of which would be more reasonable than a crash.
Almost. I guess the right part can return "null", i.e. Typefaces.Find(...). One of the skipped out-vars will probably be a boolean indicating if found or similar. In any-case we can check the return value or shorten it like this
return (Orphans.Contains(iconChar) ? null : Typefaces.Find(iconChar.UniCode(), out _, out _)) ?? Typefaces[0];
Describe the bug Not sure if we are using the library wrong but applying an icon through style resources results in a System.ArgumentException in
FontAwesome.Sharp.IconBlockBase.OnIconPropertyChanged
To Reproduce Created a sample app to reproduce the issue: https://github.com/hypetsch/FontAwesome.Sharp.TestApp
Expected behavior Style should be applied without exception.
Additional context Stacktrace of the exception: