bc-programming

I see this question semi-frequently on forums. It's a reasonable question on the surface. However, the fact is that there is no "Best language for a beginner". Truly, the very idea that a given computer language could be "better for beginners" than another is downright assinine. Consider human languages. A person learns language over time, and there isn't any more difficulty for different languages; the skill develops through practice. Chinese isn't "harder" to learn than English, for example; but it is harder to learn when you know english. So how does this extend into computer languages? Well, the first computer language you learn won't matter, just as the first Human language you learned doesn't really matter.For Human languages, the big thing you are learning is how to express yourself to others. For Programming languages, the big thing you are learning is how to express yourself- to the computer. Once you learn one imperative programming language, the others are easier to learn; same way with human languages. Once you know one germanic language, the others are typically easier to learn. Of course, it's harder to learn Chinese or Japanese when you are used to a latin alphabet; for programming languages, this "barrier" is typically found between imperative, Declarative, and functional languages. of course the actual difficulty is not quite at the same level; but functional languages are fundamentally different in many ways from imperative languages, enough that trying to take what you learned via programming in an imperative language and applying it to a functional one can do more harm than good to your learning process, just as trying to apply your understanding of English will harm attempts to learn most non-germanic languages, trying to apply an understanding of Chinese/Japanese/etc to learning English will harm attempts to learn it as well. Additionally, one issue I find is that many people will say that "language X is easy to learn because it's like plain english". Which is a flawed perspective, since that brings with it a lot of language baggage; english is designed for communicating between people; a programming language is designed for communicating between a person and a computer (or rather, the interpreter/compiler which makes it into something the computer understands, but let's not cloud the issue). So you end up with a psuedo-english language that tries to be declarative but at the same time isn't english; SQL, for example, is english-like, but I'd be hard-pressed to say that "Select * from Customers Where CX>6" is "plain english". It's easy to understand, but it's restrictive; after all, in english the same concept could be expressed as "choose all fields from the customers table where the record in question has a CX field greater than 6". But that is far from valid SQL, which has a far more restrictive grammar and syntax. (if it didn't, parsing it would be a nightmare). This is how I've always felt about it. What is important isn't what specific language you learn but that you learn the concepts involved; for imperative languages this would be references, functions, recursion, variable allocations,object mutability, (and for OOP languages the various OOP concepts, such as polymorphism, aggregation, composition, delegation, etc). Functional languages, (and some imperative languages that integrate functional features) it's things like lambdas, recursive definitions,Higher-order/First-class functions (Functions that take other functions as arguments), pure functions, strict versus non-strict evaluation, catamorphism, etc. Once you learn the concepts, you can use pretty much learn any language with minimal effort, you just need to learn the syntax.(unless you are jumping across a declarative/imperative/functional divide, in which case you also need to learn and relearn other concepts as well). Overall, however, Learning a syntax is easy; the first programming language you learn is hardest no matter which one you choose simply because you have to learn the syntax at the same time you are learning all sorts of "new" concepts. It doesn't matter what language you choose; it will always be "harder" to learn than later languages for you.

I see this question semi-frequently on forums. It’s a reasonable question on the surface. However, the fact is that there is no “Best language for a beginner”. Truly, the very idea that a given computer language could be “better for beginners” than another is downright assinine.

Consider human languages. A person learns language over time, and there isn’t any more difficulty for different languages; the skill develops through practice. Chinese isn’t “harder” to learn than English, for example; but it is harder to learn when you know english.

So how does this extend into computer languages?

Well, the first computer language you learn won’t matter, just as the first Human language you learned doesn’t really matter.For Human languages, the big thing you are learning is how to express yourself to others. For Programming languages, the big thing you are learning is how to express yourself- to the computer.

Once you learn one imperative programming language, the others are easier to learn; same way with human languages. Once you know one germanic language, the others are typically easier to learn.

Of course, it’s harder to learn Chinese or Japanese when you are used to a latin alphabet; for programming languages, this “barrier” is typically found between imperative, Declarative, and functional languages. of course the actual difficulty is not quite at the same level; but functional languages are fundamentally different in many ways from imperative languages, enough that trying to take what you learned via programming in an imperative language and applying it to a functional one can do more harm than good to your learning process, just as trying to apply your understanding of English will harm attempts to learn most non-germanic languages, trying to apply an understanding of Chinese/Japanese/etc to learning English will harm attempts to learn it as well.

Additionally, one issue I find is that many people will say that “language X is easy to learn because it’s like plain english”. Which is a flawed perspective, since that brings with it a lot of language baggage; english is designed for communicating between people; a programming language is designed for communicating between a person and a computer (or rather, the interpreter/compiler which makes it into something the computer understands, but let’s not cloud the issue). So you end up with a psuedo-english language that tries to be declarative but at the same time isn’t english; SQL, for example, is english-like, but I’d be hard-pressed to say that “Select * from Customers Where CX>6″ is “plain english”. It’s easy to understand, but it’s restrictive; after all, in english the same concept could be expressed as “choose all fields from the customers table where the record in question has a CX field greater than 6″. But that is far from valid SQL, which has a far more restrictive grammar and syntax. (if it didn’t, parsing it would be a nightmare).

This is how I’ve always felt about it. What is important isn’t what specific language you learn but that you learn the concepts involved; for imperative languages this would be references, functions, recursion, variable allocations,object mutability, (and for OOP languages the various OOP concepts, such as polymorphism, aggregation, composition, delegation, etc). Functional languages, (and some imperative languages that integrate functional features) it’s things like lambdas, recursive definitions,Higher-order/First-class functions (Functions that take other functions as arguments), pure functions, strict versus non-strict evaluation, catamorphism, etc.

Once you learn the concepts, you can use pretty much learn any language with minimal effort, you just need to learn the syntax.(unless you are jumping across a declarative/imperative/functional divide, in which case you also need to learn and relearn other concepts as well). Overall, however, Learning a syntax is easy; the first programming language you learn is hardest no matter which one you choose simply because you have to learn the syntax at the same time you are learning all sorts of “new” concepts. It doesn’t matter what language you choose; it will always be “harder” to learn than later languages for you.

In some of my recent posts, I've covered the topic of accessing and parsing an INI file for configuration data in a C# Application. Some may wonder why. After all; the "norm" for C# and .NET applications is to use XML files for configuration information, isn't it? Well, yes. But to be honest, XML files are a fucking pain in the ass. They aren't human readable to your average person the same way an INI file is, and getting/setting values is tedious. Primarily, the reason I use INI files is that they are: Human Readable: Anybody can understand the basic structure of the sections and Name=Value syntax. Accessible: You don't need a special editor Portable: since the entire thing is interpreted using Managed code, it will act the same on any platform (Mono or the MS CLR). Mostly, I feel that XML, and in many ways other configuration options, are more or less driven by fad. Another option for configuration settings on Windows is the Registry, which is in fact often the recommended method; but this is anything but accessible to the user. Would you rather guide a user to edit a INI file or to fiddle with registry settings? With that said, INI Files do have their own issues. For example, their data is typically typeless; or, more precisely, the Values are all strings. Whereas using a .NET XML Serializer, for example, you could easily(relatively speaking) serialize and deserialize a special configuration class to and from an XML file and preserve it's format, with my INI file class there will typically be some work to parse the values. It was with the idea of turning my string-only INIFile configuration settings into something that can be used for nearly any type that I created the INItemValueExtensions class, which is nothing more than a static class that provides some extension methods for the INIDataItem class. I covered this in my previous post. The prototypes for the two static functions are: public static T GetValue<T>(this INIDataItem dataitem, T DefaultValue); //and public static void SetValue<T>(this INIDataItem dataitem, T newvalue); How would one use these extension methods? Well, here's an Example: public static void main(String[] args) { INIFile loadini = new INIFile("D:\\testini.ini"); loadini["Dates"]["TestDate"].SetValue(DateTime.Now); DateTime readvalue = loadini["Dates"]["TestDate"].GetValue(); } Woah, hold the phone! What's going on here? We're loading DateTime values directly from the INI File? How does that work? All the "magic" happens in the getValue generic extension method. The first thing the routine does is check to see if the Type Parameter has a static TryParse() method; if it implements ISerializable and 1) { //more than one, so offset... OffsetRect(ref getplacement.rcNormalPosition, 16*existing.Length, 16*existing.Length); } SetWindowPlacement(FormObject.Handle, ref getplacement); //load placement... } } Alright, so maybe I lied a bit. It's not super short. Although a lot of it is comments. Some might note that I only sporadically add doc comments, even though I ought to be adding them everywhere. Well, sue me. I just add them when I feel like it. When I'm concentrating on function, I'm not one to give creedence to form. This is where I explain OffsetRect(). Basically, if your application is run twice, and you load the form position twice, the second form will open over the first one, and the screen will look pretty much the same. So we detect previous instances and offset by an amount to make it's position different from any previous instances as necessary. That's pretty much the only purpose of OffsetRect. I have packaged the current versions of cINIFile.cs and the new FormPositionSaver.cs in a zip file, it can be downloaded from here.

In some of my recent posts, I’ve covered the topic of accessing and parsing an INI file for configuration data in a C# Application.

Some may wonder why. After all; the “norm” for C# and .NET applications is to use XML files for configuration information, isn’t it? Well, yes. But to be honest, XML files are a fucking pain in the ass. They aren’t human readable to your average person the same way an INI file is, and getting/setting values is tedious. Primarily, the reason I use INI files is that they are:

1. Human Readable: Anybody can understand the basic structure of the sections and Name=Value syntax.
2. Accessible: You don’t need a special editor
3. Portable: since the entire thing is interpreted using Managed code, it will act the same on any platform (Mono or the MS CLR).

Mostly, I feel that XML, and in many ways other configuration options, are more or less driven by fad. Another option for configuration settings on Windows is the Registry, which is in fact often the recommended method; but this is anything but accessible to the user. Would you rather guide a user to edit a INI file or to fiddle with registry settings?

With that said, INI Files do have their own issues. For example, their data is typically typeless; or, more precisely, the Values are all strings. Whereas using a .NET XML Serializer, for example, you could easily(relatively speaking) serialize and deserialize a special configuration class to and from an XML file and preserve it’s format, with my INI file class there will typically be some work to parse the values.

It was with the idea of turning my string-only INIFile configuration settings into something that can be used for nearly any type that I created the INItemValueExtensions class, which is nothing more than a static class that provides some extension methods for the INIDataItem class. I covered this in my previous post.

The prototypes for the two static functions are:

How would one use these extension methods? Well, here’s an Example:

Woah, hold the phone! What’s going on here? We’re loading DateTime values directly from the INI File? How does that work?

All the “magic” happens in the getValue generic extension method. The first thing the routine does is check to see if the Type Parameter has a static TryParse() method; if it implements ISerializable and have a TryParse method, than the routine will read the string from the INI file, decode it via Base64, and throw it in a MemoryStream, and then try to deserialize the Object Graph for a Type T using that stream.

If it does implement a TryParse() routine, (like, for example, DateTime) it doesn’t try quite as hard. It takes the string from the INI file and hands it to the Type’s TryParse() routine, and then returns what that gives back. Naturally, the inverse function (setValue) does something somewhat opposite; it checks the Base64 logic, and if so it sets the value of the item to the Base64 encoded value of the serialized object. Otherwise, it just uses toString().

This typically works, particularly with DateTime, because usually ToString() is the inverse of TryParse(). In the case of DateTime, this has a few edge cases with regards to locale, but usually it works quite well. And more importantly, the introduction of allowing any object that implements ISerializable to simply be thrown as an INI value via a Base64 encoded string is useful too, although with large objects it’s probably not a good idea for obvious reasons.

But… I still want to access other settings!

Of Course, an INIFile is only one of any number of ways to store/retrieve configuration settings. And while they don’t typically lend themselves to the same syntax provided by the INIFile class, it would be useful to have some sort of common denominator that can handle it all. That was the original intent of the relatively unassuming ISettingsStorage interface:

This uses a concept known as a “category” which is pretty much the same idea as an INI File section. What makes it different is that, for implementors that use other storage mechanisms, it could have additional meaning; for example, a fictitious XML implementation of ISettingsStorage could use the “Category” string as an XPath to an element; and the Value could be stored/retrieved as a Attribute. a Registry implementation might use it as a Registry path, and so on.

The problem is, even though the INIFile class implements this interface, it’s too basic, and doesn’t provide nearly the syntactic cleanliness that just using the INIFile does. Stemming from that, and because I wanted to try to get a way to store settings directly in a DB, I introduced two events to the INIFile class; one that fires when a Value is retrieved, and one when a value is saved. This way, the event could be hooked and the value saved elsewhere, If desired. Now, to be fair, this is mostly a shortcoming of my interface definition; as you can see above, there is no way to, for example, inspect category or Value names. I toyed with the idea of adding a “psuedo” category/value combination that would return a delimited string of category names, but that felt extremely silly. The creation of a generic interface- or abstract class- that provides all the conveniences I currently enjoy using my INIFile class but allowing me to also use XML, Registry, or nearly any other persistent storage for settings will be a long term goal. For now, I’m content with accessing INI files and having a unclean event to hack in my own behaviour.

My first test of the above feature- whereby it allows values to be TryParse’d and ToString’d back and forth from a given type on the fly- was the creation of a FormPositionSaver class.

The proper way to save and restore a window’s position on Windows is using the GetWindowPlacement() and SetWindowPlacement() API Functions. These use a structure, named, quite aptly, “WINDOWPLACEMENT” to retrieve and set the window position and various attributes. Therefore, our first task is to create the proper P/Invoke’s for these functions:

I also include OffsetRect(), but I’ll get to that in a bit. Now the “big one” is the definition of the WINDOWPLACEMENT structure and it’s various aggregate structures. Why? well, in the interest of leveraging the INIFile’s static extensions, Why not define a static TryParse() and a toString() method on the structure that can set and retrieve the member values:

WHEW! that’s quite a bit of code for a structure definition, but we’ll make up for it with the brevity of the actual FormPositionSaver class itself. First, my design goal with this class was to make it basically do all the heavy lifting; it hooks both the Load and Unload event, and saves to and from a given INIFile Object in those events. Since the application I was working on at the time didn’t actually get a Valid INI object until during it’s main form’s Load event, and since there is no way to say “Invoke this event first no matter what” I also added a way for it to be told that hooking the load event would be pointless since it already occured, at which point it will not hook the event and instead set the form position immediately. Values are stored

Alright, so maybe I lied a bit. It's not super short. Although a lot of it is comments. Some might note that I only sporadically add doc comments, even though I ought to be adding them everywhere. Well, sue me. I just add them when I feel like it. When I'm concentrating on function, I'm not one to give creedence to form.

This is where I explain OffsetRect(). Basically, if your application is run twice, and you load the form position twice, the second form will open over the first one, and the screen will look pretty much the same. So we detect previous instances and offset by an amount to make it's position different from any previous instances as necessary. That's pretty much the only purpose of OffsetRect.

I have packaged the current versions of cINIFile.cs and the new FormPositionSaver.cs in a zip file, it can be downloaded from here.

HAHA! How's that for a clever title? Oh... well... ahem... nevermind. As a avid user of my own INIFile class, which I first write about- at least it's C# implementation- in my parsing INI files posting, I am always looking for ways to improve it's usage make it more "accessible". Recently, I have been tasked (by way of my new title of "freelance consultant") with creating several LOB (Line of Business) Type applications. Applications, naturally, have a tendency to lend their implementations to the creation and reading of settings. Being something of a fan of the simplicity of INI Files, I chose to use my INIFile class in the application. It works well, however, I have noticed that I have a lot of duplicate code. More specifically, I typically have to implement a "wrapper" class, which manages configuration information and reads/writes values to and from the INIFile as its own properties are accessed. For example: public bool PopulateUserOrderDropdown { get { bool tparse; if(bool.TryParse(OurINI["Admin.Settings"]["PopulateUserOrderDropDown","false"].Value,out tparse) return tparse; return false; } set { OurINI["Admin.Settings"]["PopulateUserOrderDropDown"].Value;} } Nothing too dreadful, but imagine having nearly the exact same thing repeated a number of times! The code is repeated and as Larry Wall says, one of the traits of a good programmer is sloth. I don't like having to write this same code over and over again! The INIFile is supposed to make it easy! The trouble here stems from the fact that the INIFile values are only strings; and typically, many settings are represented in the application itself as integers and booleans, dates, and so forth. My first attempt to mitigate the clutter was a static method, which I called xParse: public static class boolEx { public static bool xParse(String Value, bool Default) { bool parseresult; if(bool.TryParse(Value,out parseresult)) return parseresult; else return Default; } } relatively straightforward- basically it's a shell of what I had repeated over and over again. This mitigated the issue somewhat, so my properties in the wrapper looked like this: public bool PopulateUserOrderDropdown { get { return boolEx.xParse(OurINI["Admin.Settings"]["PopulateUserOrderDropDown", "false"].Value); } set { OurINI["Admin.Settings"]["PopulateUserOrderDropDown"].Value;} } much more managable, but still, could we not make this more concise? My first thought, was that perhaps I could eliminate the necessity of having the wrapper at all; I recalled two interfaces from my old COM programming days, specifically, IDispatch and IDispatchEx. Surely, I could do something similar? Unfortunately, the interfaces are for COM, and C# doesn't have dynamics until Version 4. So, I fired up Visual Studio 2010 express to see if I couldn't add the dynamic language constructs to the INIFile class; additionally, since I still need to work with .NET 3.5, I'll add the new code as a conditional compilation. The first step was deciding exactly what I wanted to happen. Imagine code like this: INIFile useINI = new INIFile("settings.ini"); String ConnectionString = (String)useINI.General.ConnectionString; The holy grail of the INIFile simplicity! Naturally, the .NET framework does provide the facility with which to add this functionality, as part of the System.Dynamic namespace. The first step was deciding on the method by which to conditional compile. Since projects copy the source of a file to your project folder when you add them, it seemed reasonable to simply add it as a #define right inside the INIFile class itself. #define CS4 And now, I just need to enclose all my new happy stuff in a conditional directive, and I'll get the best of both worlds- C# 4.0 consumers who keep the #define will be able to use the suave new feature, and older consumers will still be able to work without ripping apart the classes. The code to add this was surprisingly simple; as it stands now the longest method (An implementation of TryDeleteMember, which is never called from C#/VB.NET consumers, so is excessive for my usage). First, obviously we enclose the import statement in the conditional compile; the class headers are conditionally compiled as well, only deriving from DynamicObject with CS4 set. The core of the new functionality is in the overrides to the Dynamic Object's TryGetMember. For the INISection: public override bool TryGetMember(GetMemberBinder binder,out object result) { result = this[binder.Name]; return true; } And for the INIFile... public override bool TryGetMember(GetMemberBinder binder,out object result) { result = this[binder.Name]; return true; } Exactly the same, in fact. This works because of the indexer I added; the indexer will add the item if it doesn't exist and return the new value, so even if the member name doesn't exist, the INIFile will simply have that section added. That's for the retrieval of erements; to allow the assignment to them in the same fashion, we need to override TrySetMember(). In my case, this was a bit more involved, for flexibility purposes. For example, code like INIFile.MainSection="hello" should work, and change the name of the section. And why allow things like assignments from a Dictionary<String, String>, or maybe even a list (assigning a numbered id to set values)? And of course allow setting the Value directly, which will likely use the indexer much as I did for the TryGet... Implementations. public override bool TrySetMember(SetMemberBinder binder, object value) { //if it is a dataitem, set it directly. if (value is INIDataItem) { this[binder.Name] = (INIDataItem)value; return true; } else if (value is Tuple<, Object>) { Tuple<, Object> theTuple = (Tuple<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = theTuple.Item1; getitem.Value = theTuple.Item2.ToString(); return true; } else if (value is Tuple<, String>) { Tuple<, Object> theTuple = (Tuple<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = theTuple.Item1; getitem.Value = theTuple.Item2.ToString(); return true; } else if (value is KeyValuePair<, Object>) { //Allow a KeyValuePair<,Object> to be passed to set Name and Value. KeyValuePair<, Object> castedval = (KeyValuePair<, Object>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = castedval.Key; getitem.Value = castedval.Value.ToString(); return true; } else if (value is KeyValuePair<, String>) { //Allow a KeyValuePair<,String> to be passed to set Name and Value. KeyValuePair<, String> castedval = (KeyValuePair<, String>)value; INIDataItem getitem = this[binder.Name]; getitem.Name = castedval.Key; getitem.Value = castedval.Value; return true; } else { this[binder.Name].Value = value.ToString(); return true; } } setting the Value should be equally flexible; since we can, why not? for example, why not make the following "legal"? INIFile.Section.Value="newvalue"; INIFile.Section.Value=DateTime.Now; INIFile.Section.Value=Tuple.Create("NewName","Chicken"); INIFile.Section.Value=Tuple.Create("NewName",DateTime.Now); The first example sets the Value to a string, the second sets it to a DateTime that is silently casted to a String (using toString(), and the last two use the new C# 4.0 tuples, to set both the name of the value and the value simultaneously. A more elegant solution would be to add this code to the Indexer, and merely call the indexer with the name and the value and return true if no exception occurs and false otherwise. However, I'm reluctant to go that route since some of the types are C# 4 types (Tuples). public override bool TrySetMember(SetMemberBinder binder, object value) { if (value is String) { this[binder.Name].Name = (String)value; return true; } else if (value is List<INIItem>) { INISection getsection = this[binder.Name]; getsection.INIItems = (List<INIItem>)value; return true; } else { return false; } } So Now, I've got an INI File implementation that supports Dynamic invocation. Well, that's great... except that the application I first found it clumsy in is using .NET 3.5, so I can't use the dynamic features. Back at square one. In C# 2008/3, we might not be able to leverage the power of dynamics, but we do have generics and Extension methods at our disposal. a feasible alternative could be to add a extension method to the INIDataItem class that has a generic type parameter that it will attempt to convert it's string Value into. First, using ChangeType, second, it can try to invoke a static TryParse on the given Type to parse the "value" string. And if none of that works, it can return a passed in default. This is still more verbose than the dynamic solution, but it has two distinct advantages- first, it's type-safe, so you get all the intellisense goodness, and second, it's still shorter than the alternative. Here is the code, which can be found in the cINIFile.cs file attached to this posting as well. public static class INItemValueExtensions { //extensions for INIDataItem //normally, INIDataItem is a Name/Value Pair; More Specifically, because of the way INI files are, they are //naturally typeless. However, most configuration options are mapped to a different type by the application. //and I've found it to be a gigantic pain to have to write the same TryParse() handling code over and over. //so I added these handy extensions to the INIDataItem class, which provide some functions for setting. //I keep them out of the main code simply because that way it doesn't clutter it up. It's already cluttered enough as-is. /// <summary> /// Attempts to use Convert.ChangeType() to change the Value of this INIDataItem to the specified type parameter. /// If this fails, it will attempt to call a static "TryParse(String, out T)" method on the generic type parameter. /// If THAT fails, it will return the passed in DefaultValue parameter. /// </summary> /// <typeparam name="T">Parameter Type to retrieve and act on in Static context.</typeparam> /// <param name="dataitem">INIDataItem instance whose value is to be parsed to the given type.</param> /// <param name="DefaultValue">Default value to return</param> /// <returns>Result of the parse/Conversion, or the passed in DefaultValue</returns> public static T GetValue<T>(this INIDataItem dataitem, T DefaultValue) { //Generic method, attempts to call a static "TryParse" argument on the given class type, passing in the dataitem's value. try { return (T)Convert.ChangeType(dataitem.Value, typeof(T)); } catch (InvalidCastException ece) { //attempt to call TryParse. on the static class type. //TryParse(String, out T) Type usetype = typeof(T); T result = default(T); Object[] passparams = new object[] { dataitem.Value, result }; try { bool tpresult = (bool)usetype.InvokeMember("TryParse", BindingFlags.Static, null, null, passparams); if (tpresult) { //tryparse succeeded! return (T)passparams[1]; //second index was out parameter... } } catch (Exception xx) { //curses... return DefaultValue; } } return DefaultValue; } /// <summary> /// Logical inverse of the getValue routine... a bit faster to implement... /// </summary> /// <typeparam name="T"></typeparam> /// <param name="dataitem"></param> /// <param name="newvalue"></param> public static void setValue<T>(this INIDataItem dataitem, T newvalue) { dataitem.Value = newvalue.ToString(); } private static void GetTypeDefault<T>(out T result) { Type tt = typeof(T); //basic idea: call default, empty constructor using reflection. ConstructorInfo defaultconstructor = tt.GetConstructor(new Type[] { }); result = (T)defaultconstructor.Invoke(null); } } And there you have it, a bunch of awesome additions. INI files are often thought of as deprecated, but that's only the INIFile functions. This class was designed because working with the registry makes it difficult to test properly, and because JSON,YAML, and many other formats are excessively complicated. when you just need a few basic settings, all you need is the clean, simple format of a INI file. And now, with these additions, code for reading from those INI files is clean and simple as well! The Source- cINIFile.cs

HAHA! How’s that for a clever title?

Oh… well… ahem… nevermind.

As a avid user of my own INIFile class, which I first write about- at least it’s C# implementation- in my parsing INI files posting, I am always looking for ways to improve it’s usage make it more “accessible”.

Recently, I have been tasked (by way of my new title of “freelance consultant”) with creating several LOB (Line of Business) Type applications. Applications, naturally, have a tendency to lend their implementations to the creation and reading of settings. Being something of a fan of the simplicity of INI Files, I chose to use my INIFile class in the application. It works well, however, I have noticed that I have a lot of duplicate code. More specifically, I typically have to implement a “wrapper” class, which manages configuration information and reads/writes values to and from the INIFile as its own properties are accessed. For example:

Nothing too dreadful, but imagine having nearly the exact same thing repeated a number of times! The code is repeated and as Larry Wall says, one of the traits of a good programmer is sloth. I don’t like having to write this same code over and over again! The INIFile is supposed to make it easy!

The trouble here stems from the fact that the INIFile values are only strings; and typically, many settings are represented in the application itself as integers and booleans, dates, and so forth. My first attempt to mitigate the clutter was a static method, which I called xParse:

relatively straightforward- basically it’s a shell of what I had repeated over and over again. This mitigated the issue somewhat, so my properties in the wrapper looked like this:

much more managable, but still, could we not make this more concise? My first thought, was that perhaps I could eliminate the necessity of having the wrapper at all; I recalled two interfaces from my old COM programming days, specifically, IDispatch and IDispatchEx. Surely, I could do something similar?

Unfortunately, the interfaces are for COM, and C# doesn’t have dynamics until Version 4.

So, I fired up Visual Studio 2010 express to see if I couldn’t add the dynamic language constructs to the INIFile class; additionally, since I still need to work with .NET 3.5, I’ll add the new code as a conditional compilation.

The first step was deciding exactly what I wanted to happen. Imagine code like this:

The holy grail of the INIFile simplicity! Naturally, the .NET framework does provide the facility with which to add this functionality, as part of the System.Dynamic namespace.

The first step was deciding on the method by which to conditional compile. Since projects copy the source of a file to your project folder when you add them, it seemed reasonable to simply add it as a #define right inside the INIFile class itself.

#define CS4

And now, I just need to enclose all my new happy stuff in a conditional directive, and I’ll get the best of both worlds- C# 4.0 consumers who keep the #define will be able to use the suave new feature, and older consumers will still be able to work without ripping apart the classes. The code to add this was surprisingly simple; as it stands now the longest method (An implementation of TryDeleteMember, which is never called from C#/VB.NET consumers, so is excessive for my usage). First, obviously we enclose the import statement in the conditional compile; the class headers are conditionally compiled as well, only deriving from DynamicObject with CS4 set.

The core of the new functionality is in the overrides to the Dynamic Object’s TryGetMember.

For the INISection:

And for the INIFile…

Exactly the same, in fact. This works because of the indexer I added; the indexer will add the item if it doesn’t exist and return the new value, so even if the member name doesn’t exist, the INIFile will simply have that section added.

That’s for the retrieval of erements; to allow the assignment to them in the same fashion, we need to override TrySetMember(). In my case, this was a bit more involved, for flexibility purposes.

For example, code like INIFile.MainSection=”hello” should work, and change the name of the section. And why allow things like assignments from a Dictionary<String, String>, or maybe even a list (assigning a numbered id to set values)? And of course allow setting the Value directly, which will likely use the indexer much as I did for the TryGet… Implementations.

setting the Value should be equally flexible; since we can, why not?
for example, why not make the following “legal”?

The first example sets the Value to a string, the second sets it to a DateTime that is silently casted to a String (using toString(), and the last two use the new C# 4.0 tuples, to set both the name of the value and the value simultaneously.

A more elegant solution would be to add this code to the Indexer, and merely call the indexer with the name and the value and return true if no exception occurs and false otherwise. However, I’m reluctant to go that route since some of the types are C# 4 types (Tuples).

So Now, I’ve got an INI File implementation that supports Dynamic invocation. Well, that’s great… except that the application I first found it clumsy in is using .NET 3.5, so I can’t use the dynamic features. Back at square one.

In C# 2008/3, we might not be able to leverage the power of dynamics, but we do have generics and Extension methods at our disposal. a feasible alternative could be to add a extension method to the INIDataItem class that has a generic type parameter that it will attempt to convert it’s string Value into. First, using ChangeType, second, it can try to invoke a static TryParse on the given Type to parse the “value” string. And if none of that works, it can return a passed in default. This is still more verbose than the dynamic solution, but it has two distinct advantages- first, it’s type-safe, so you get all the intellisense goodness, and second, it’s still shorter than the alternative.

Here is the code, which can be found in the cINIFile.cs file attached to this posting as well.

And there you have it, a bunch of awesome additions. INI files are often thought of as deprecated, but that’s only the INIFile functions. This class was designed because working with the registry makes it difficult to test properly, and because JSON,YAML, and many other formats are excessively complicated. when you just need a few basic settings, all you need is the clean, simple format of a INI file. And now, with these additions, code for reading from those INI files is clean and simple as well!

The Source- cINIFile.cs

As I posted previously here, Sorting a Listview can be something of a pain in the ass. In that article, I covered some basics on providing a class that would essentially give you sorting capabilities for free, without all the messy code that would normally be required. A lot of the code required for sorting is mostly boilerplate with a few modifications for sorting various types. As a result, the generic implementation works rather well. However, as with any class, adding features never hurts. In this case, I got to thinking- why not have right-clicking the ColumnHeaders show a menu for sorting against that Column? Seems simple enough. I quickly learned that apparent simplicity often is misattributed. I faced several issues. The first thought was that I could hook a Mouse event for Right-Clicking a column header. Unfortunately, I soon discovered two facts about the .NET ListView control. First, was that there was no event for right-clicking a header control. Second, no even was fired at all by the ListView control when you right-clicked a header. This left me stymied. How the heck do I implement this feature? I discovered something of a "hack" however, in that when the ListView's ContextMenuStrip property is set, that ContextMenu Strip will be shown regardless of the location the ListView is clicked. This at least gave me something to work with. Since a ContextMenuStrip's "Opening" event can be easily hooked, we can use that as an entry point and perform needed calculations to determine if we are indeed on a columnheader. Which brings me to the next problem, which is determining when a columnheader was in fact the item that was clicked. This requires determining the rectangle the Header control occupies, first. The Header Control is a child control of the ListView; as such, a platform Invoke using the EnumChildWindows() API was required, something like this: private Rectangle _HeaderRect; private delegate bool EnumWindowsCallBack(IntPtr hwnd,IntPtr lparam); [DllImport("user32.dll")] private static extern int EnumChildWindows(IntPtr hwndParent,EnumWindowCallBack callbackFunction,IntPtr lParam); [DllImport("user32.dll"] private static extern bool GetWindowRect(IntPtr hWnd,out RECT lpRect); [StructLayout(LayoutKind.Sequential)] private struct RECT { public int Left; public int Top; public int Right; public int Bottom; } private bool EnumWindowCallback(IntPtr hwnd, IntPtr lParam) { RECT rct; if(!GetWindowRect(hwnd,out rct)) { //first child of the listview should be the header control _HeaderRect=Rectangle.Empty; //likely the listview is not in Details mode, so there is no header control. } else { _HeaderRect = new Rectangle(rct.Left,rct.Top,rct.Right-rct.Left,rct.Bottom-rct.Top); } return false; //cancel enumeration. } private static ColumnHeader[] GetOrderedHeaders(ListView lvw) { ColumnHeader[] returnarray = new ColumnHeader[lvw.Columns.Count]; foreach(ColumnHeader loopheader in lvw.Columns) { returnarray[loopheader.DisplayIndex] = loopheader; } return returnarray; } Quite a bit of boilerplate to add in. Basically, the idea is that we will hook the contextMenu Opening event of the Listview, (and we add a context menu to hook if the listview in fact doesn't have one) in our constructor; and then when we receive the event we need to determine if the click occured within the area of the header control of the listview, if so, we cancel the event (which stops the default context menu from appearing) and show our own menu for the columnheader, which we can acquire using a bit of math and the static "GetOrderedHeaders" function, which retrieves the array of columnheaders of a ListView in order of appearance Left to Right (since the user could rearrange the Columns). So First, we need to add code to the GenericListViewSorter's Constructor. We also have a few private variables that are added; in this case, we need a ContextMenuStrip variable called "_ghostStrip" which we will use if we need to create a context menu for the control, since we don't want that to appear in the default case. Of course we create our own ContextMenuStrip which we will show in the event instead of the default when appropriate. so we add this beneath the existing code in the constructor: if(handleListView.ContextMenuStrip==null) { handleListView.ContextMenuStrip = new ContextMenuStrip(); handleListView.ContextMenuStrip.Items.Add("GHOST"); //add a ghost item so we get the Opening Event _ghoststrip = handleListView.ContextMenuStrip; } //create OUR context menu _headerContextMenuStrip = new ContextMenuStrip(); //add a ghost item to make sure Opening will fire. _HeaderContextMenuStrip.Items.Add("ghost"); handleListView.ContextMenuStrip.Opening += ContextMenuStrip_Opening; handleListView.ContextMenuStripChanged += handleListView_ContextMenuStripChanged; Of course we need to add the two referenced event handlers, too. The ContextMenuStripChanged being a rather simple implementation designed to keep changes in the contextmenu of the listview from causing us to balls up and stop showing ours (since we are now hooking a orphaned context menu not being shown by the listview). void handleListView_ContextMenuStripChanged(object sender,EventArgs e) { OurListView.ContextMenuStrip.Opening+=ContextMenuStrip_Opening; } Now the meat of the code is in the ContextMenuStrip_Opening() routine. This will need to determine wether its applicable to show the Column menu, or the already present menu (which it doesn't show either if it happens to be the _ghoststrip). This is accomplished by use of the GetCursorPos() API routine paired with the already present GetWindowRect() implementation, which we update by calling EnumWindows. void ContextMenuStrip_Opening(object sender,System.ComponentModel.CancelEventArgs e) { //first, get screen coordinates of Cursor. POINTAPI gapi; GetCursorPos(out gapi); Point gotposition = new Point(gapi.X,gapi.Y); //acquire the HeaderRect of the control... EnumChildWindows(OurListView.Handle,new EnumWindowCallBack(EnumWindowCallback),IntPtr.Zero); //if the mouse position is within the retrieved rectangle, cancel the display of the normal menu and create and show ours. if(_HeaderRect.Contains(gotposition)) { e.Cancel=true; int xoffset = gotposition.X - _HeaderRect.Left; ColumnHeader clickedheader = HeaderAtOffset(OurListView,xoffset); if(clickedheader != null) { //create the context menu as needed. _HeaderContextMenuStrip = new ContextMenuStrip(); _HeaderContextMenuStrip.Tag = clickedheader; //two items, one for ascending order, one for descending order. ToolStripMenuItem AscendingHeaderItem = new ToolStripMenuItem(String.Format("Sort Column \"{0}\" Ascending",clickedheader.Text)); ToolStripMenuItem DescendingHeaderItem = new ToolStripMenuItem(String.Format("Sort Column \"{1}\" Descending",clickedheader.Text)); //if the current sort column is the header, check it off and disable it. if(CurrentSortColumn == clickedheader) { if(OurListView.Sorting ==SortOrder.Ascending) { AscendingHeaderItem.Checked=true; AscendingHeaderItem.Enabled=false; } else if (OurListView.Sorting==SortOrder.Descending) { DescendingHeaderItem.Checked=true; DescendingHeaderItem.Enabled=false; } } AscendingHeaderItem.Tag = ClickedHeader; DescendingHeaderItem.Tag = ClickedHeader; //set event handlers for the two items. AscendingHeaderItem.Click+= AscendingHeaderItem_Click; DescendingHeaderItem.Click+= DescendingHeaderItem_Click; //add them to the context menu strip. _HeaderContextMenuStrip.Items.Add(AscendingHeaderItem); _HeaderContextMenuStrip.Items.Add(DescendingHeaderItem); //display the menu. _HeaderContextMenuStrip.Show(gotposition); } } else { //show the default menu, but only if it isn't the ghoststrip. if(OurListView.ContextMenuStrip == _ghoststrip) e.Cancel=true; } } The events for the two buttons basically sort based on the columnheader in their tag, nothing particularly special there. the actual details can be seen in the source file itself, really. It actually works quite well, I'm using it in a production application, and it's working quite well. Some obvious enhancements, of course, include making it possible to customize the shown menu, to present other options; perhaps a delegate or event that can be hooked that is given the Strip and the clicked column, and any number of other parameters? This would essentially give the equivalent of a ColumnHeaderRightClicked type event, too.

As I posted previously here, Sorting a Listview can be something of a pain in the ass.

In that article, I covered some basics on providing a class that would essentially give you sorting capabilities for free, without all the messy code that would normally be required. A lot of the code required for sorting is mostly boilerplate with a few modifications for sorting various types. As a result, the generic implementation works rather well.

However, as with any class, adding features never hurts. In this case, I got to thinking- why not have right-clicking the ColumnHeaders show a menu for sorting against that Column? Seems simple enough. I quickly learned that apparent simplicity often is misattributed.

I faced several issues. The first thought was that I could hook a Mouse event for Right-Clicking a column header. Unfortunately, I soon discovered two facts about the .NET ListView control. First, was that there was no event for right-clicking a header control. Second, no even was fired at all by the ListView control when you right-clicked a header.

This left me stymied. How the heck do I implement this feature? I discovered something of a “hack” however, in that when the ListView’s ContextMenuStrip property is set, that ContextMenu Strip will be shown regardless of the location the ListView is clicked. This at least gave me something to work with. Since a ContextMenuStrip’s “Opening” event can be easily hooked, we can use that as an entry point and perform needed calculations to determine if we are indeed on a columnheader.

Which brings me to the next problem, which is determining when a columnheader was in fact the item that was clicked. This requires determining the rectangle the Header control occupies, first. The Header Control is a child control of the ListView; as such, a platform Invoke using the EnumChildWindows() API was required, something like this:

private Rectangle _HeaderRect;
private delegate bool EnumWindowsCallBack(IntPtr hwnd,IntPtr lparam);
[DllImport("user32.dll")]
private static extern int EnumChildWindows(IntPtr hwndParent,EnumWindowCallBack callbackFunction,IntPtr lParam);
[DllImport("user32.dll"]
private static extern bool GetWindowRect(IntPtr hWnd,out RECT lpRect);

[StructLayout(LayoutKind.Sequential)]
private struct RECT
{
    public int Left;
    public int Top;
    public int Right;
    public int Bottom;

}

private bool EnumWindowCallback(IntPtr hwnd, IntPtr lParam)
{
    RECT rct;
    if(!GetWindowRect(hwnd,out rct))
    {
    //first child of the listview should be the header control
    _HeaderRect=Rectangle.Empty; //likely the listview is not in Details mode, so there is no header control.
    }
    else
    {
        _HeaderRect = new Rectangle(rct.Left,rct.Top,rct.Right-rct.Left,rct.Bottom-rct.Top);
    }
    return false; //cancel enumeration.
}
private static ColumnHeader[] GetOrderedHeaders(ListView lvw)
{
    ColumnHeader[] returnarray = new ColumnHeader[lvw.Columns.Count];
    foreach(ColumnHeader loopheader in lvw.Columns)
    {
        returnarray[loopheader.DisplayIndex] = loopheader;

    }
    return returnarray;
}

Quite a bit of boilerplate to add in. Basically, the idea is that we will hook the contextMenu Opening event of the Listview, (and we add a context menu to hook if the listview in fact doesn’t have one) in our constructor; and then when we receive the event we need to determine if the click occured within the area of the header control of the listview, if so, we cancel the event (which stops the default context menu from appearing) and show our own menu for the columnheader, which we can acquire using a bit of math and the static “GetOrderedHeaders” function, which retrieves the array of columnheaders of a ListView in order of appearance Left to Right (since the user could rearrange the Columns).

So First, we need to add code to the GenericListViewSorter’s Constructor. We also have a few private variables that are added; in this case, we need a ContextMenuStrip variable called “_ghostStrip” which we will use if we need to create a context menu for the control, since we don’t want that to appear in the default case. Of course we create our own ContextMenuStrip which we will show in the event instead of the default when appropriate. so we add this beneath the existing code in the constructor:

    if(handleListView.ContextMenuStrip==null)
    {
        handleListView.ContextMenuStrip = new ContextMenuStrip();
        handleListView.ContextMenuStrip.Items.Add("GHOST"); //add a ghost item so we get the Opening Event
        _ghoststrip = handleListView.ContextMenuStrip;
}

//create OUR context menu
_headerContextMenuStrip = new ContextMenuStrip();
//add a ghost item to make sure Opening will fire.
_HeaderContextMenuStrip.Items.Add("ghost");
handleListView.ContextMenuStrip.Opening += ContextMenuStrip_Opening;
handleListView.ContextMenuStripChanged += handleListView_ContextMenuStripChanged;

Of course we need to add the two referenced event handlers, too. The ContextMenuStripChanged being a rather simple implementation designed to keep changes in the contextmenu of the listview from causing us to balls up and stop showing ours (since we are now hooking a orphaned context menu not being shown by the listview).

void handleListView_ContextMenuStripChanged(object sender,EventArgs e)
{
    OurListView.ContextMenuStrip.Opening+=ContextMenuStrip_Opening;
}

Now the meat of the code is in the ContextMenuStrip_Opening() routine. This will need to determine wether its applicable to show the Column menu, or the already present menu (which it doesn’t show either if it happens to be the _ghoststrip). This is accomplished by use of the GetCursorPos() API routine paired with the already present GetWindowRect() implementation, which we update by calling EnumWindows.

void ContextMenuStrip_Opening(object sender,System.ComponentModel.CancelEventArgs e)
{
    //first, get screen coordinates of Cursor.
    POINTAPI gapi;
    GetCursorPos(out gapi);

    Point gotposition = new Point(gapi.X,gapi.Y);

    //acquire the HeaderRect of the control...
    EnumChildWindows(OurListView.Handle,new EnumWindowCallBack(EnumWindowCallback),IntPtr.Zero);
    //if the mouse position is within the retrieved rectangle, cancel the display of the normal menu and create and show ours.
    if(_HeaderRect.Contains(gotposition))
    {
        e.Cancel=true;
        int xoffset = gotposition.X - _HeaderRect.Left;
        ColumnHeader clickedheader = HeaderAtOffset(OurListView,xoffset);

        if(clickedheader != null)
        {
        //create the context menu as needed.
        _HeaderContextMenuStrip = new ContextMenuStrip();
        _HeaderContextMenuStrip.Tag = clickedheader;
        //two items, one for ascending order, one for descending order.
        ToolStripMenuItem AscendingHeaderItem = new ToolStripMenuItem(String.Format("Sort Column \"{0}\" Ascending",clickedheader.Text));
        ToolStripMenuItem DescendingHeaderItem = new ToolStripMenuItem(String.Format("Sort Column \"{1}\" Descending",clickedheader.Text));

        //if the current sort column is the header, check it off and disable it.

        if(CurrentSortColumn == clickedheader)
        {
            if(OurListView.Sorting ==SortOrder.Ascending)
            {
                AscendingHeaderItem.Checked=true;
                AscendingHeaderItem.Enabled=false;
            }
            else if (OurListView.Sorting==SortOrder.Descending)
            {
              DescendingHeaderItem.Checked=true;
              DescendingHeaderItem.Enabled=false;
            }   

        }
        AscendingHeaderItem.Tag = ClickedHeader;
        DescendingHeaderItem.Tag = ClickedHeader;
        //set event handlers for the two items.
        AscendingHeaderItem.Click+= AscendingHeaderItem_Click;
        DescendingHeaderItem.Click+= DescendingHeaderItem_Click;
        //add them to the context menu strip.
        _HeaderContextMenuStrip.Items.Add(AscendingHeaderItem);
        _HeaderContextMenuStrip.Items.Add(DescendingHeaderItem);
        //display the menu.
        _HeaderContextMenuStrip.Show(gotposition);
        }
   }
   else
   {
       //show the default menu, but only if it isn't the ghoststrip.
       if(OurListView.ContextMenuStrip == _ghoststrip)
           e.Cancel=true;

   }   

}

The events for the two buttons basically sort based on the columnheader in their tag, nothing particularly special there. the actual details can be seen in the source file itself, really.

It actually works quite well, I’m using it in a production application, and it’s working quite well.

Some obvious enhancements, of course, include making it possible to customize the shown menu, to present other options; perhaps a delegate or event that can be hooked that is given the Strip and the clicked column, and any number of other parameters? This would essentially give the equivalent of a ColumnHeaderRightClicked type event, too.

Or, at least that's what I am calling it. The .NET framework provides quite a rich set of data structures for dealing with Dates. You've got DateTime which represents a single point in time, You've got TimeSpan which represents a interval. However I noticed something somewhat absent- a DateTime Range, with a start time, and an ending time. This came about because I required a way to coalesce a set of DateTime's organized as Starting and Ending time so that there weren't any overlaps. For example, if I had datetimes for one interval from 9AM to 12PM, another from 8AM to 11AM, and a third from 5PM to 9PM, the coalesced result would be two intervals, one from 8AM to 12PM, and one from 5PM to 9PM. Basically, the point was to "simplify" a set of datetime intervals so that overlapping time would not be counted. At first, I figured it would be built-in functionality of one of the DateTime classes. It's not. so I did some googling, no real luck there either. So, I decided to write my own "DateRange" class that encapsulated a Start Time and an Ending time and had the functionality I required. Obviously, the first thing we know is that the class is going to need Starting Time and Ending Time. Of course, once we've defined the data structures, the tricky part will be the "coalescing" code. The implementations for which can be found in the "CoalesceRanges" and "Coalesce" methods. public class DateRange : ICloneable { private DateTime _StartTime, _EndTime; public DateTime StartTime { get { return _StartTime;}} public DateTime EndTime { get { return _EndTime; }} public TimeSpan Span { get { return EndTime-StartTime; } set { _EndTime = StartTime+value; } } public DateRange(DateTime sTime, DateTime eTime) { if (sTime < eTime) _StartTime = sTime; else _StartTime=eTime; if (sTime > eTime) _EndTime = sTime; else _EndTime=eTime; } public override string ToString() { return "Range:(" + StartTime.ToString() + ")-(" + EndTime.ToString() + ")"; } public static DateRange[] Coalesce(DateRange RangeA, DateRange RangeB) { bool CondA = RangeA.StartTime > RangeB.EndTime; bool CondB = RangeA.EndTime < RangeB.StartTime; bool overlaps = !(CondA || CondB); // bool overlaps = (RangeA.StartTime > RangeB.EndTime) && (RangeA.EndTime < RangeB.StartTime); //overlap exists if neither A or B is true. if (overlaps) { //overlap exists. //create a new starttime the lower of the given two... DateTime newstart, newEnd; if (RangeA.StartTime < RangeB.StartTime) newstart = RangeA.StartTime; else newstart = RangeB.StartTime; if (RangeA.EndTime > RangeB.EndTime) newEnd = RangeA.EndTime; else newEnd = RangeB.EndTime; return new DateRange[] { new DateRange(newstart, newEnd) }; } else { //there is no overlap, return a daterange array with both the same elements. return new DateRange[] { (DateRange)RangeA.Clone(), (DateRange)RangeB.Clone() }; } } public DateRange[] Coalesce(DateRange Otherdaterange) { return DateRange.Coalesce(this, Otherdaterange); } public static DateRange[] CoalesceRanges(DateRange[] ranges) { //coalesces/simplifies a given set of date ranges to the simplest form. For example: /* a * |----| * b * |----| c * |----| * */ //will return an array of two Dateranges: /* a * |-----| * b * |----| * */ //this is the "simplest" reduction of what the previous ranges were. List&lt;daterange&gt; userange = ranges.ToList(); List&lt;daterange&gt; workalist = userange; List&lt;daterange&gt; result = new List&lt;daterange&gt;(); //algorithm //set a flag indicating a coalesce was discovered to true. //iterate while said flag is true. //set flag to false as loop begins. //iterate through every possible pair X and Y in the List. skip iterations where X==Y. //for each possible pairing: //coalesce the two DateRanges. If the results coalesce (the return value array has a length of 1) //mark x and y for removal, set the new Array to be AddRanged() to the List, and break out of both loops, and set the flag saying that //a coalesce was discovered. bool coalescefound =true; while (coalescefound) { List&lt;daterange&gt; removalmarked = new List&lt;daterange&gt;(); List&lt;daterange&gt; addmarked = new List&lt;daterange&gt;(); bool breakouter=false; coalescefound=false; foreach (DateRange x in workalist) { foreach (DateRange y in workalist) { if (x != y) { DateRange[] coalresult = DateRange.Coalesce(x, y); if (coalresult.Length == 1) { coalescefound=true; //add new array to be added... addmarked.AddRange(coalresult); //remove both x and y. We can't remove them here since we are iterating... removalmarked.Add(x); removalmarked.Add(y); breakouter=true; break; } } } if (breakouter) break; //break out of outer iterator if flag set. } //add and remove the marked items. foreach (var removeme in removalmarked) { workalist.Remove(removeme); } foreach (var addme in addmarked) { workalist.Add(addme); } } return workalist.ToArray(); } public object Clone() { return new DateRange(StartTime, EndTime); } } For this case I've decided that I would make the class Immutable. This should make our accessors simpler to implement. As a result, the StartTime and EndTime implementations only define get accessors. I also add a "Span" parameter that actually does change the EndTime in it's setter, so I guess I lied. Oh well. Anyways, the meat of the class is in the various coalescing methods, which makes sense since that is what I sort of wrote the class to do. the class could surely be fleshed out with other, useful methods and properties, but as it is now it meets my own needs admirably so I've not really expanded it past what I've got here.

Or, at least that’s what I am calling it. The .NET framework provides quite a rich set of data structures for dealing with Dates. You’ve got DateTime which represents a single point in time, You’ve got TimeSpan which represents a interval.

However I noticed something somewhat absent- a DateTime Range, with a start time, and an ending time. This came about because I required a way to coalesce a set of DateTime’s organized as Starting and Ending time so that there weren’t any overlaps. For example, if I had datetimes for one interval from 9AM to 12PM, another from 8AM to 11AM, and a third from 5PM to 9PM, the coalesced result would be two intervals, one from 8AM to 12PM, and one from 5PM to 9PM. Basically, the point was to “simplify” a set of datetime intervals so that overlapping time would not be counted.

At first, I figured it would be built-in functionality of one of the DateTime classes. It’s not. so I did some googling, no real luck there either. So, I decided to write my own “DateRange” class that encapsulated a Start Time and an Ending time and had the functionality I required.

Obviously, the first thing we know is that the class is going to need Starting Time and Ending Time. Of course, once we’ve defined the data structures, the tricky part will be the “coalescing” code. The implementations for which can be found in the “CoalesceRanges” and “Coalesce” methods.

For this case I’ve decided that I would make the class Immutable. This should make our accessors simpler to implement. As a result, the StartTime and EndTime implementations only define get accessors. I also add a “Span” parameter that actually does change the EndTime in it’s setter, so I guess I lied. Oh well. Anyways, the meat of the class is in the various coalescing methods, which makes sense since that is what I sort of wrote the class to do. the class could surely be fleshed out with other, useful methods and properties, but as it is now it meets my own needs admirably so I’ve not really expanded it past what I’ve got here.

Anybody who has used windows is probably familiar with the ListView control. It is used in Windows Explorer; it is even used for the desktop. Heck, the ListView control even has implementations on Linux and Mac, and in the latter case it was there first. The ListView itself can display in several modes. Normally, it shows things as Icons. But it can also be set to show Small Icons, a List, in some Operating Systems, there is a 'Tile' option, or even options like Large,Medium, and other sizes of Icons. My Personal favourite is the details mode. [caption id="attachment_877" align="alignleft" width="300" caption="HA! Bet you didn&#39;t expect me to use an image from Windows 95! Expect the unexpected, chaps."][/caption] Because I mostly see and use Listviews in Details mode, I also force people who use my software to deal with Details mode. Mostly because the reason I am displaying a ListView is to show some data in a somewhat tabular format and not just give them a few icons to drag around with minimal actual information, but I digress. Anyway, I think a good question at this point might be to look at what different parts this particular ListView has. First, the gray "buttons" at the top, which serve to title each column, are referred to affectionately as ColumnHeaders. Under each ColumnHeader there is data for a given "subitem" of each item. For example, the "Size" entry here is a Subitem for each drive. An interesting feature of columnheaders that is nearly universal is that you can click on one, and it will sort by that column. Another interesting thing, is that in many programming environments, the ListView control doesn't actually provide this feature for you, and you have to code it yourself. It is rather frustrating. In particular, Visual Basic 6 allows you to sort, but you can't really customize what you sort by; it always treats it as text. In one of my VB6 applications, BCSearch (which is available for download from my Downloadspage) I managed to use a Custom control, available from VBAccelerator.com, which exposes additional functionality of the ListView Control on top of that provided in either of the MS provided libraries for use within Visual Basic. One of these features is that it has better support for sorting. I still had to add my own "arrow" to show the sort direction, though. [caption id="attachment_878" align="alignright" width="150" caption="BCSearch showing results sorted by Size"][/caption] The VBAccelerator control exposes a number of events and properties for controlling sorting, which I use to properly sort the various subitems, so that various entries like date or size aren't sorted as text. Curiously, the .NET Windows Forms ListView control, while having more functionality, still leaves a lot of effort to the programmer for what ideally ought to be a free feature supported by the OS. In fact it IS a free feature supported by the OS. Thankfully, the .NET control does in fact provide a feature for customizing sort functionality, And all you need is a class to implement IComparer. the IComparer will be used to compare the listitems as the Listview sorts. But if you have, say, Date and Time fields and size fields or other fields that can't just be sorted as text, you are going to need to implement your own special comparer for each. This amounts to quite a bit of glue code; on top of that, you will need to handle the ColumnClick events on the ColumnHeader, change the sort mode, and sort it, and so forth. To combat this bloating code, I wrote a relatively small class designed to encapsulate sorting. The idea being that you create a instance of this class for each listview, pass in the ListView to it's constructor, and the class handles all the details. It worked quite well. There was a minor issue that amounted to a gigantic pain in the ass but at the same time made the result a lot better. using System; using System.Collections; using System.Collections.Generic; using System.Diagnostics; using System.Drawing; using System.Linq; using System.Runtime.InteropServices; using System.Text; using System.Windows.Forms; namespace JobClockAdmin { public static class ListViewExtensions { [System.Runtime.InteropServices.StructLayout(LayoutKind.Sequential)] public struct HDITEM { public int mask; public int cxy; [System.Runtime.InteropServices.MarshalAs(UnmanagedType.LPTStr)] public string pszText; public IntPtr hbm; public int cchTextMax; public int fmt; public IntPtr lParam; // _WIN32_IE >= 0x0300 public int iImage; public int iOrder; // _WIN32_IE >= 0x0500 public uint type; public IntPtr pvFilter; // _WIN32_WINNT >= 0x0600 public uint state; [Flags] public enum Mask { Format = 0x4, // HDI_FORMAT }; [Flags] public enum Format { SortDown = 0x200, // HDF_SORTDOWN SortUp = 0x400, // HDF_SORTUP }; }; private const int HDM_FIRST = 0x1200; private const int LVM_FIRST = 0x1000; private const int HDM_GETITEMCOUNT = (HDM_FIRST + 0); private const int HDM_SETITEM = (HDM_FIRST + 4); private const int LVM_GETHEADER = (LVM_FIRST + 31); private const int HDM_GETITEM = (HDM_FIRST + 3); [DllImport("user32.dll", EntryPoint = "SendMessageA")] private static extern IntPtr SendMessage(IntPtr hwnd, int wMsg, IntPtr wParam, IntPtr lParam); [System.Runtime.InteropServices.DllImport("user32.dll", EntryPoint = "SendMessage")] public static extern IntPtr SendMessageHDITEM(IntPtr hWnd, uint Msg, IntPtr wParam, ref HDITEM hdItem); public static void SetSortIcon(this System.Windows.Forms.ListView ListViewControl, int ColumnIndex, System.Windows.Forms.SortOrder Order) { IntPtr ColumnHeader = SendMessage(ListViewControl.Handle, LVM_GETHEADER, IntPtr.Zero, IntPtr.Zero); for (int ColumnNumber = 0; ColumnNumber < = ListViewControl.Columns.Count - 1; ColumnNumber++) { IntPtr ColumnPtr = new IntPtr(ColumnNumber); HDITEM item = new HDITEM(); item.mask = (int)HDITEM.Mask.Format; SendMessageHDITEM(ColumnHeader, HDM_GETITEM, ColumnPtr, ref item); if (!(Order == System.Windows.Forms.SortOrder.None) && ColumnNumber == ColumnIndex) { switch (Order) { case System.Windows.Forms.SortOrder.Ascending: item.fmt &= ~(int)HDITEM.Format.SortDown; item.fmt |= (int)HDITEM.Format.SortUp; break; case System.Windows.Forms.SortOrder.Descending: item.fmt &= ~(int)HDITEM.Format.SortUp; item.fmt |= (int)HDITEM.Format.SortDown; break; } } else { item.fmt &= ~(int)HDITEM.Format.SortDown & ~(int)HDITEM.Format.SortUp; } SendMessageHDITEM(ColumnHeader, HDM_SETITEM, ColumnPtr, ref item); } } } class GenericListViewSorter : IComparer { private System.Windows.Forms.ListView OurListView; //GetCompareValue: given a columnname and a ListViewItem, should return any more specific type. //For example, if Column represents a date value, it would return a DateTime. public delegate Object GetCompareValue(GenericListViewSorter Sorter, String ColumnName, ListViewItem Item); private GetCompareValue CompareValueFunc; private ColumnHeader CurrentSortColumn = null; private SortOrder[] SortOrders = new SortOrder[] { SortOrder.None,SortOrder.Ascending, SortOrder.Descending }; private String[] SortOrderImageKey = new string[] {"CLEAR","ASCENDING","DESCENDING" }; private int CurrSortIndex = 0; private Object GetCompareValue_Default(GenericListViewSorter Sorter, String ColumnName, ListViewItem Item) { //default just returns the String, for now. Later, add special conditions that detect when something is a valid date. Or something... int indexuse = Sorter.OurListView.Columns[ColumnName].Index; return Item.SubItems[indexuse].Text; } public GenericListViewSorter(ListView handleListView,GetCompareValue GetCompareRoutine) { OurListView = handleListView; if (GetCompareRoutine != null) CompareValueFunc = GetCompareRoutine; else CompareValueFunc = GetCompareValue_Default; handleListView.ColumnClick += new ColumnClickEventHandler(handleListView_ColumnClick); } void handleListView_ColumnClick(object sender, ColumnClickEventArgs e) { //throw new NotImplementedException(); //First thing is first: is this the same column that was clicked before? ColumnHeader clickedcolumn = OurListView.Columns[e.Column]; if (CurrentSortColumn == null) { CurrentSortColumn = clickedcolumn; } if (CurrentSortColumn != clickedcolumn) { //if not, set the current sort Index to 0... // CurrentSortColumn.ImageKey = "CLEAR"; //don't want it to keep the image... CurrentSortColumn = clickedcolumn; } else { //if it is the same, increment it and take the modulus... CurrSortIndex = (CurrSortIndex + 1) % (SortOrders.Length); Debug.Print("CurrSortIndex:" + CurrSortIndex); } //CurrentSortColumn.ImageKey = SortOrderImageKey[CurrSortIndex]; OurListView.Sorting = SortOrders[CurrSortIndex]; OurListView.SetSortIcon(CurrentSortColumn.Index, OurListView.Sorting); if (CurrSortIndex == 0) { OurListView.ListViewItemSorter = null; } else { OurListView.ListViewItemSorter = this; } OurListView.Sort(); } #region IComparer Members public int Compare(object x, object y) { ListViewItem a = (ListViewItem)x; ListViewItem b = (ListViewItem)y; String columnnameuse = CurrentSortColumn.Name; Object checkA = CompareValueFunc(this, columnnameuse, a); Object checkB = CompareValueFunc(this, columnnameuse, b); if((checkA is IComparable) && (checkB is IComparable)) { if(OurListView.Sorting==SortOrder.Ascending) return ((IComparable)checkA).CompareTo(checkB); else { return ((IComparable)checkB).CompareTo(checkA); } } return 0; } #endregion } } As you can see, it it relatively small (overall). the API code at the top might be a bit confusing, but it is a result of what can only be described as an oversight on Microsoft's part; see, originally, I was changing the sort arrow header by simply changing the columnheader image. This worked, sorta of, but there was no way to remove the image and it had this weird effect where it would basically move the text and make it aligned sorta weird. Turns out that the way the ListView would "normally" show sort order icons was a built in feature of the Listview since Common Controls 6 (XP). After some SDK digging I was able to use the Platform Invoke feature of C# to call all the appropriate API functions and "force" the Listview to show the sort order in the header appropriately. The class also exposes a custom delegate which can be implemented and passed in to the constructor, which will allow for "custom" sorts. This is useful if columns contain data like dates, or numbers that you don't want to be sorted using the normal "text" comparison. All in all, It's a class I've added to my "toolbox", alongside my INIFile class for accessing INI Files. did I write about that one? I forget.

Anybody who has used windows is probably familiar with the ListView control. It is used in Windows Explorer; it is even used for the desktop. Heck, the ListView control even has implementations on Linux and Mac, and in the latter case it was there first.

The ListView itself can display in several modes. Normally, it shows things as Icons. But it can also be set to show Small Icons, a List, in some Operating Systems, there is a ‘Tile’ option, or even options like Large,Medium, and other sizes of Icons. My Personal favourite is the details mode.

HA! Bet you didn't expect me to use an image from Windows 95! Expect the unexpected, chaps.

Because I mostly see and use Listviews in Details mode, I also force people who use my software to deal with Details mode. Mostly because the reason I am displaying a ListView is to show some data in a somewhat tabular format and not just give them a few icons to drag around with minimal actual information, but I digress. Anyway, I think a good question at this point might be to look at what different parts this particular ListView has. First, the gray “buttons” at the top, which serve to title each column, are referred to affectionately as ColumnHeaders. Under each ColumnHeader there is data for a given “subitem” of each item. For example, the “Size” entry here is a Subitem for each drive. An interesting feature of columnheaders that is nearly universal is that you can click on one, and it will sort by that column.

Another interesting thing, is that in many programming environments, the ListView control doesn’t actually provide this feature for you, and you have to code it yourself. It is rather frustrating. In particular, Visual Basic 6 allows you to sort, but you can’t really customize what you sort by; it always treats it as text. In one of my VB6 applications, BCSearch (which is available for download from my Downloadspage) I managed to use a Custom control, available from VBAccelerator.com, which exposes additional functionality of the ListView Control on top of that provided in either of the MS provided libraries for use within Visual Basic. One of these features is that it has better support for sorting. I still had to add my own “arrow” to show the sort direction, though.

BCSearch showing results sorted by Size

The VBAccelerator control exposes a number of events and properties for controlling sorting, which I use to properly sort the various subitems, so that various entries like date or size aren’t sorted as text.

Curiously, the .NET Windows Forms ListView control, while having more functionality, still leaves a lot of effort to the programmer for what ideally ought to be a free feature supported by the OS. In fact it IS a free feature supported by the OS. Thankfully, the .NET control does in fact provide a feature for customizing sort functionality, And all you need is a class to implement IComparer. the IComparer will be used to compare the listitems as the Listview sorts. But if you have, say, Date and Time fields and size fields or other fields that can’t just be sorted as text, you are going to need to implement your own special comparer for each. This amounts to quite a bit of glue code; on top of that, you will need to handle the ColumnClick events on the ColumnHeader, change the sort mode, and sort it, and so forth.

To combat this bloating code, I wrote a relatively small class designed to encapsulate sorting. The idea being that you create a instance of this class for each listview, pass in the ListView to it’s constructor, and the class handles all the details. It worked quite well. There was a minor issue that amounted to a gigantic pain in the ass but at the same time made the result a lot better.

As you can see, it it relatively small (overall). the API code at the top might be a bit confusing, but it is a result of what can only be described as an oversight on Microsoft’s part; see, originally, I was changing the sort arrow header by simply changing the columnheader image. This worked, sorta of, but there was no way to remove the image and it had this weird effect where it would basically move the text and make it aligned sorta weird. Turns out that the way the ListView would “normally” show sort order icons was a built in feature of the Listview since Common Controls 6 (XP). After some SDK digging I was able to use the Platform Invoke feature of C# to call all the appropriate API functions and “force” the Listview to show the sort order in the header appropriately.

The class also exposes a custom delegate which can be implemented and passed in to the constructor, which will allow for “custom” sorts. This is useful if columns contain data like dates, or numbers that you don’t want to be sorted using the normal “text” comparison.

All in all, It’s a class I’ve added to my “toolbox”, alongside my INIFile class for accessing INI Files. did I write about that one? I forget.

Most Computer users are familiar with the Sounds that Windows emits when you plug and unplug a USB thumb drive. It's a useful form of auditory feedback that the drive was in fact detected. However, I've found linux to be oddly tacit in this regard. So I set to work writing a python script that uses DBUS to monitor for new USB devices and will play a sound whenever a new Volume is attached. #!/usr/bin/python #by BC_Programming import dbus import gobject import time import subprocess print "BASeCamp 'USBSounds' Simple USB Volume notification sound." #playsound merely shells out to mplayer. I would have preferred an integrated solution but... meh. def playsound(soundfile): subprocess.call(["mplayer", "hardwareinsert.wav"], stdout=open('/dev/null', 'w'), stderr=open('/dev/null', 'w')) class DeviceAddedListener: def __init__(self): #get the system bus... self.bus = dbus.SystemBus() #get the manager self.hal_manager_obj = self.bus.get_object( 'org.freedesktop.Hal', '/org/freedesktop/Hal/Manager') #get the interface for the manager self.hal_manager = dbus.Interface(self.hal_manager_obj,'org.freedesktop.Hal.Manager') #connect to the appropriate signals. self.hal_manager.connect_to_signal('DeviceAdded', self._filteradd) self.hal_manager.connect_to_signal("DeviceRemoved",self._filterremove) #note: I couldn't get DeviceRemoval sounds to work since it doesn't let you #inspect whether the removed device is a volume via "QueryCapability"... since it's gone. def _filteradd(self, udi): device_obj = self.bus.get_object ('org.freedesktop.Hal', udi) device = dbus.Interface(device_obj, 'org.freedesktop.Hal.Device') #if it is a volume, call the do_add function... if device.QueryCapability("volume"): return self.do_add(device) def _filterremove(self,udi): try: #device_obj = self.bus.get_object('org.freedesktop.Hal',udi) #device = dbus.Interface(device_obj,'org.freedesktop.Hal.Device') #if device.QueryCapability("volume"): # return self.do_remove(device) except: return #unused.... def do_remove(self,volume): playsound("hardwareremove.wav") #displays some info about the added device to the console (maybe future changes can pop stuff like volume label, device file, size, etc into a Notification box?) def do_add(self, volume): device_file = volume.GetProperty("block.device") label = volume.GetProperty("volume.label") fstype = volume.GetProperty("volume.fstype") mounted = volume.GetProperty("volume.is_mounted") mount_point = volume.GetProperty("volume.mount_point") try: size = volume.GetProperty("volume.size") except: size = 0 print "New storage device detected:" print " device_file: %s" % device_file print " label: %s" % label print " fstype: %s" % fstype if mounted: print " mount_point: %s" % mount_point else: print " not mounted" print " size: %s (%.2fGB)" % (size, float(size) / 1024**3) #and play a sound. playsound("hardwareinsert.wav") #main loop... if __name__ == '__main__': from dbus.mainloop.glib import DBusGMainLoop DBusGMainLoop(set_as_default=True) loop = gobject.MainLoop() print "in __main__..." DeviceAddedListener() loop.run() As can be seen, it's a tad messy, and even rather hackish. For one thing, it uses DBUS, which to my understanding is deprecated. Unfortunately, the replacement I couldn't really get a clear answer on. From what I can gather, the proper method for now is libnotify and pynotify, but I couldn't get libnotify to compile and thus was not able to properly use pynotify, and I didn't want to have to force people to go through that sort of hell when they tried to use my script, so I stuck to DBUS. The only limitation I discovered is that on device removal, you can't really inspect what device was removed. At first I just figured, Just play the sound everytime and let the user figure it out, but for some reason that just assaulted me with constant device removal sounds. So I ended up commenting (and I think removing) that particular segment of code. Playing Sounds is unnecessarily difficult in Python, or more specifically, Linux. It's ridiculous. First I found a build in module for python, ossdevsound (or something to that effect), but attempts to use that failed because apparently it uses OSS, which apparently was replaced by ALSA for whatever reason. So I tried pygame, which errored out that I had no mixer device when I tried to initialize the mixer. So I decided to hell with it and just spawned a mplayer process, and redirected it's stdout to NULL to avoid the nasty business where it barfs all over the console. And amazingly, that seems to work fine for device insertions, which I decided I was content with. By default I use the Windows insertion and removal sound files. The removal sound isn't actually used but I kept it in the g-zipped tar because I wanted to. Personally I usually just launch this in a terminal and then tuck it away on another desktop. No doubt one can execute it as a daemon or something instead and get the functionality without the console window baggage to keep around, though. ThumbNotify.tar.gz

Most Computer users are familiar with the Sounds that Windows emits when you plug and unplug a USB thumb drive. It’s a useful form of auditory feedback that the drive was in fact detected. However, I’ve found linux to be oddly tacit in this regard. So I set to work writing a python script that uses DBUS to monitor for new USB devices and will play a sound whenever a new Volume is attached.

As can be seen, it’s a tad messy, and even rather hackish. For one thing, it uses DBUS, which to my understanding is deprecated. Unfortunately, the replacement I couldn’t really get a clear answer on. From what I can gather, the proper method for now is libnotify and pynotify, but I couldn’t get libnotify to compile and thus was not able to properly use pynotify, and I didn’t want to have to force people to go through that sort of hell when they tried to use my script, so I stuck to DBUS.

The only limitation I discovered is that on device removal, you can’t really inspect what device was removed. At first I just figured, Just play the sound everytime and let the user figure it out, but for some reason that just assaulted me with constant device removal sounds. So I ended up commenting (and I think removing) that particular segment of code.

Playing Sounds is unnecessarily difficult in Python, or more specifically, Linux. It’s ridiculous. First I found a build in module for python, ossdevsound (or something to that effect), but attempts to use that failed because apparently it uses OSS, which apparently was replaced by ALSA for whatever reason. So I tried pygame, which errored out that I had no mixer device when I tried to initialize the mixer. So I decided to hell with it and just spawned a mplayer process, and redirected it’s stdout to NULL to avoid the nasty business where it barfs all over the console. And amazingly, that seems to work fine for device insertions, which I decided I was content with.

By default I use the Windows insertion and removal sound files. The removal sound isn’t actually used but I kept it in the g-zipped tar because I wanted to. Personally I usually just launch this in a terminal and then tuck it away on another desktop. No doubt one can execute it as a daemon or something instead and get the functionality without the console window baggage to keep around, though.

ThumbNotify.tar.gz

It's a relatively trivial task, really easy to do with the command prompt and GNU wc: for /f "delims=" %P in ('dir /s /b *.cs') do wc -l "%P" >> D:\codewordcounts.txt I executed this within the desired directory (my BASeBlock source folder, if you must know) and the result was a file filled with numbers and files; I wrote a quick python script to parse that and add up the numbers that were at the start of each line, but then I figured, why not just write the whole think in python and forget about the rest of it, so I did. #!/usr/bin/python import sys import fnmatch import os def searchfolder(folder,filemask,excludemask): filelist=[] for root,subFolders,files in os.walk(folder): for file in files: buildpath=os.path.join(root,file) if os.path.isfile(buildpath): if fnmatch.fnmatch(buildpath,filemask): if not fnmatch.fnmatch(buildpath,excludemask): filelist.append(buildpath) return filelist def Countlines(filename): #counts the lines in filename. countit = open(filename) runner=0 for line in countit: runner=runner+1 return runner searchfor = sys.argv[1] searchin = sys.argv[2] excludethese = sys.argv[3] print "examining files matching " + searchfor + " in directory " + searchin + " excluding " + excludethese totalcount=0 for countthese in searchfolder(searchin,searchfor,excludethese): #print Countlines(countthese) totalcount = totalcount + Countlines(countthese) print "total line count:" + totalcount It's a rather basic script, and I don't even comment it as much as I ought to. I just wanted a quick tool to be able to count the lines of code in a given directory for a given source file type. Ideally, I'd allow for multiple types, but I didn't want to complicate the argument parsing code too much. The counting method is pretty barren, it just loops over every line and increments a counter. It seems to work relatively fast. It quickly gave me the result I wanted, which was that BASeBlock's .cs files comprise about 53K lines of code, excluding the .designer.cs files (thus the third argument). And now I have a nice reusable script to figure this out in a jiffy without too much thinking about shell syntax or what I need to pipe to wc and what arguments I need to pass wc and whatnot. plonked in a location on my windows machine with pathext set to allow execution of .py files directly using the ActivePython interpreter and putting it on my Linux machine and adding a symlink in /usr/bin to it makes it available to me on both machines.

It’s a relatively trivial task, really easy to do with the command prompt and GNU wc:

I executed this within the desired directory (my BASeBlock source folder, if you must know) and the result was a file filled with numbers and files; I wrote a quick python script to parse that and add up the numbers that were at the start of each line, but then I figured, why not just write the whole think in python and forget about the rest of it, so I did.

It’s a rather basic script, and I don’t even comment it as much as I ought to. I just wanted a quick tool to be able to count the lines of code in a given directory for a given source file type. Ideally, I’d allow for multiple types, but I didn’t want to complicate the argument parsing code too much. The counting method is pretty barren, it just loops over every line and increments a counter. It seems to work relatively fast. It quickly gave me the result I wanted, which was that BASeBlock’s .cs files comprise about 53K lines of code, excluding the .designer.cs files (thus the third argument). And now I have a nice reusable script to figure this out in a jiffy without too much thinking about shell syntax or what I need to pipe to wc and what arguments I need to pass wc and whatnot. plonked in a location on my windows machine with pathext set to allow execution of .py files directly using the ActivePython interpreter and putting it on my Linux machine and adding a symlink in /usr/bin to it makes it available to me on both machines.

So, as mentioned in the previous post, I added a "sort" of scriptability to BASeBlock. I made some tweaks, and refactored the code so it was a bit more abstracted; the original implementation was directly in the MultiTypeManager, but that didn't really have anything to do with it, so I tweaked some of the parameters to a few methods there, added a new class with the static routines required for the needed functionality, etc. I also made it so that a "BASeBlock Script Group file" (.bbsg extension) could be used to both compile a set of files into an assembly, as well as include various other assemblies as required. Future additions will probably include the ability for each assembly to define a sort of "main" method, which can be called when the assembly is initialized. However, once again, Serialization was the constant thorn in my side. I was able to mess about with a custom block written in a .cs script, and it even saved properly. But the game encountered an exception when I tried to open that LevelSet; I forget the specifics, something to the tune of "failed to find assembly"  type of error. What could I do?  SerializationBinder What this basically meant was I was going to have to learn even more about the Serialization structure of .NET. Specifically, SerializationBinder's. The concept was actually quite simple. You basically just derive a type from SerializationBinder, and use that as the .Binder property on a IFormatter class, overriding one method seems to be enough for the most part: &nbsp; Type BindToType(string assemblyName, string typeName) &nbsp; Simple! it gives you an assembly Name, a Type Name, and you simply return the appropriate type. The reason the default implementation wasn't working was certainly as a result of the assembly being loaded dynamically, since it wasn't [i]really[/i] being referenced by the BASeBlock assembly, so the default implementation didn't find the "plugin" class assembly or the appropriate type, so threw an exception. The trick here is not to enumerate the referenced assemblies, but rather to use all loaded assemblies in the current AppDomain. The general consensus with regards to using CodeDOM and compiling things like this is to compile them to their own AppDomain; however, since the assemblies were being kept "alive" for the duration of the application, that wasn't necessary, and in this case would have complicated things. Well, it would have complicated things more than they already were. The "AssemblyName" parameter, however, was more akin to the FullName property of the System.Reflection.Assembly; for example, BASeBlock's assembly would (for the current version) be passed in as "BASeBlock, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null". Since we are only interested in the actual name of the assembly, we can simply grab everything up to the first comma. Armed with the Assembly's base name, we can start enumerating all the loaded Assemblies and looking for a match: public override Type BindToType(string assemblyName, string typeName) { try { string BaseAssemblyName = assemblyName.Split(',')[0]; Assembly[] Assemblies = AppDomain.CurrentDomain.GetAssemblies(); foreach (Assembly loopassembly in Assemblies) { if (loopassembly.FullName.Split(',')[0].Equals(BaseAssemblyName,StringComparison.OrdinalIgnoreCase)) { return loopassembly.GetType(typeName); } } } catch (System.Exception exception) { throw exception; } return null; } Then, we compare the Assembly.FullName.Split(',')[0] (the text before the first comma) to the modified string, BaseAssemblyName that was changed in the same manner. I decided to go string insensitive for no reason; mostly because the assembly names for the scripts are formed from the filenames and I wouldn't want filename capitalization to prevent a script from serializing/deserializing properly. If we find a matching assembly, we return the result of a GetType() call to that assembly with the same typename passed in as a parameter to the method. The Formatter will than attempt to deserialize the data it has to that type as needed. There are a few issues with this- for one thing, it doesn't work with Generic types. At least, I assume it doesn't; I assume I would need some special code to get the appropriate Type for a generic type given type arguments. I'll cross that bridge when I come to it. Right now, I've not actually tested this extensively. My main concern would be to test that it can serialize in one session, and deserialize in another. This concern is based on the fact that the two assemblies would in that case be literally distinct- in that it would have been compiled on two occasions. Assuming the Binder is enough to convince the serializer it can deserialize something, there shouldn't be any issues. Once I decide to figure out how to add Generics support to this Binder, I'll definitely write about it here.

So, as mentioned in the previous post, I added a “sort” of scriptability to BASeBlock.

I made some tweaks, and refactored the code so it was a bit more abstracted; the original implementation was directly in the MultiTypeManager, but that didn’t really have anything to do with it, so I tweaked some of the parameters to a few methods there, added a new class with the static routines required for the needed functionality, etc. I also made it so that a “BASeBlock Script Group file” (.bbsg extension) could be used to both compile a set of files into an assembly, as well as include various other assemblies as required. Future additions will probably include the ability for each assembly to define a sort of “main” method, which can be called when the assembly is initialized.

However, once again, Serialization was the constant thorn in my side. I was able to mess about with a custom block written in a .cs script, and it even saved properly.

But the game encountered an exception when I tried to open that LevelSet; I forget the specifics, something to the tune of “failed to find assembly”  type of error. What could I do?

 SerializationBinder

What this basically meant was I was going to have to learn even more about the Serialization structure of .NET. Specifically, SerializationBinder’s. The concept was actually quite simple. You basically just derive a type from SerializationBinder, and use that as the .Binder property on a IFormatter class, overriding one method seems to be enough for the most part:

Simple! it gives you an assembly Name, a Type Name, and you simply return the appropriate type. The reason the default implementation wasn’t working was certainly as a result of the assembly being loaded dynamically, since it wasn’t [i]really[/i] being referenced by the BASeBlock assembly, so the default implementation didn’t find the “plugin” class assembly or the appropriate type, so threw an exception.

The trick here is not to enumerate the referenced assemblies, but rather to use all loaded assemblies in the current AppDomain. The general consensus with regards to using CodeDOM and compiling things like this is to compile them to their own AppDomain; however, since the assemblies were being kept “alive” for the duration of the application, that wasn’t necessary, and in this case would have complicated things. Well, it would have complicated things more than they already were.

The “AssemblyName” parameter, however, was more akin to the FullName property of the System.Reflection.Assembly; for example, BASeBlock’s assembly would (for the current version) be passed in as “BASeBlock, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null”. Since we are only interested in the actual name of the assembly, we can simply grab everything up to the first comma.

Armed with the Assembly’s base name, we can start enumerating all the loaded Assemblies and looking for a match:

Then, we compare the Assembly.FullName.Split(‘,’)[0] (the text before the first comma) to the modified string, BaseAssemblyName that was changed in the same manner. I decided to go string insensitive for no reason; mostly because the assembly names for the scripts are formed from the filenames and I wouldn’t want filename capitalization to prevent a script from serializing/deserializing properly. If we find a matching assembly, we return the result of a GetType() call to that assembly with the same typename passed in as a parameter to the method. The Formatter will than attempt to deserialize the data it has to that type as needed.

There are a few issues with this- for one thing, it doesn’t work with Generic types. At least, I assume it doesn’t; I assume I would need some special code to get the appropriate Type for a generic type given type arguments. I’ll cross that bridge when I come to it.

Right now, I’ve not actually tested this extensively. My main concern would be to test that it can serialize in one session, and deserialize in another. This concern is based on the fact that the two assemblies would in that case be literally distinct- in that it would have been compiled on two occasions. Assuming the Binder is enough to convince the serializer it can deserialize something, there shouldn’t be any issues. Once I decide to figure out how to add Generics support to this Binder, I’ll definitely write about it here.

When I first started developing BASeBlock, the basic idea was just to get a feel for how Animation, rendering, and other concepts were dealt with in C#, as opposed to the aging language I was familiar with VB6. Additionally, I wanted to make use of Threading. After getting through the initial hurdles and issues related to the type of code I would need to write with BCDodger, I had a good idea the type of things I needed for BASeBlock. &nbsp; BASeBlock's actual Game information is, not surprisingly, kept inside a instance of a "BCBlockGameState" object. There are a few folly's in my design, whereby some elements that would probably be best placed as members of BCBlockGameState are in fact members of the main form, but everything works well as it is, and if necessary objects can get a reference to the form itself using the BCBlockGameState ClientObject property, which is a interface that defines the type of stuff that is more implementation specific than ought to be in the State instance. Rendering is managed entirely within the Paint event of the main form's PictureBox- (and likewise for the Editor). Rendering and the actual GameProc() routine (that makes things happen) are similar; they both iterate through the various objects in the game and call methods. The GameProc() routine animates balls, GameObjects, Particles, and AnimatedBlocks; the Paint event basically iterates through all those objects and get's them to paint on a bitmap which is them blitted to the PictureBox when necessary. Of course having these two activities on separate threads meant  that I tripped on a few things while I was getting started- not locking this variable, trying to call methods of the form from within the game loop, and other similar contention issues. All of those have been resolved, to the best of my knowledge. Another goal while working on BASeBlock was to make it easier for the creation of new blocks. The way the older Poing game (VB6) did it was to only have a single Block object, which had an Enumeration that determined what kind of block it really was. This had the issue whereby the Block had a lot of fields that were only applicable with certain block types, and weren't applicable at all otherwise. This was a primarily a result of the fact that VB6 isn't really an Object Oriented Language, but rather an Object-Based Language; while you can fake Implementation Inheritance using the Implements keyword and an aggregate class, it's a lot of boilerplate that I couldn't be bothered with for little gain. With C#, and more importantly proper OOP constructs, I could try my hand at a more reasonable Object heirarchy. Collections By far one of the most annoying things to deal with in VB6 is collections. they are finicky, and more importantly, the built-in Collection class only deals with Objects, so I would have to cast variables all over the place, and casting in VB6 means actually declaring another variable of that type and using Set to attempt the assignment to perform the "cast". The only "workaround" is to create a entirely new class that uses a Collection internally but exposes the members of that Collection as the more specific type, as well as having Strongly-Typed parameters for Addition of blocks and removal. But the creation of these classes: Is a gigantic pain in the ass. They are almost all exactly the same, differing only in the Type used. Clouds the namespace. Poing has a Levels.cls class, a Blocks.cls class, a Balls.cls class, and a few others, all for the sole purpose of representing the exact same data structure for different objects. Is a gigantic pain in the ass. I already said that, but I just wanted to make sure I was clear about that. While you can use For...Each on the collection, it's only through non-standard coding and setting method properties that it works, and even then you have very little control since the Interface being used for Enumeration, IEnumVariant is not easily implemented in VB6, and requires literally hacking away at your Process Memory to change in-memory VTables, which wreaks havoc on the brittle IDE. Now, thanks to my Switch-over to C#, I can just declare those variables to be List&lt;Block&gt; or List&lt;Level&gt; or List&lt;cBall&gt; and forget about all this special Collection class nonsense. And Of course for specific Data Structures, I can use various other Generic classes such as Stack&lt;&gt;, LinkedList&lt;&gt;, etc. Generics is a powerful feature that becomes that much more valuable when you've had to hoof it yourself in less powerful languages to duplicate it's functionality. Dynamic Loading But, this is supposed to be about dynamic loading- and more specifically, Reflection. Visual Basic 6 sorta-kinda had reflection, in the form of a MS-provided library, tlbinfo32.dll, which essentially allowed you to inspect COM components; since VB6 produced COM components, this worked there. But it was still rather cumbersome; you were no longer looking at VB-native classes or types, but you had to interpret the appropriate parameters from the idl code. additionally, COM was often just plain stubborn. I feel that in many ways .NET tries to resolve the issues of COM, particular with regards to pluggable components. .NET allows you to, directly in your code, load a new assembly, inspect the classes and types within that assembly- see what those classes implement or derive from, and so forth. Java provides equal functionality with it's reflection libraries, too, and  that is how a lot of java applications implement plugins, including eclipse, one of the better java IDE applications. With C# &amp; .NET, you can load assemblies directly from the .dll or .exe file; then you have the Assembly object, and can inspect the types of t hat Object. BASeBlock, for example, loads all the assemblies (that don't meet an "ignore" regular expression) from it's executable's folder- I'll probably change this to a unique location, to prevent the game from enumerating the assemblies I included which will never contain what it is looking for). Once it has all the assemblies, it searches for various Types that implement some of it's types. It always inspects "itself", so it will find all the Block derivations, iBallBehaviour implementations, iPaddleBehaviour, etc. These get added to their own LoadedTypeManager instances within the MultiTypeManager that does all the work, and this allows the BASeBlock code to easily find all the implementations of it's various interfaces, for purposes such as showing a pop-up menu and so forth. Originally, I wanted to add a single implementation of the appropriate interfaces and base classes,  that delegated their actions/events/etc to some sort of script interpreter/compiler. After futzing about with IronPython, however, I decided  that the object model exposed there and what I needed required a lot of plumbing code to make managable. But then I had another thought. The CodeDOM .NET Exposes a namespace, System.Runtime.CompilerServices that contains more namespaces, classes, and interfaces that are used for dealing with the CodeDOM; it also allows you to compile  VB.NET and C# (probably F#, but since that isn't included in .NET 3.5, I don't support it yet), directly into assemblies. That is when I realized I could use that functionality, paired with my existing code that finds object implementations and derived classes for an Assembly[] array, to make it possible to "script" new derived classes and implementations of those interfaces and Derivation I search for. The result turned out to be quite simple, not more than a page of code, which I added to the class that performed the Assembly enumeration. It loads new assemblies by inspecting a Scripts folder in it's %appdata% folder, and attempting to compile those scripts into assemblies (.csx files using the C# code provider, .vb files using the VB code provider... I was going to use .vbx but that gave me flashbacks to Visual Basic 2.0 and vbx extension files. The code used to compile adds the basic references (System.Drawing, System.data.dll, etc) as well as itself, using Assembly.GetExecutingAssembly().Location- this includes the BASeBlock assembly, which is necessary since BASeBlock of course contains all the interfaces that need to be implemented, the necessary frameworks for any additional addins, etc. The script I used to test was a copy-paste of the AddBallBlock class, whose name I changed to AddBallBlockEx. Once the code compiles the new assembly and detects everything went well, that Assembly object is added to the list of Assemblies that the game will inspect for the appropriate derivations- of Block, iBallBehaviour,GamePowerUp etcetera. &nbsp; After some tweaks and debug sessions, everything seemed to work fine. So far the only issue has been that AddBallBlock's code called "AddScore" which is implemented by the Block base class, but for some reason trying to compile that resulted in the error that the symbol wasn't defined. Absolutely no idea what is going on there... Once I resolve that issue, I'll make the error-detection code a bit more robust and easier to get to  (for people trying to write their own scripts, or me in the future, it would be nice to have a place to find the errors issued by the compiler; perhaps it can save them in either the same scripts folder (as script.csx.errors or something) or a separate folder. As it is now, though, the test classes I created seem to be found perfectly fine; the blocks show up in the editor and the powerups can be spawned using cheats, so they seem to work well. the AddScore() issue will bother me though, but it seems to be related to the way the object heirarchy is laid out. The main "unique" feature of BASeBlock is that it uses pure GDI+; this was because OpenGL seemed like overkill, and I needed to learn GDI+ at the time anyway. People don't give it enough credit, honestly.

When I first started developing BASeBlock, the basic idea was just to get a feel for how Animation, rendering, and other concepts were dealt with in C#, as opposed to the aging language I was familiar with VB6. Additionally, I wanted to make use of Threading. After getting through the initial hurdles and issues related to the type of code I would need to write with BCDodger, I had a good idea the type of things I needed for BASeBlock.

BASeBlock’s actual Game information is, not surprisingly, kept inside a instance of a “BCBlockGameState” object. There are a few folly’s in my design, whereby some elements that would probably be best placed as members of BCBlockGameState are in fact members of the main form, but everything works well as it is, and if necessary objects can get a reference to the form itself using the BCBlockGameState ClientObject property, which is a interface that defines the type of stuff that is more implementation specific than ought to be in the State instance. Rendering is managed entirely within the Paint event of the main form’s PictureBox- (and likewise for the Editor). Rendering and the actual GameProc() routine (that makes things happen) are similar; they both iterate through the various objects in the game and call methods. The GameProc() routine animates balls, GameObjects, Particles, and AnimatedBlocks; the Paint event basically iterates through all those objects and get’s them to paint on a bitmap which is them blitted to the PictureBox when necessary. Of course having these two activities on separate threads meant  that I tripped on a few things while I was getting started- not locking this variable, trying to call methods of the form from within the game loop, and other similar contention issues. All of those have been resolved, to the best of my knowledge.

Another goal while working on BASeBlock was to make it easier for the creation of new blocks. The way the older Poing game (VB6) did it was to only have a single Block object, which had an Enumeration that determined what kind of block it really was. This had the issue whereby the Block had a lot of fields that were only applicable with certain block types, and weren’t applicable at all otherwise. This was a primarily a result of the fact that VB6 isn’t really an Object Oriented Language, but rather an Object-Based Language; while you can fake Implementation Inheritance using the Implements keyword and an aggregate class, it’s a lot of boilerplate that I couldn’t be bothered with for little gain. With C#, and more importantly proper OOP constructs, I could try my hand at a more reasonable Object heirarchy.

Collections

By far one of the most annoying things to deal with in VB6 is collections. they are finicky, and more importantly, the built-in Collection class only deals with Objects, so I would have to cast variables all over the place, and casting in VB6 means actually declaring another variable of that type and using Set to attempt the assignment to perform the “cast”. The only “workaround” is to create a entirely new class that uses a Collection internally but exposes the members of that Collection as the more specific type, as well as having Strongly-Typed parameters for Addition of blocks and removal. But the creation of these classes:

• Is a gigantic pain in the ass. They are almost all exactly the same, differing only in the Type used.
• Clouds the namespace. Poing has a Levels.cls class, a Blocks.cls class, a Balls.cls class, and a few others, all for the sole purpose of representing the exact same data structure for different objects.
• Is a gigantic pain in the ass. I already said that, but I just wanted to make sure I was clear about that.
• While you can use For…Each on the collection, it’s only through non-standard coding and setting method properties that it works, and even then you have very little control since the Interface being used for Enumeration, IEnumVariant is not easily implemented in VB6, and requires literally hacking away at your Process Memory to change in-memory VTables, which wreaks havoc on the brittle IDE.

Now, thanks to my Switch-over to C#, I can just declare those variables to be List<Block> or List<Level> or List<cBall> and forget about all this special Collection class nonsense. And Of course for specific Data Structures, I can use various other Generic classes such as Stack<>, LinkedList<>, etc. Generics is a powerful feature that becomes that much more valuable when you’ve had to hoof it yourself in less powerful languages to duplicate it’s functionality.

Dynamic Loading

But, this is supposed to be about dynamic loading- and more specifically, Reflection. Visual Basic 6 sorta-kinda had reflection, in the form of a MS-provided library, tlbinfo32.dll, which essentially allowed you to inspect COM components; since VB6 produced COM components, this worked there. But it was still rather cumbersome; you were no longer looking at VB-native classes or types, but you had to interpret the appropriate parameters from the idl code. additionally, COM was often just plain stubborn. I feel that in many ways .NET tries to resolve the issues of COM, particular with regards to pluggable components. .NET allows you to, directly in your code, load a new assembly, inspect the classes and types within that assembly- see what those classes implement or derive from, and so forth. Java provides equal functionality with it’s reflection libraries, too, and  that is how a lot of java applications implement plugins, including eclipse, one of the better java IDE applications.

With C# & .NET, you can load assemblies directly from the .dll or .exe file; then you have the Assembly object, and can inspect the types of t hat Object. BASeBlock, for example, loads all the assemblies (that don’t meet an “ignore” regular expression) from it’s executable’s folder- I’ll probably change this to a unique location, to prevent the game from enumerating the assemblies I included which will never contain what it is looking for). Once it has all the assemblies, it searches for various Types that implement some of it’s types. It always inspects “itself”, so it will find all the Block derivations, iBallBehaviour implementations, iPaddleBehaviour, etc. These get added to their own LoadedTypeManager instances within the MultiTypeManager that does all the work, and this allows the BASeBlock code to easily find all the implementations of it’s various interfaces, for purposes such as showing a pop-up menu and so forth.

Originally, I wanted to add a single implementation of the appropriate interfaces and base classes,  that delegated their actions/events/etc to some sort of script interpreter/compiler. After futzing about with IronPython, however, I decided  that the object model exposed there and what I needed required a lot of plumbing code to make managable. But then I had another thought.

The CodeDOM

.NET Exposes a namespace, System.Runtime.CompilerServices that contains more namespaces, classes, and interfaces that are used for dealing with the CodeDOM; it also allows you to compile  VB.NET and C# (probably F#, but since that isn’t included in .NET 3.5, I don’t support it yet), directly into assemblies. That is when I realized I could use that functionality, paired with my existing code that finds object implementations and derived classes for an Assembly[] array, to make it possible to “script” new derived classes and implementations of those interfaces and Derivation I search for. The result turned out to be quite simple, not more than a page of code, which I added to the class that performed the Assembly enumeration. It loads new assemblies by inspecting a Scripts folder in it’s %appdata% folder, and attempting to compile those scripts into assemblies (.csx files using the C# code provider, .vb files using the VB code provider… I was going to use .vbx but that gave me flashbacks to Visual Basic 2.0 and vbx extension files. The code used to compile adds the basic references (System.Drawing, System.data.dll, etc) as well as itself, using Assembly.GetExecutingAssembly().Location- this includes the BASeBlock assembly, which is necessary since BASeBlock of course contains all the interfaces that need to be implemented, the necessary frameworks for any additional addins, etc. The script I used to test was a copy-paste of the AddBallBlock class, whose name I changed to AddBallBlockEx. Once the code compiles the new assembly and detects everything went well, that Assembly object is added to the list of Assemblies that the game will inspect for the appropriate derivations- of Block, iBallBehaviour,GamePowerUp etcetera.

After some tweaks and debug sessions, everything seemed to work fine. So far the only issue has been that AddBallBlock’s code called “AddScore” which is implemented by the Block base class, but for some reason trying to compile that resulted in the error that the symbol wasn’t defined. Absolutely no idea what is going on there… Once I resolve that issue, I’ll make the error-detection code a bit more robust and easier to get to  (for people trying to write their own scripts, or me in the future, it would be nice to have a place to find the errors issued by the compiler; perhaps it can save them in either the same scripts folder (as script.csx.errors or something) or a separate folder. As it is now, though, the test classes I created seem to be found perfectly fine; the blocks show up in the editor and the powerups can be spawned using cheats, so they seem to work well. the AddScore() issue will bother me though, but it seems to be related to the way the object heirarchy is laid out.

The main “unique” feature of BASeBlock is that it uses pure GDI+; this was because OpenGL seemed like overkill, and I needed to learn GDI+ at the time anyway. People don’t give it enough credit, honestly.