How to share a single record instance between multiple modules in F#?

I am using WPF/C# for my UI to a F# backend. I am passing multiple delegates to create several windows from the C# code to my main F# program module.

If I had a single record type to hold the function delegates (prior to using invoke); how do I access this record from multiple different F# modules?

As an example, lets say I have this record declared in a top file:

type Windows = {
        createReportMenu: Func<Window> 
        createProgressNote: Func<Window>
        createPatientRegistrationWindow: Func<Window>
    }

And these delegates passed to my main program:

Program.main(MainWindow, () => new ReportMenu(), () => new ProgressNoteWindow2(), () => new PatientRegistrationWindow() )

How do you create a single instance of the record Windows and share it among multiple different F# modules? (Kind of like a Global record ).

Thanks for any help or suggestions.

I have done something very similar in my Elmish.WPF applications. The reason for doing this is that it otherwise becomes an increasingly intolerable nightmare and high-risk activity to manage the passing around of all the window creation functions.

I will share the parts of my source that do this. Let me know if it's not enough detail, and I'll keep editing until it's good enough.

The following is used in one of my Elmish.WPF programs, but I guess it should be usable also in other architectures, e.g. plain code-behind.

In F# I have declared a type WindowCreationService in one place. This is where I keep all the function definitions for creating specific windows from F#.

The nullWindowCreationService is a kind of dummy for use with the design time model in Elmish.WPF, just so that it compiles, but it won't be called. You can leave this out if you don't need it for that kind of use.

type WindowCreationService(skriverValg, snDlg, resDlg, ordDlg, veksleDlg) =
    member val CreateSkriverValgWindow : unit -> Window = skriverValg
    member val CreateSerieNrDialog : unit -> Window = snDlg
    member val CreateReseptAktiveringDialog : unit -> Window = resDlg
    member val CreateOrdreRedigerDialog : unit -> Window = ordDlg
    member val CreateVeksleDlg : unit -> Window = veksleDlg
    static member nullWindowCreationService =
        WindowCreationService(
            (fun () -> failwith "Never called"),
            (fun () -> failwith "Never called"),
            (fun () -> failwith "Never called"),
            (fun () -> failwith "Never called"),
            (fun () -> failwith "Never called")
            )

The C# WPF program uses the F# library with the program's logic. Let's say the program is named MyProgram, and the F# library MyProgram.Models, and it contains a module named Program with a function named main.

The C# program will at some point hand over control to F#. This is the relevant part of how that is done on the C# side. If you use code-behind, then this call is not necessarily done in OnActivated. The oneShot is just there to make sure the call to main is only done once - the first time OnActivated is called.

public partial class App : Application
{
    bool oneShot = false;

    ...

    protected override void OnActivated(EventArgs e)
    {
        base.OnActivated(e);
        if (!oneShot)
        {
            oneShot = true;
            Models.Program.main(mainWindow:MainWindow,
                createSkriverWin:() => new Views.SkriverValg(),
                createSerieNrDialog:() => new Views.SerieNrDialog(),
                createReseptAktiveringDialog:() => new Views.ReseptAktiveringDialog(),
                createOrdreRedigeringDialog:() => new Views.OrdreRedigerDialog(),
                createVeksleCfgDlg:() => new Views.VeksleCfgDlg()
                );
        }
    }

And the main function in module Program in F# looks like this, except for some lines that are specific to my application, and their absence should be irrelevant. That match on klientIni.LogElmishWpf is only there so that I can choose from a setting whether to engage logging or not, which also is only relevant in an Elmish.WPF application.

let main (mainWindow: Window)
        (createSkriverWin: Func<Window>)
        (createSerieNrDialog: Func<Window>)
        (createReseptAktiveringDialog: Func<Window>)
        (createOrdreRedigeringDialog: Func<Window>)
        (createVeksleCfgDlg: Func<Window>)
        =
    let createOwnedWindow (theCreate: Func<Window>) =
        let w = theCreate.Invoke()
        w.Owner <- mainWindow
        w
    let windowCreationService = WindowCreationService(
        skriverValg=(fun () -> createOwnedWindow createSkriverWin),
        snDlg=(fun () -> createOwnedWindow createSerieNrDialog),
        resDlg=(fun () -> createOwnedWindow createReseptAktiveringDialog),
        ordDlg=(fun () -> createOwnedWindow createOrdreRedigeringDialog),
        veksleDlg=(fun () -> createOwnedWindow createVeksleCfgDlg)
        )
    let init = fun () -> MainWindow.init ()
    let bindings () = MainWindow.bindings windowCreationService
    WpfProgram.mkProgram init MainWindow.update bindings
    |> (fun program ->
        match klientIni.LogElmishWpf with
        | true -> WpfProgram.withLogger (TdDesktop.SerilogRouter.getSeriLoggerFactory ()) program
        | false -> program
        )
    |> WpfProgram.startElmishLoop mainWindow

The reason mainWindow (of type Window) was brought over from C#, is that I want all windows to have mainWindow as their owner. That will make it possible that these windows should be centered in their owner window upon creation, which is nice.

If you happen to use Elmish.WPF, you'll likely want to know what happens from here on as well. You see above where the windowCreationService is used.

Next, this is how the function bindings for the MainWindow is declared, and how the bindings there use the WindowCreationService. With the help of a fun and currying, we tag on wcs to these bindings.

let bindings (wcs: WindowCreationService) : Binding<Model, Msg> list =
    [
    ...
        "ProduksjonPane" |> Binding.subModelOpt ((fun m -> m.ProduksjonPane), snd, ProduksjonPaneMsg, (fun () -> ProduksjonPane.bindings wcs))
        "OrdrePane" |> Binding.subModelOpt ((fun m -> m.OrdrePane), snd, OrdrePaneMsg, (fun () -> OrdrePane.bindings wcs))
        "ResepterPane" |> Binding.subModelOpt ((fun m -> m.ResepterPane), snd, ResepterPaneMsg, (fun () -> ResepterPane.bindings wcs))
    ...
    ]

So the bindings function for the MainWindow will pass wcs on to other bindings functions, which again will pass it on to other bindings functions lower down in the hierarchy, as deep as necessary.

If we look at just one of these - the ProduksjonPane bindings - pat of it looks like this.

let bindings (wcs: WindowCreationService) =
    [
        ...
        "SerieNrDialog" |> Binding.subModelWin((fun m -> m.SerieNrDialog |> WindowState.ofOption),
            snd, SerieNrDialogMsg, SerieNrDialog.bindings, wcs.CreateSerieNrDialog,
            onCloseRequested=(SerieNrDialogMsg SerieNrDialog.Msg.Cancel), isModal=true)
        ...
    ]

Here we finally got to see actual use of one of the window creation functions. The wcs.CreateSerieNrDialog is handed over to the Binding.subModelWin of Elmish.WPF, which will use it to create a window at the proper time.

This is an alternative and much simpler way to solve it, as discussed in the comment thread of my first answer.

In the F# project, I have this module before all modules that need access to the wcs declared and initialized here. AutoOpen is used so that there's no need to open or qualify elsewhere to get access to wcs. The function named createWindowCreationService wraps the logic needed to be done from the C# WPF program, so we don't have to fiddle with writing this in C#.

Note in particular that the wcs is declared and initialized with null for the mainWindow and a dummy function that is never called, and this also happens at design time when no call to createWindowCreationService is made. If wcs had just been assigned null, then that would provoke an exception at design time. This is because the bindings refer to wcs.CreateProduktVelgerWindow, and the bindings are used at design time in order to show the window in the designer. Now, the design time is not trying to create a window through wcs, but just trying to get the wcs.CreateProduktVelgerWindow, so has to go through wcs, so therefore this must not be null.

module [<AutoOpen>] TdPakke.Models.Services

open System
open System.Windows

type [<AllowNullLiteral>] WindowCreationService(mainWindow: Window,
        produktVelger: Func<Window>) =

    let createOwnedWindow (theCreate: Func<Window>) =
        let w = theCreate.Invoke()
        w.Owner <- mainWindow
        w

    member val CreateProduktVelgerWindow : unit -> Window =
        fun () -> createOwnedWindow produktVelger

let mutable wcs: WindowCreationService =
    WindowCreationService(null,
        (fun () -> failwith "Never called")
    )

let createWindowCreationService(mainWindow: Window,
        produktVelger: Func<Window>) =
    wcs <- WindowCreationService(mainWindow,
    produktVelger=produktVelger
    );

In the C# WPF project, in the App.xaml.cs, there's this code that initializes the wcs. The createWindowCreationService is called before main, so that wcs is reinitialized before the bindings try to access it.

private void StartElmish(object sender, EventArgs e)
{
    this.Activated -= StartElmish;
    Models.Services.createWindowCreationService(mainWindow:MainWindow,
        produktVelger: () => new ProduktVelger()
        );
    Models.Program.main(mainWindow:MainWindow);
}

It should be easy enough to add more window creation functions as needed. Just look at the other answer to get the hang of it.

I have used named parameters because that's an advantage as the list of functions grows.