I previously set CurrentTime to the current time on the system. I've changed it to 'Not Set' so dev's can identify any configuration errors. I've done this because I fell foul to that problem already. When I was initialising MainPageVM, I was using DateTime.Now as the default value and when initialising it in the View class (MainPage.xaml.cs). This confused me because I couldn't understand why the time wouldn't update when I change the code.
Basically, I was updating MainPageVM because the time displayed on the dashboard matched what I set it as in the ViewModel. But, the time was being changed in the View class (at run-time) with the DateTime.Now property.
CurrentTime is not a main feature and does not refer to any of the time-stamps attached to any of the device sections (on the dashboard). This is just a clock to help people quickly see how long is left in the day before the various devices shut down (based on the Legend Info. below it. So, this is just a cosmetic change.
When the program is in dark mode, the logo is difficult to see (if you can see it at all). I've added a block of white behind it show to combat this. I went with white because the logo is fine when Windows is in light mode. Because of that, the border/shape/fill recedes into the background.
I decided against changing the logo programmatically to an alternative version because it'll require more work than it's worth. This is a minor cosmetic part of the program and, this way, the logo remains as intended (a rich navy blue).
The time (top-right) of dashboard was not updating to British Summer Time (BST). The change here adds a converision of the system's current/local time to match that of it current time zone. I should've done this at the beginning but here it's done now. And, most importantly, it's before the exhibition has started.
In UpdateStatusColour, the code checks to see what state the device it's processing is in and relays that information to the user with a colour change on the dashboard. In a previous commit, I forgot to include a return statement to indicate the Relays (gallery1 and 2) are on. The one line of code added here addresses that.
Note: The code is starting to look sloppy. The code in UpdateStatusColour is beginning to turn into a sprawing mess of branching logic. I have decided to keep like this for now because of the fixed requirements but you should be aware of the mess building-up. If the requirements begin to change, here might be a good place to start refactoring from.
The tablet I'm using most of the time to monitor the system (with Eyes and Ears) is under powered (too many Windows 10 updates at this point by I digress). So, it doesn't handle the increase in RAM needed for this feature very well. I change the LogToggle to provide a way to clear the log area alongside stopping the program logging (reducing RAM usage and processing cycles).
The changes here are a completion of a previous P.O.C. commit. When the program detects a change in the status of a device (I.E. 'on' to 'off' and vice-versa), Eyes and Ears will play an text-to-speech phrase to indicate the change.
This is a very rough bit of code. This is for testing the possibilty/usability of having the program provide updates using the SpeechSynthesizer class. The initial intention is to have the program denote any change in power status ('gallery1' is now off', 'weld detected by factory1' Etc.) and, if it's any good, expand it from there.
The code changes made here are incomplete but I'm packing up for the day and going home -- it's late. I'm logging the current changes for future reference.
The code added here is more about populating the area created for logging each web request. The XAML code was done in the previous commit. As I stated there, these logs are more about the providing the user of this program visual feedback about the state of the program. There are times when the various devices (light meters/relays) don't update and it's hard to tell if that's Eyes and Ears, the internet connection or the devices on the other end.
This is in aid of providing the user with more feedback about the program (eyes and ears) than the light readings and web requests. The toggle button allows the user to turn-off the logs if they don't want or need them. This is not a full implementation of the logging system (this is just a start).
There was a case where the device status would change to the 'low light detected' (light sky blue) when on the border between a weld being detected and not. This commit addresses that. Also, both Light Meters have been installed at this point and it is apparent both of the welding booths have different light levels. Becuase of this, the dashboard now has code in place which seperates the update-checks to match the device/welding booth. In other words, factory1 does not go dark see green at factory2's light levels.
The app. is going to use a date based versioning system going forward. The format is yyyy.mm.dd.build. The build number is the build for that day and not a 'total' build (I.E. the total amount of time the app. has been built).
Note: Visual Studio does not like it when you use '01' (I.E. January). It does not compile because it does not match any reg-ex patterns specified by the UWP. Instead, you must use '1' to represent January and '11' for November. This is a minor formatting concern from an end-user's perspective but a fixed position for the developer.
The logic for 'factory3' and 'gallery3' is still in place but is not bound to the view (MainPage.xml). The view xml is commented out and not removed. This should make it easier to re-add it if the need comes about.
'factory2' was not updating its timestamp when it received a new reading. It was binding to the wrong property in MainPage.xml (view model). This changes the property to the correct one.
Return to Ritherdon Project