Archive for July, 2010

SmallChange and LargeChange properties of scrollbars

These properties apply to scrollbar controls in WinForms, but the concepts are pretty universal:

  • SmallChange is the change in value that occurs when you click on a scrollbar’s arrows
  • LargeChange is the change in value that occurs when you click on a scrollbar’s track
  • I had some vague ideas on how to set these values, but this MSDN entry confirmed by suspicions that the values should be set relative to size of the container and not the size of the content.

    User interface guidelines suggest that the SmallChange and LargeChange properties are set relative to the size of the view that the user sees, not to the total size including the unseen part. For example, if you have a picture box with scroll bars displaying a large image, the SmallChange and LargeChange properties should be set relative to the size of the picture box, not to the size of the image.

I write like…

Playing around a bit with I write like. Based on sampling from a few blog posts, the most common writer that came up was Cory Doctorow

Cory Doctorow

To a lesser extent, I also got David Foster Wallace

David Foster Wallace

Sweet.

A cappella metal

Lurking on reddit, I discovered van Canto, an a cappella metal group – yes, a cappella metal – consisting of 5 singers and a drummer. Hearing their cover of Master of Puppets was just one of those amazing what-the-fuck moments…

Mono WinForms layout and invalidate issues

Issue 1: Layout of anchored, non-visible control

I had a custom subcontrol anchored left and right within a parent control. The subcontrol was not visible and would only appear when I called a function to make it visible. The parent control had a default width and height, of course, but would be resized as necessary when placed on a form. With Mono, after being placed on a form, the anchoring seems to take effect based on the default dimensions of the control, not the dimensions of it in the form. This, of course, results in the subcontrol being an incorrect size and position.

I haven’t found a solution to this issue as yet.

Issue 2: Repaint after SuspendLayout/ResumeLayout

When adding a number of custom subcontrols (Dock=Top) to a Panel, I called SuspendLayout() before adding them, and called ResumeLayout() after. The height of the controls are adjusted right after they are added to automatically fit a word-wrapped block of text. On Mono, the Panel is never repainted (meaning the custom controls are never repainted either, and its text is not shown).

Calling Refresh() or Invalidate() after ResumeLayout() solves this issue.

Ekkio feed 2.0

A new feed for the Ekkio desktop client. This replaces the flat buttons with hyperlinks, for a more concise and elegant look.

The real challenge here was creating a WinForms controls where text and links could be rendered side-by-side. The standard Label and LinkLabel controls don’t allow for this.

ekkio feed v2

I’ll do writeup and post some code soon on how to make a control like this.

The end of :hover

Interesting post on the realization that :hover (in CSS, this defines what occurs when the mouse is over an HTML element) is no longer viable for layout on touchscreen devices.

When I sat down to a redesign of the Gameplan2 admin interface I suddenly came to a realisation, :hover doesn’t work. It’s entirely possible I’d skim read this somewhere, but somehow the implications for my design work had passed me by until I saw an iPad in use.

I came to the same realization when designing the Ekkio web client, and realizing I couldn’t open the file and folder submenus on my Palm Pixi.

Ekkio web client submenu

The arrows on the left would only appear when the user hovered over a file or folder. The solution, as shown, was to always show the arrows, but make then a lighter shade; on hover or when the dropdown is open, the arrows become a darker shade. This works well, despite the visual clutter of the arrows always being visible.

I agree with Croll’s conclusion,

So my proposition is this: :hover as an web interface design tool going forward is going to be less and less important.

I see :hover (and javascript mouse events such as onmouseover, for that matter) being unused or used only for non-essential stuff, such as added visual flair.

On a related note, touchscreen also don’t allow viewing the alt-text when hovering over an image. This is probably not a big deal when it comes to web layout, but it sucks for reading xkcd.

Safari 5 form submission bug

This applies specifically to Safari 5 (no problems in Safari 4) and forms with an enctype of multipart/form-data, submitted with a POST request built manually (for an AJAX [XMLHttpRequest] call).

Safari 5 injects a “charset=UTF-8” name/value pair into the ContentType field after the boundary string. This generates an invalid request. On the server-side of things, this resulted in no data in PHP’s $_POST global variable.

I tracked down the issues thanks to this post. The bug itself is a WebKit bug, described here.

The simple fix is to prevent Safari from automatically putting the charset parameter in by putting it in manually – before the boundary string. Here’s some jQuery code that demonstrates the issue/fix:

function ajaxSubmitForm(servlet, theForm, extraFunc)
{
var boundaryString = 'AaB03x';
var boundary = '--' + boundaryString;

var requestBody = new Array();

requestBody.push(boundary);

for (var i=0; i<theForm.length; i++)
{
requestBody.push('Content-Disposition: form-data; name="' + theForm.elements[i].name + '"');
requestBody.push('');
requestBody.push(theForm.elements[i].value);
requestBody.push(boundary);
}

var reqBodyText = requestBody.join('\r\n');

$.ajax({
url: servlet,
type: 'POST',
contentType: 'multipart/form-data; charset=UTF-8; boundary=' + boundaryString + '',
data: reqBodyText,
error: function(reqobj, errType, exceptionObj){
alert('Failed to submit form data.\r\nStatus = ' + reqobj.statusText);
},

success: function(xml)
{
if(extraFunc != null)
extraFunc();
}

});
}

The Grind

“… things were going to get a little challenging…”

Outlook interop exception when updating appointments

An odd issue I encountered doing Outlook interop with the Outlook Primary Interop Assembly; an exception with the message “You don’t have the permission to move this item” is raised when attempting to update an appointment. Thanks to this post I discovered the issue is caused by attempting to set the start and end times of an appointment with a recurrence pattern.

You cannot set the Outlook._AppointmentItem.Start and Outlook._AppointmentItem.End properties. You only set the Outlook.RecurrencePattern.StartTime and Outlook.RecurrencePattern.EndTime properties to indicate the start and end times of the event.