Developer guidelines

Topics: Developer Forum
Aug 18, 2006 at 7:54 AM
Don't miss to read and comment on the developer guidelines
Aug 25, 2006 at 8:40 PM
And, like anything else I post, feel free to tell me I'm stupid, edit the guidelines, or anything else. :)
Aug 27, 2006 at 12:15 AM
I would expect our intention is to develop a reusable .NET class library then these guidelines would be applicable.
Aug 31, 2006 at 4:55 PM
One thing I'd like to make sure that gets done is excellent responsiveness of the applications. (One of my pet peeves).

When launching a process (like a browser), this operation could take several seconds to complete. If this is done in a Form event handler, the form will be unresponsive for that time (bad).

I've noticed a couple places in the test code where a URL is simply executed as a Process. This method works fine in the main thread; but fails if done from another thread (like via BackgroundWorker). This is because Process.Start requires the active thread to be STA, something you don't want on a background thread. Since we may be doing this frequently, here's the pattern I use for spawning a browser in the background:

private System.ComponentModel.BackgroundWorker spawnBrowserBackgroundWorker;
this.spawnBrowserBackgroundWorker = new System.ComponentModel.BackgroundWorker();
this.spawnBrowserBackgroundWorker.DoWork += new System.ComponentModel.DoWorkEventHandler(this.spawnBrowserBackgroundWorker_DoWork);

/// <summary>
/// BackgroundWorker.DoWork event handler.
/// Just spawn a process to handle the URL based on the system's file association.
/// </summary>
private void spawnBrowserBackgroundWorker_DoWork ( object sender, DoWorkEventArgs e )
String url = e.Argument as String;
if (url != null)
Process process = new Process();
process.StartInfo.FileName = "rundll32.exe";
process.StartInfo.Arguments = "url.dll,FileProtocolHandler " + url;
process.StartInfo.UseShellExecute = true;

// Asynchronously spawn a browser as this may take
// several seconds.
// Use BackgroundWorker to avoid queueing with the thread pool
// and avoid delay with Control.BeginInvoke.

See the MSNSearch Web Service MSDN Forums Prototype for example(s).
Sep 6, 2006 at 5:30 PM
What do you think about the Forum Explorer tool, just using the browser WinForms control? I know you didn't like the idea initially, but it looks like it could turn out to be an easy win. If we make sure that all of the functionality (like tagging, searching, etc.) is factored into their own libraries and projects, we could start by using the WinForm app and then allow people to spawn their own UIs as they see fit (toolbar, separate app, cmd line...) :)
Sep 9, 2006 at 2:35 AM
For this project I have been very bad at following the guidelines. Almost no comments.

I think we all agree to separate the functionality from the presentation and Mike have done the job to bring it together in a single project.

If we would have access to webservices for the forums we probably could improve responsiveness but what I missed with ReachOut was the view of the forums as they are seen from the browser.

This has nothing to do with developer guidelines but I would imagine one goal is to ensure the forum view is actually representing what other users see.