The Moth

Rico gives us Performance Tidbits.

The big news this week are the changes to the shipping/content plans for Longhorn. Chris Sells has all the links here.

UPDATED the status of the suggestions on ladybug

Previously in the overview of the Class Designer I focused on the good aspects.

I did not mention two tracking windows that I am not that excited about but you might be, so I'll briefly summarise them.

Each time a shape is selected/clicked in the diagram, there are two windows that get updated: Properties and Class Details (in my configuration on the bottom right and bottom respectively). Class Details is a breakdown of the elements in the shape for finer editing. However, I'd rather double click on the shape and go straight to code where the excellent code editor/intellisense will help me make my change, then Ctrl+TAB and I am back in the diagram. The Properties window shows info already on the diagram (e.g. method name, access modifier), it shows info that should be on the diagram (e.g. method signature, type, whether it is static) and it shows info that I wouldn't mind going to code to see (e.g. Custom Attributes, remarks, summary). I would probably be more enthusiastic about these windows if I didn't know that the development time taken to offer us these could have been used to plug more essential gaps that are there due to "resource constraints".

Talking of gaps in functionality here is a list of features that would greatly improve the tool. They are over at the MSDN Feedback center as suggestions where the problem and proposed solution for each are described.

1 (POSTPONED) Show Full method signature for methods, events, delegates, overloads
(a must have feature whose ommission makes the whole Class Designer almost useless IMHO)

2 (POSTPONED) Support a dependency association
(read my justification for this... it is one of the least appreciated yet most useful of UML IMO)

3 (POSTPONED) Static members should have visual indication on diagram

4 (POSTPONED) Visual distinction of readonly properties

5 (POSTPONED) Event as association and How to show subscription to an event

6 (FIXED) Delegate signature

7 (POSTPONED) Delegates (and other nested types) shown outside the class

8 (POSTPONED) Visual representation/distinction of Namespaces

9 (POSTPONED) Attach notes to classes and associations at least

10 (FIXED) "View in diagram" should not always create a new diagram

11 (POSTPONED) Navigation aid for large class diagram

12 (FIXED) "View in diagram" framework types from Object Browser

13 (POSTPONED) Option to use .NET framework types instead of language types

So VS2005 brings with it a great feature: the Class Designer.

For those of you unfamiliar with UML, think of it as a diagrammatic compliment to the Object Browser and Class View.

If you are familiar with UML (and its 8-9 diagram types), think Class Diagram but MSFT are going their own way with a slightly different notation.

Classes (reference types) and interfaces are represented by rounded-corner box shapes, and Structures/enumerations (value types) are represented by square boxes. Abstract classes are shown with a dotted line. Each box has up to four sections: Fields, Properties, Methods and Events. This is a great improvement over UML, where you just have 2 sections for attributes and operations; representing anything else requires stereotypes and/or other custom mechanisms. Each member can individually be hidden. Furthermore, each section is collapsible, as is the class as a whole; from a usability point of view this is done easier than in any other tool I have used!

The other item available from the toolbox is a square yellow note for adding comments in free format. While on the subject of color, it is used as a further aid in distinguishing elements on the diagram: classes/structs are blue, delegates red, interfaces green and enums are violet (unless I have become color-blind :-)

Interface implementation is shown via the lollipop shape, and it's good to see just one of these coming out of a class with a list of all the interface names below it: this reduces clatter. Should you wish to view the member of each interface separately, this is just a context menu away: "Show Interface". Inheritance is represented by the UML closed arrow head. The only other relationship supported is open arrow head association (i.e. when a type references another type) and there is an excellent feature where a field/property can be visualised as an association or vice versa: "Show as Association". Naturally, if one of your classes contains a field of a framework type, then showing as association will show a class of the framework type...this is great for reverse engineering the .NET library classes.

The Class Designer is always in synch with your code. In case that was not clear, any change in the class diagram (e.g. adding a method, changing a field) is reflected in code and any change in the code (e.g. deleting a property, changing a delegate) is reflected on the diagram; there is no code generation/reverse engineering step; they are just "naturally" in synch. In fact, if you look at the file (with extension "cd") you will find an XML document with layout and file information, but nothing that describes the members of the types as they are all read via reflection every time the class diagram is displayed. Navigation between the two is easy: going from a diagram element to its code counterpart is a double-click away and at any point in a code file, one can "View in Diagram" the types declared in the file.

Did I mention that Class Designer not only is available for all languages but also for CF projects as well :-D

Next time we'll look at what is still missing...

When it comes to threading we can think of locking in terms of a "linear acquire-do-release approach" or a "callback-based approach". I will not attempt to summarise any further this cool entry by Ian Griffiths.

If you find VB's language/syntax evolution weird/funny then laugh at this from the 3 Leaf guys.

Want to restrict a windows app to a single running instance? The traditional way is via a mutex and K. Scott Allen explains that very well here. As usual, its the gotchas that add the value...

Read the first two parts here and here.

.NET 2.0 fixes the problem with exceptions being swallowed on background threads (based on the VS2005 Beta 1).

When global exception handling is not present, unhandled exceptions on background threads will result in the app either exiting or JIT debug window appearing (based on the reg entry mentioned previously - on my VS2005 Beta 1 installation, the registry entry has the decimal value of 10 so there are clearly more options added in this area; but sorry, I just don't know more about them).

When global exception handling is present, the same rules as today apply, except we also get to see the JIT debugging window before our catch code runs(!). I guess this is for helping us on our dev machines, since by changing the reg entry to 1 the JIT debugging dialog does not appear (phew :-)

UPDATE: The CF 2.0 story is better with the November CTP compared to the Beta 1 story below.

With the CF 2.0, there is still no support for Application.ThreadException or AppDomain.UnhandledException, but the story gets better with try..catch around the main entry point. Basically the bug has been fixed, so the app will not freeze in the Control.Invoke scenario. To recap, if you try..catch the Appliccation.Run then you have two scenarios with CF 2.0:
1. Exceptions on the GUI thread are caught [just as in CF 1.0]
2. Exceptions in other threads (including the Control.Invoke scenario) are caught, BUT before your catch code runs the built-in dialog still appears!

This is the same behaviour with the full Framework (when we use global exception handling) with one major difference. On the desktop we can change the registry setting to override that behaviour - with the CF there is no way that I know of to suppress the built-in dialog :-( Let's hope this situation changes by release time...

Following from previous entry. If you are working with the Compact Framework 1.0, you should know that exceptions on background threads do result in the unhandled exception dialog appearing on screen. Also on the CF there are no registry entries to configure.

If you wish to add global exception handling to CF apps, you are out of luck. There is no support for Application.ThreadException or AppDomain.UnhandledException. You might think that using a try..catch around the entry point would work, however that is a bad idea. There are three scenarios when you do that:
1. Exceptions on the main GUI thread
2. Exceptions on background threads
3. Exception occurs in the GUI thread as a result of a Control.Invoke from a background thread (which you must do to update GUI areas)

The first scenario is OK - the exceptions are caught and your catch code will run. Your catch code will not run for the second case; in fact the built-in dialog will appear.

The third case is the worst, and I classify this as a bug: in this scenario your app will freeze/lock (and of course your catch code after Application.Run will not run).

So, no centralised global error handling on the CF.

Next time we'll look at how things change with VS2005 and .NET v2.0

We should be trapping possible exceptions in various places with the try..catch mechanism, but all software contains bugs and so will your code; in that scenario you still want to catch the exception (log it, present custom GUI to user, etc). To do this on the full Framework 1.1 we use a try..catch around the entry point (typically Application.Run), hook into System.Windows.Forms.Application.ThreadException (for GUI thread exceptions) and hook into AppDomain.CurrentDomain.UnhandledException for other thread exceptions. We need to perform all 3 actions.

There is a good article on the subject in June's edition of MSDN Magazine on the above, go read it.

To finish the desktop story, check out the registry entry described here. Note that, if there is no global error handler mechanism, any exceptions on background threads are swallowed if not explicitly caught. This means the application does not exit or put up a JIT debugging window, it just continues running in whatever state it is in!

Next time we'll look at how things are different with the Compact Framework.

David Cline continues his series on using cordbg on the CF with part VII (check out parts I, II, III, IV, V and VI).

Also, Brian Grunkemeyer on the BCL blog talks about Managed Debugging Assistants (MDA's) in Whidbey, in the context of finalizers.

Finally this week, Wes discusses differences in memory/speed between the Hashtable implementation of Whidbey and the current one.

I work for a Building Management Systems (BMS) manufacturing company. Our main products are intelligent building controls. In January we replaced our old network display panel with a new hardware platform running Windows CE 4.2. The product's name is IQView.

Our hardware is based on an XScale PXA255 processor 200 MHz with 32 MB RAM. There is no stylus/keyboard/mouse, so user interaction is via 1/4VGA color touchscreen using a finger :-) Connectivity includes rs232, Ethernet and our own proprietary current loop. The unit is always connected to one of the previous options. It can be panel mounted or fixed to the wall (either way this is not a mobile device). In summary, it also has an SD card slot, LED, buzzer and relay output.

IQView allows for discovery of controllers, navigation of modules within them and adjustment of parameters, graphing, alarm reception etc. The application itself is written by myself using .NET CF. This is effectively (not literally) the only process running on the system and the only GUI that the end user interacts with - there are no OS components (control panel applets, taskbar, menus etc) ever visible. It runs 24x7 (assuming none of my bugs creep up :-).

If you want to know more about our choice of CE over other operating systems, our choice of the CF over eVC or want to see an image of the product, then you may find this article [pdf , html] useful. It appeared in EmbeddedSystemsEurope in April and includes quotes from our technology and business managers - us devs never get air time like that :-[

Other references to IQView on the web are
here (Swedish)
here (Finnish)
here (French)
here (German)
here, here, here (English)

This week Casey started blogging about new namespaces in CF 2.0, unique types on CF compared to desktop and breaking changes in CF 2.0 compared with 1.0. But then he summed it all up and much more in this article; go read it!

Also this week, Stan Lippman gives us his insights into the problem of a language retaining its character while having to fit in with the .NET Framework where "individual languages are diminished". Go read it especially if you are interested in templates vs generics in C++.

By creating on the device a registry key and editing a value under it one can have a file automatically created containing statistics for a .NET CF 1.0 application. For more info on this go here (the counters are also described here amongst other performance advise).

In CF 2.0 (that comes with VS2005 Beta 1) there are more statistics added. For a list of the 30 previous counters, which are still with us, I refer you to the two links already provided. Here is the list of the 23 new counters only (can broadly be grouped as Threading, GC, COM):

UPDATE: The list below has changed. See here

Number of Uncontested Monitor.Enter Calls
Number of Contested Monitor.Enter Calls
Number of recursive Monitor.Enter Calls
Number of threads in thread pool
Number of pending timers
Timer latency

Number of objects in block move
GC Number Of Mark Stack Overflows
GC Number Of PInvoke Args Encountered
GC Number Of Eval Stack Pointer Lookups
GC Number Of Object Pools Created
GC Number Of Pinned Objects
GC Number Of ByRef Types Encountered
GC Number Of Pinned ObjRefs
GC Number Of Items Pinned At JIT's Request
GC Number Of Normal ObjRefs
GC Number Of Objects Moved by Compactor
GC Number Of Objects Not Moved by Compactor

Number of Runtime Callable Wrappers
Total number of Runtime Callable Wrappers
Number of generated Com wrapper classes used by the system
Number of Com Methods
Number of Com Calls

There are many who believe that the ThreadPriority property is not available on the .NET CF (some articles, books and MS documentation got this wrong in the past). The fact is that the property is available (5 priorities like the desktop version - these map to 249-253 in Windows CE terms). However I believe it is a bad idea to change the priority of managed threads.

For every CF application there are 3+1 threads [Quote from MSFT reply to my question in the ng] :
#1 The main application thread.
#2 is used to control various period timers and timeouts that can be scheduled by the system or applications.
#3 is used to track changes to the active TCP/IP interfaces (simulating the media sense behavior that is present on Windows XP but not Windows CE).
#4 [...] the thread that is used to run object Finalizers. It is created when the first finalizable object is garbage collected.

[Note that the 2nd thread is created only when needed in the CF 2.0 Beta 1]

Apart from the first one you cannot change the priority of the threads above (they are all at 251). So if you change the priority of other threads in your app how will they play nicely with the above four?

When a NETCF garbage collection occurs there isn't a special thread that performs the collection rather it is whatever thread happens to be running when the need for a collection occurs (do not confuse the GC thread with the finalizer thread). What will the results be if that happened to be one of your own threads whose priority you lowered?

Finally, note that the ThreadPool in the CF 1.0 does not have a limit of 25 threads like the desktop framework does; instead it is 256. [CF 2.0's ThreadPool is broken in the Beta so cannot comment on that but is fixed for the next CTP. Apparently CF 2.0 will bring parity with the desktop with a limit of 25. Let's hope that will be configurable]

So if you are going to be creating threads and changing their priority you must first be sure you understand the above and cater for them in your design. I have personally elected to keep all threads at their default normal priority in my CF apps and have only had unexpected results when I experimentally deviated from that policy.