Visa run by bicycle

A fact of life for many foreigners staying long term in Thailand, and in other countries probably, is the visa run. My visa is valid for one year, but I'm only allow to stay continuously for a maximum of ninety days. Before exceeding that limit I must leave Thailand, even if for just five minutes before returning again.

So today it was visa run time again! Well, my ninety days wasn't up until Monday, but I decide to get it over with a few days early. I arrived yesterday in this town on the Burmese border, called Mae Sot. I came from Lampang where I was visiting some American friends. I didn't depart there until 1pm, however, so I arrived in Mae Sot at 5pm. I headed straight to the border. When I got there at 5:11pm I found out the Burmese side closes at 5pm. Oops.

I headed into town where I eventually found the decent and affordable Green Guest House. It's located on a side-street behind the police station, just past the holding facility (just a big cage really) for illegal Burmese immigrants. After checking in, I went to eat dinner at the restaurant Krua Canadian (Canadian Kitchen) which (surprise!) is owned and operated by a Canadian guy with a Thai wife. It was good tasting Mexican food, better than what I had in Chiang Mai. I assume the Canadian owner spent some time living in Mexico before coming to Thailand.

This morning I rented one of the guest house's bicycles, then rode the five kilometers or so to the border. I took a bunch of photos, with the idea in mind to write this blog entry tonight. So here the photos are below.

The day's mode of transporation, in front of the guest house

The road ahead

The road ahead becomes a four-lane highway

Border checkpoint in sight

For some, this is the way home

Crossing the bridge into Burma

Some Burmese don't need a bridge, or travel documents, to get into Thailand

The Burmese end of the bridge is in sight

I spent a couple minutes walking down the street

Then into some market... (then I headed back to Thailand)

Item Presentation Models for WPF

After two weeks of work (and some play), I've finally posted my Item Presentation Models for WPF article to Code Project. This is my first Code Project article ever, so I'm excited about it. I hope readers find it useful and I look forward to their feedback.

Naming domain-specific ItemPresentationModel objects

I've decided to follow a rather unconventional naming pattern for domain-specific presentation-model classes — suffix them with "View". I am aware that this naming breaks away from the conventional terminology of MVC and its derivatives, in which "View" refers to the UI layer. So I devote this blog entry to digressing my reasons.

Outside the scope of MVC-related design patterns, the word "view" has a more general meaning that's applied in varying contexts. SQL, for example, uses it to mean a derived view of base data. Closer to the present topic, WPF includes the CollectionView class which is a sort of presentation-model. People who prefer that "view" strictly refer to the UI probably hate this choice of class name. However, appending "ViewModel" or the even longer "PresentationModel" to all my class names is verbose in my opinion.

For the above reasons I instead use the suffix "View" as an acceptably short alternative for my domain-specific Presentation Model classes. By doing so, I intend to invoke the word's general meaning of the sense that the presentation-model provides a derived view of the domain object. Another interpretation is that the presentation-model provides an interface for the domain object that makes it fit for presentation; the presentation-model is therefore an abstract view (presentation) object. This latter interpretation is useful since it emphasises the presentation-model's actual purpose, which is that it facilitates visual display (in that sense, Josh Smith's original "Presenter" suffix doesn't sound half bad).

I am aware that this naming breaks away from every quasi-standard in the literature of MVC and its derivatives. Even the WPF library doesn't use it consistently. That is, they use the word "View" in its more traditional MVC sense as well, as in ListView and TreeView. If instead WPF named those controls "ListControl" and "TreeControl" — which would be consistent with many other controls in their library such as ContentControl, ItemsControl, UserControl, and TabControl — then I would find their choice of "CollectionView" more acceptable. In any case, I still find their suffix "View" to be so much more aesthetically pleasing than the alternatives, so that's what I choose to use in my own projects. Such a choice, however, has implications only within the scope of individual projects or organisations. Therefore, others can use whatever naming convention they find to be the easiest to live with.

Revisiting bidirectional association helpers

The one-to-many and many-to-many helper classes in my ObservableCollections project make it easy to maintain in-memory the semantics of bidirectional associations, by keeping an association's references in sync in both directions. The way these helper classes are now, they work only in situations where the many-side is constrained as unique and is non-indexed, i.e. the corresponding collection is an ISet. However, I've encountered a situation in my main project where an association's many-side is indexed, i.e. the corresponding collection is an IList. So I'm revisiting the ObservableCollections project in order to accommodate this need.

Looking back at the bidirectional association helper classes after so much time, I realised how confusing the class and method names have been. So the first step was to rename them. For starters, I renamed the SetContainerToEntityAssocSync class to OneToManyAssocSync to reflect the more general (albeit incomplete Although I will add support to the newly named OneToManyAssocSync class for indexed collections, this more general name isn't completely applicable since I won't be adding support for non-unique collections as well.) desired applicability. And I renamed the SetContainerToSetContainerAssocSync class to ManyToManyAssocSync. After that, in the OneToManyAssocSync class, I changed other occurrences of "setContainer" to say "one" or "oneSide" since it has a multiplicity of one in the relationship. And I changed "entity" to say "many" or "manySide" since it has a multiplicity of n in the relationship. Finally, I renamed some miscellaneous variable names so that they, to, will be consistent with this new terminology.

The next step was to modify the OneToManyAssocSync class's UpdateOneSide method, along with the ManyToManyAssocSync class's UpdateOtherSide method, as follows. The other side's collection must be cast not to ISet, but to the ancestor type ICollection which is common to both ISet and IList. I actually ended up using the generic ICollection<T> since the nongeneric version strangely lacks methods for adding, removing, and checking for containment of items. The code now works in cases the collection type is an IList; however, it only works when the uniqueness constraint is being applied to the IList, which is fine in the case of my main project. It will not, however, work for bags or lists with multiple occurrences of the same item. I included checks for this boundary condition.

Closable TabItem in WPF

Having finally reached the user-interface implementation step in my current programming project, I must first lay the foundation for the program's tabbed document interface (TDI). It's a TDI of the style seen in Firefox and Internet Explorer, where each tab includes it's own close button. Additionally, in my program the set of tabs is fixed and the user can reopen a tab (via a menu) after it's been closed, which makes it appear at its original position. WPF's standard TabItem control doesn't have a close button, so in order to include such a tab in your own program you must find or create a custom control that does the job. You can download the result of my effort—a Visual Studio 2005 solution—here (updated 2008-Feb-11).

The included ClosableTabItem derives from TabItem and provides the functionality you need to easily add close buttons to your program's tabs. The sample application additionally includes for each tab a corresponding item on the 'Tabs' menu, with a check mark indicating the tab's current visibility. After a tab has been closed, a check mark no longer appears on it's menu item. This provides a means for the user to reopen a previously closed tab by selecting a menu item with no check mark. If the user selects a menu item that's currently checked, the item gets unchecked and the tab is closed. But I am not sure this latter behaviour is the most natural/useful. Perhaps it would be better if, rather than closing the tab, it gets selected and it's contents are brought to the front. In that case, I would rename the menu from 'Tabs' to 'Switch Tabs' similar to the 'Switch Windows' menu in Microsoft Word 2007. I am not sure which behaviour would make for a better user experience, so please send me your feedback.

Soon after I started creating the custom control, I came across a blog post which looked like it already did the work for me. Upon looking at the solution's source code, however, I became disappointed with it's architecture. Rather than reusing the Style and Template of it's parent TabItem type by deriving from it, it completely replaces them. This flows contrary to the object-oriented principles of code reuse which I have internalised. So I decided to continue creating my own custom control. At first I thought that after adding the BasedOn attribute onto my custom control's Style element, I'd just need to write a few lines of code then be done with it. But it actually took more work than that, involving WPF features such as data templating, property bindings, and routed commands. The resulting custom style code is a lot shorter than the competition's, though—less than 90 lines as opposed to about 170—so I consider it an improvement.