You may have noticed that version 4.0 of Movable Type has been officially ‘open sourced’ (at Digg). I prefer the rather more correct ‘Movable Type has been relicensed under a less restrictive (or more restrictiver, whichever you fancy) license’. After all, the MT package has always included the code.
Does MT still matter these days? They do but not as much after that famous ‘relicensing’ hot-discussed event in 2004. A lot of people have moved to WordPress since that: however, I thought the generation of static pages was one of the plus-sides.
To .Net then: if you use the ToolTip class and create instances dynamically you may have noticed that the class showcases a design paradox: if you don’t dispose these instances after you’ve finished using them, you’ll end up with (what Microsoft calls) a ‘managed resource leak’ (obviously, there is a limitation of GDI objects a program can create. My favourite part is ‘There is a theoretical limit of 65,536 GDI handles per session’). However, a timed ToolTip (the type that disappears ‘magically’) obviously has ‘visibility’ issues when being disposed too soon (it will never pop-up). So, the questions is: When do these tooltips need to be disposed then? It looks like that’s a paradox unless you drop them in your project at design-time.
What you need to know before you plan to work on Serial port communication:
0. Create a good test environment. You may need com0com (earlier) which can simulate a loopback between 2 ports.
1. Carefully choose between non-blocking and blocking. You save yourself a lot of pain when you thought using non-blocking was going to make work a lot easier. If you’re not familiar with the blocking vs. non-blocking approach, consider the table below the fold. (More on blocking vs. non-blocking). Holy wars have been fought between proponents of either form.
2. While doing your serial port stuff, also note that ReadLine has a BLOCKING nature. This is not mentioned in the original FrameWork SDK help files, but yes, it is mentioned in the SDK online. There’s no problem using ReadLine in your OnDataReceived event, but you must clear the port’s/socket buffer first before you can close your port/application (you’ll get specific errors).
3. There is no 4.
I added a minor project to the ‘Current Project’ section (Right here), a program in C# that generates classes based on table meta-data. It’s simple and it works: there are a couple of tricks how to collect metadata from ODBC datasources.
Currently, I used ‘hardcoded’ datatype conversion (SQL_xxx -> Dot.Net type): I was in a rush and decided to (conveniently) forget about using reflection. That said, I keep forgetting about my linefeeds [sorry], but then, your Visual Studio formats everything nicely out anyway.
This reminds me that I’ve downloaded ‘Orcas’ yesterday, Microsoft’s CTP of the new Visual Studio IDE. It comes with a visual ‘class designer’ that allows you to create classes from tables like the generator above does, but obviously (at this stage) that feature only supports the typical MS-like database interfaces. Not much of a help if you work in other environments. The only interesting items are the new C#/.Net language extensions, like LINQ and XAML. And yes, the Dev Team finally decided to add a Compile to Target feature, which allows you to compile and link your executables with other .Net Frameworks.
I had that question appear in my logs a couple of times, and I assume, these are (beginning) .Net developers who want to have examples of accessing database servers via ODBC in C#. If you thought this was going to be ‘plain and simple, drag and drop in Visual Studio’ (or SharpDevelop), you are partly wrong. As in everything in programming, you end up doing a lot of coding yourself because of certain limitations.
First of all, Visual Studio 2005 (SharpDevelop might) by default does not have the (visual) ODBC controls installed in the ‘Toolbox’. You need to add them yourself (there should be 4 of them). After doing that, you’ll find out that using these ‘visual’ controls is not as ‘visual as that fancy commercial promised’. Worse, you read in the Framework documentation that:
While the OdbcDataReader is being used, the associated OdbcConnection is busy serving the OdbcDataReader, and no other operations can be performed on the OdbcConnection other than closing it
Due to the limitations of native ODBC drivers, only one DataTable is ever returned when you call FillSchema. This is true even when executing SQL batch statements from which multiple DataTable objects would be expected.
There’s generally two ways to get and retrieve data using the .Net 2.0 Framework: the first one is to use the earlier mentioned DataReader, the second one is the ‘in-memory cache’ DataSet/DataTable. Most of time, you’ll end up using a combination of both: when there’s lots of data involved you may want to skip the DataSet and go for the DataReader (wrap it in an object for example). If you want to keep data in memory and want to keep connections open (persistent), you may want to keep close attention to the first quote I mentioned above.
But the good stuff is right here (warning: untested code ahead! All disclaimers apply). If you’re not into programming, you may want to skip this: