question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Question: What is a proper way to deal with OpenFileDialog etc?

See original GitHub issue

Currently I use something like this:

Button.create [
    Button.content "Some text"

    Button.onClick (fun _ ->
        let ctx = System.Threading.SynchronizationContext()
        async {
            let ofd = OpenFolderDialog()
            let window = getWindow()
            let! path = 
                ofd.ShowAsync(window) 
                |> Async.AwaitTask
            do! Async.SwitchToContext ctx
            path
            |> Msgs.SomeMsg
            |> dispatch
        } |> Async.Start
    )
]

but I’m not sure whether this is a good approach or not.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
AngelMunozcommented, Jul 8, 2020

I see, yeah I agree it could couple you to a specific implementation But you can always fallback to use an interface instead of a concrete class (like my example) to make it agnostic to your update function

let update  (msg : Msg) (state: State) (dialogService: IMyDialogService) = 
       match msg with 
       |  OpenWindow ->
            state, Cmd.ofAsync.either dialogService.OpenFolderDialog () OpenFolderSuccess OpenFolderError
       | OpenFolderSuccess path -> { state with path = path }, Cmd.none
       | OpenFolderError ex -> { state with error = Some ex.Message }, Cmd.none

inside the Window constructor, you should be able to get the service you need without worrying about coupling your MVU to your platform

1reaction
FoggyFindercommented, Jul 8, 2020

you can also pass the window as part of the update function and use the Elmish Cmd.ofAsync.* commands

I suppose this approach breaks MVU pattern ? I expect that update function/part will be totally independent from View side.

I.e. in case if I later decide to use Fabulous or Elmish.WPF or anything else then I can switch to it easily. Well, at least in theory.

Buf if I pass Window to the update function then I will be sticked to Avalonia.

Though, this is the first time I use Elmish for my app so I might be wrong 😃

Read more comments on GitHub >

github_iconTop Results From Across the Web

How do you configure an OpenFileDialog to select folders?
I have a dialog that I wrote called an OpenFileOrFolder dialog that allows you to open either a folder or a file. If...
Read more >
My solution to the OpenFileDialog problems (C#)
There are two problems to deal with: 1. The dialog must be run on a separate thread. 2. The dialog must be modal...
Read more >
Customizing OpenFileDialog in .NET
The first problem is that OpenFileDialog is a modal dialog. ... One way to get the handle of the OpenFileDialog is to override...
Read more >
OpenFileDialog Class (System.Windows.Forms)
This class allows you to check whether a file exists and to open it. The ShowReadOnly property determines whether a read-only check box...
Read more >
How to set Open File Dialog path explicitly?
I'm naturally using many applications while working on a project, like FreeCAD, LibreCAD, VLC, SimpleScan, etc. It's frustrating to navigate to ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found