Back on track

I created a PatchDataHelper class to aid in mapping Patch instances from DataRows. I also brought in a DataMapping class that provides anonymous row/reader to object mapping using reflection. Assuming properties and column names are the same this should work nicely and save me a bunch of typing.

My initial approach seems cumbersome and unwieldy. After putzing around for a while, I decided to try wrapping the TableAdapterManager through the Database class, access all of the 'helper' code from that level, and focus on using a single typed dataset.

Hopefully I can build on this momentum and not let it slip by the wayside again...

Back from hiatus

The NyMPH project was unintentionally put on hold. My wife decided to have back surgery, which has taken most of my free time (until Christmas, which took up the rest of it).

I'm looking forward to getting back into the NyMPH project. Hopefully I can remember what I was doing. :)

Working on data access

I started working on data access code for the Keyword class. I initially added LINQ mappings to the Keyword class, created a typed datacontext, and wrote a couple query methods using LINQ. It's pretty neat.

Once I got to the 'Update' method, I realized that LINQ-to-SQL doesn't have a specific 'update' method; as I understand it changes to the object's properties are automatically persisted when the datacontext 'updates' everything. There didn't seem to be a way to selectively update individual objects.

I was eager to use LINQ to SQL, but as I read up on it to see how I could best use it for the NyMPH project it became apparent that LINQ to SQL wasn't going to be developed further by Microsoft.

As cool as LINQ seems to be, I decided to stick with typed datasets and SQL queries. This will make object/relational mapping a bit more work, but that's alright.

I also learned the built-in O/RM editor in Visual Studio 2008 doesn't work with SQL CE 3.5. That's a shame.

I've started adding persistence methods to the KeywordFactory class (poorly named; I'll probably change it later). Once I get into the rhythm of working with typed datasets for O/RM I'll probably streamline it and use it as a basis for the other domain classes.

Added Database

I found the prototype SQL CE 3.5 database I created for NyMPH and added it to the solution. I'm hoping to use LINQ for the majority of the queries.

I've implemented IEquatable and IComparable on a couple different domain classes; I will do the same for the rest of them.

I also realized that determining equality between generic List objects takes a bit of code. Right now, I'm comparing item count first (to avoid the cost of full comparison), then iterating through each item until it finds a mismatch.

I could create custom collection classes, but at this point I don't see a need to do so. We'll see how well the 'brute force' item comparison works in terms of performance.

I've also created a spreadsheet to store these changes. It is in /Solution/NyMPH_Classes/NyMPHDevLog.xls.

Cranking out code

I've gone through all of the NyMPH.Patches classes and filled in the code as best as I can for now. I also worked on the FileSystem class. Things are starting to come together, but for now this is just bare-bones minimal functionality code.

I did create a solid block of code for NyMPH.Patches.PatchBank.CreatePatchListFile(). This method uses a string builder to assemble the contents of a .pchList file. I need to add some checks for empty Patch lists, etc.

Since the PatchBank will be graphically represented in the UI as a 10 x 10 grid of Patches, perhaps using a List instance isn't the best way to go. The position of Patches in the grid will determine the order they are written to the pchList file, which in turn sets the order they are loaded into the Nord. I'd also like to offer sorting options for the PatchBank, which may become complicated with other ways of storing Patches.

I'm going to create a spreadsheet with a tab for each class. This will let me keep track of changes to each class in chronological order.

Added XML to event logger

I added some basic XML code to create an Event element with attributes of Date, Time and EntryType (severity). The inner text of each Event will contain the message.

This produces a .log file with an XML fragment; it would be a simple matter to create a root element corresponding to the log filename in order to read/search through it. I may create this as needed, but for right now the basic logging features should work.

Back to work

I'm back on track with writing code for the NyMPH project. I started using the EventLogHelper class and quickly realized I had an opportunity to make things a bit easier to use it.

I started adding namespaces to the classes I've touched so far. Since they were all auto-generated, they are all at the same 'level'.

The namespace scheme I came up with is as follows: Root level namespace is NyMPH, second level namespace refers to the 'package' a class falls under (i.e. Patches, Persistence, etc.). For example, the fully qualified name for the Patch type would be NyMPH.Patches.Patch.

I added a 'generic' method to the ELH called WriteEvent(). This method looks at the instance that invoked it to see if it should write to a log file, write to the Event Log, or write to the Application Event Log. It tests the FileInfo object for null, followed by the EventLog object for the 'custom' log.

I then used preprocessor directives to create an instance of ELH using a log file (for debugging), or registered Event Log and Event Source names for the 'release' version (which will create the log and source values during installation).

This allows me to simply call the WriteEvent() method as needed without having to check for 'debug mode' each time.

For each class, then, I will use the fully qualified name for log files. Errors that happen in the FileSystem class, for example, would be written to the same directory as the executable as NyMPH.Persistence.FileSystem.Errors.log.

For writing to log files, I should probably implement something a bit more structured for writing errors than just dumping the Message onto a single line. I may create an XML file or something to do this.

I also need to start keeping track of individual classes as I write code for them. Specifically, I need to keep track of the following states:
untouched (generated code only)
in process (working on them)
on hold (have worked on them but waiting for something)
almost ready (can be tested but contains 'TODO' markers)
ready (can be tested fully)