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.
Application.Current
in
https://github.com/elmish/Elmish.WPF/blob/3f0d3552203dcf3152f1088014ee608f2926f8a9/src/Elmish.WPF/ViewModel.fs#L199
was 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
https://github.com/elmish/Elmish.WPF/blob/3f0d3552203dcf3152f1088014ee608f2926f8a9/src/Elmish.WPF/Program.fs#L36-L40
creates an 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 let
-bound Application
instance like
type CurrentApplication()
let value =
let current = Application.Current
if isNull current then Application () else current
Then we replace all references to Application.Current
with 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
Dispatcher
instance 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.
https://stackoverflow.com/questions/20025143/application-current-dispatcher-vs-dependencyobject-dispatcher-for-ui-thread-acce
http://dotnetpattern.com/wpf-dispatcher
Related questions
No questions were found.