Ask questionsReferences to Application.Current
This is the issue I promised in https://github.com/elmish/Elmish.WPF/pull/201#issue-402463416 that I would create.
null when processing an initial state as described in #200. Indeed, this property is static with a private setter. The fix in PR #201 implies to me that the constructor of
Application sets that static property (probably like
Current = this). So that PR is a bug fix, but I also believe it does not satisfy the principle of least astonishment. I mean, look at how
Application instance and then throws it away. Very unexpected if you ask me.
Instead, I would prefer if we accessed the current
Application instance in a way that I could statically verify in the Elmish.WPF code. There is more than one way to achieve this. Here is the way that I think is best.
We could implement the F#-equivalent of a static constructor to initialize a static
Application instance like
type CurrentApplication() let value = let current = Application.Current if isNull current then Application () else current
Then we replace all references to
CurrentApplication.value. As always, naming is impossibly hard, so we could certainly go with better names.
Answer questions JDiLenarda
Thanks for sharing @JDiLenarda.
While investigating this bug, the thought about which
Dispatcherinstance to use crossed my mind, but I don't know the difference between using one vs another.
My guess is they’re the same, at least as long the program is launched in a STAThread.
Related questionsNo questions were found.