Military Data Solutions (MDS)
So I stated previously (here) that I was going to give a taste, and I’m not lying. Getting things to work in multiple environments can be tricky sometimes if you don’t remember to have a test system in place to test the full life cycle of the development. But anyways, here’s a few screenshots to hold you over and some explanations on the logistics of where the design is going. Later I’ll work towards keeping my word by posting a demo.
So first up, you see above that we have an installation wizard. Currently the application is using Microsoft’s ClickOnce deployment for Install and Updates, but the functionality of that is pretty limited yet still effective at what it does. The simplest way to think of why I have ClickOnce in place is because I need a simple way to get the application on the computer, dependencies installed, and program running without much hiccups so that my code can finally run. From there, my wizard takes us through the setup process, selecting either new Database to make (MSSQL (server), SQLite (file), MSAccess (file), or connect to an existing install (if this is a secondary computer). Once everythings set, the application is good to go.
Next up, and seen everytime after installation, is the login screen of course. Currently it’s just a simple User/Password system. Permissions are basic Access Control Layers of “Can_View_Basic_Personnel”, “Can_View_Privledged…”, etc. A more elegant system will be developed later, but for now we’re working just fine.
The logo in the back is a silly yet nice little nod to the old “GIGeeks” idea, but in the future will be customized to show the main unit’s logo. For Admins (and right now all testers), a debug window appears which will spit out any errors, list any functions we need to keep track of, and just provide a rich amount of information. In the future, I want to set up levels of messages to categorize things and keep a log that’s always being saved to file or database. This way an Admin/Developer can always see what’s going on and address the issue.
Addons menu is populated dynamically during initial load to show all the available plugins. Demo Plugin is hard-coded right now, but would be the basis of the Example plugin for any developer licenses purchased in the future. Personnel Manager is the “HRPlugin” that’s created outside of the solution, compiled separately from the base code, and imported during load. This is how all plugins will function and it’s a must needed plugin at that.
The current HRPlugin is simply a two panel design with the left being a hierarchy list showing all the units and persons assign to the unit. On the right though is where all the fun information for each person is laid out and can be updated. The current idea is to keep this plugin for just HR purposes about the Person, and leave another plugin in charge for other function like inventories.
Clicking through the hierarchy of units, you can get as far down as it goes. I simply started with the BCT, and broke it down all the way to platoon level, but there’s nothing stopping you from going higher or going down further to even fireteams.
With any application, you need to have settings. Just like the Addons menu loading up the plugins dynamically to use, our Settings page will automatically load each plugin’s settings to use. The Plugin’s settings can be designed and customized however the developer wishes, as all we need is a Tabpage returned to show.
The Settings page also allows to denote where downloaded plugins may be located. We automatically create a subdirectory in the application’s folder called “/addons”, and that’s where we’d prefer all plugins to be stored, but if for whatever reason you don’t wish to (maybe you want the plugin to only be on a custom share-drive that has further access restrictions) then you can add those directories for us to search during next load. (Don’t mind the random button in the middle though, that’s currently my debugging button to restart the application.)