This should make it easier to work on the UI of Scratch Link.
Background Info
Windows Forms is the "old" way to do UI in Windows, and WPF is the "new" way (as of 2006 or so). That said, Windows Forms is still popular with developers and is well supported by Microsoft. Some Forms features, such as NotifyIcon, are still missing from WPF and might never be ported over.
Proposed Changes
This PR removes all references to WPF and alters any "WPF style" operations to use the Windows Forms equivalent instead.
Supporting changes:
Updates to the notification icon text are now instigated through an event handler instead of calling Application.Current, which is a WPF-specific feature. I think the event handler approach is better anyway.
I discovered that the JSON library we use wasn't properly registered in packages.config which could cause problems building from scratch. I suspect this was caused by forgetting to check in packages.config in the early days of the project. At any rate, it's fixed now. I kept the same version we were already using.
There are also a lot of changes to boilerplate code here; sorry about that. I made this change by creating a new, empty Windows Forms project in Visual Studio then adding all the necessary parts back in. That approach was much easier than trying to mutate it in place, but it means there's a lot of noise around the signal when looking at the diffs.
Reason for Changes
Since the Windows version of Scratch Link works by placing a NotifyIcon in the Windows notification area, and that feature doesn't exist in WPF, we have no choice but to use Windows Forms. When I first set up Scratch Link I didn't know this so initially I set it up as a WPF application. Later, I used Forms features when it came time to add the notification icon. We don't have any other UI in Scratch Link, so it was a bit silly to have the WPF libraries hooked up. I don't think it was causing practical problems, but it could cause confusion for someone trying to add more UI or read through the project structure.
The reason I'm making this change now is that I'm looking at enhancing the "Address in Use" error dialog. Doing so will require making a new dialog instead of using the builtin default, so I need to choose either WPF or WinForms. I started down the WPF road and then noticed that we were using the WinForms version of the default MessageBox, so I accidentally this PR.
Resolves
This should make it easier to work on the UI of Scratch Link.
Background Info
Windows Forms is the "old" way to do UI in Windows, and WPF is the "new" way (as of 2006 or so). That said, Windows Forms is still popular with developers and is well supported by Microsoft. Some Forms features, such as
NotifyIcon
, are still missing from WPF and might never be ported over.Proposed Changes
This PR removes all references to WPF and alters any "WPF style" operations to use the Windows Forms equivalent instead.
Supporting changes:
Application.Current
, which is a WPF-specific feature. I think the event handler approach is better anyway.packages.config
which could cause problems building from scratch. I suspect this was caused by forgetting to check inpackages.config
in the early days of the project. At any rate, it's fixed now. I kept the same version we were already using.There are also a lot of changes to boilerplate code here; sorry about that. I made this change by creating a new, empty Windows Forms project in Visual Studio then adding all the necessary parts back in. That approach was much easier than trying to mutate it in place, but it means there's a lot of noise around the signal when looking at the diffs.
Reason for Changes
Since the Windows version of Scratch Link works by placing a
NotifyIcon
in the Windows notification area, and that feature doesn't exist in WPF, we have no choice but to use Windows Forms. When I first set up Scratch Link I didn't know this so initially I set it up as a WPF application. Later, I used Forms features when it came time to add the notification icon. We don't have any other UI in Scratch Link, so it was a bit silly to have the WPF libraries hooked up. I don't think it was causing practical problems, but it could cause confusion for someone trying to add more UI or read through the project structure.The reason I'm making this change now is that I'm looking at enhancing the "Address in Use" error dialog. Doing so will require making a new dialog instead of using the builtin default, so I need to choose either WPF or WinForms. I started down the WPF road and then noticed that we were using the WinForms version of the default
MessageBox
, so I accidentally this PR.