Please compare the MainWindowViewModel code with the screenshot of the application:

Note how there is roughly a 1:1 mapping between the controls on the GUI and the members of the MainWindowViewModel. There are different types of members:

• Properties, the values of which are directly shown and sometimes also edited on the GUI:

  • Title

  • ListeningPort

  • ProviderHostName

  • ProviderPort

  • LogFolder

  • AutoScrollToMostRecentEvent

  • Events

  • SelectedEvent

  • SelectedEventDetail

• Properties, the values of which contain other properties, which in turn are shown on the GUI:

  • ConsumerConnection

  • ProviderConnection

• Properties, the values of which are used to define how the controls behave:

  • CanEditSettings: Defines the value of the IsEnabled property of the TextBox controls for Listening Port, Provider Host Name and Provider Port as well as the ... Button.

  • CanStart: Defines the value of the IsEnabled property of the Start Button.

  • CanStop: Defines the value of the IsEnabled property of the Stop Button.

  • CanLoadFullEventDetail: Defines the value of the Visibility property of the Load Full Event Button.

• Methods, which are called when the user makes an input:

  • Start(): Is called when the Start Button is clicked.

  • Stop(): Is called when the Stop Button is clicked.

  • LoadFullEventDetail(): Is called when the Load Full Event Button is clicked.

  • SaveSettings(): Is called when the x in the top-right corner of the application is clicked.

Note

We are deliberately not using an ICommand implementation (usually called DelegateCommand or RelayCommand) to combine e.g. CanStart and Start(). Although doing so would make it slightly easier to bind e.g. a button to a command, providing said command is harder than implementing two methods. For actions that are always available (like e.g. SaveSettings()) we only need to implement one method and by doing so we efficiently communicate that this action is always available.