Register Now | Sign In
FeedGhost Logo

RSS feed Stu Smith: Making It Up As I Go Along

My life working for BinaryComponents, coding, design, and other stuff.

Memory Debugging in WinForms


Posted on 24 Oct 2006 11:10

I've been doing some memory profiling in FeedGhost today, tracking down any little memory leaks. FeedGhost is now memory-stable under common repeated actions. I've been using SciTech Memory Profiler, an essential tool if you want to produce professional .NET applications. A few observations…

1. The WinForms designer makes it very easy to connect up events, but where do you detach them? Dispose() is 'taken' by the designer file, and while I could move that into the main code file, I prefer not to have to mess with auto-generated code. One solution is to forget the designer for events, and instead manually attach in OnHandleCreated() and detach in OnHandleDestroyed().

2. C#'s inline delegate syntax can simplify code, but if you do:

_button.Click += delegate { // Do something };

How do you detach the event? Stick with methods and the standard attach/detach syntax.

3. Not all events need to be manually detached of course, usually if both the sender and the receiver have no roots, they will be collected. This isn't always the case though: Timers, for example, keep themselves alive, presumably because they have their own backing window. You need to detach and dispose these.

4. I'm fully aware that nulling out references makes little or no difference to the garbage collector… but it sure makes memory leak debugging easier. For each object that you were expecting to be collectable, there will be a number of root paths to it -- the fewer of these, the easier it will be to find the one or few paths that are actually holding it alive.

Designing the (Nearly) Perfect Toolbar


Posted on 19 Oct 2006 16:20

One of the things our beta testers are likely to have noticed changing frequently is the toolbar. We've made numerous changes based on user feedback. We've had to balance many conflicting requirements:

  • Must be usable on a daily basis -- users shouldn't have to keep switching between mouse and keyboard, and should be able to use either speedily.
  • Must be learnable and approachable by new users -- they should be able to get up-to-speed rapidly.
  • Must support different methods of usage.
  • Must work on different screen resolutions.
  • Must look good.

One of the first major changes was to remove all the commands for individual articles and subscriptions. With one exception (delete article), these buttons were almost never clicked, and just forced all the other toolbar buttons to be smaller.

After several pub usability sessions we've found there are several different usage patterns for daily usage in FeedGhost... in no particular order...

  • River view, simply hitting F8 to read more articles, scrolling within the article browser.
  • Keyboard, managing articles with arrow keys and delete key.
  • Mouse, reading articles by deleting as read.
  • New user, using a combination of methods based on what is immediately apparent.

Up until now, improving one method has been to the detriment of the others. Finally though, I think we've cracked it: 'Read More' and 'Delete' are the primary reading methods, prominently displayed on the left of the toolbar. Keyboard 'alt' shortcuts are provided to scroll the article browser even if the focus is on the tree or list, and the mousewheel affects the control it is positioned over.

And so, I present the first toolbar that receives pretty much universal acceptance, in a few screen resolutions:

 

I've included the last screen-shot as a little reminder that FeedGhost can be used as a simple article reader with no other distracting controls, simply by collapsing the tree and list, and resizing until the toolbar disappears. 

(We're still not quite happy with the word 'Problems'... so there will likely be some more changes).

Feed Location


Posted on 09 Oct 2006 14:47

One of the features I wanted in FeedGhost from the beginning, and which I think we've achieved with a high degree of success, is auto-feed-location. Basically, when browsing a webpage, FeedGhost scans the page in the background to find related feeds. Our feed locator, aparently in contrast to Internet Explorer 7 and Firefox, is a proper solution, not just a heuristic-based one.

In fact, our feed locator uses the same routines as when you add a feed using the wizard, drag a URI into FeedGhost, or right-click on a browser page. If a feed can be found with one method, it can be found with any. We do prioritize scanning for links that seem most likely to be feeds, but eventually all links on a page will be scanned.

I found this blog entry discussing various "tricky" feed formats. As you can see, FeedGhost successfully locates the feed associated with this entry, plus four others referenced on the page.

(Sharp-eyed readers might notice that FeedGhost has discovered four extra feeds, while the webpage lists five. Unfortunately, at the time of writing this blog, one of the websites was down).

The upshot of all this? Drag web-page addresses into the subscriptions tree. Use the locator button on browser tabs. Right-click Internet Explorer. Forget copy-pasting URIs and let FeedGhost do the hard work for you.

The One And Only FeedGhost Setup


Posted on 06 Oct 2006 18:22

Looks like Lee is a little stuck in the past when it comes to reading subscriptions; everyone knows that the One True Reading Style is as follows:

The tree is open to reduce the reading width a tad, and to provide a little context. The news list is pointless so we hide it. Focus is kept on the article browser, arrow keys and page up / page down scroll through the articles on display, and F8 moves to each new set of articles.

Simplicity itself.