WHS Dev Tip #14: ITabExtender, Part 2: Tab Refreshing
As easy as it is to create a tab for the Windows Home Server Console, something's are difficult. Needlessly so at times.
Should a programmer want to know when their tab is being displayed they might watch for their Controls ParentChanged or reflect against the larger console for other ways.
Shouldn't there be an easier way?
In many applications the F5 key can be used to refresh visible data. Same goes for some tabs in the Home Server Console and should a programmer use the KeyDown or KeyPress events to listen for it they will find themselves out in the cold because the Home Server Console handles the keystroke itself and doesn't pass it down the line.
Shouldn't there be an easier way?
Both of these issues are resolved with two methods provided by ITabExtender: Prepare() and Refresh()... a pair of options that should have been provided in IConsoleTab in the opinion of this humble blogger.
Some add-ins are expected to be able to refresh the displayed data from time to time and because the Home Server Console suppresses any F5 keystrokes making any hooks into KeyDown or KeyPress worthless, an alterative is to use an external mechanism for refreshing such as a timer or a manual refresh button... ITabExtender.Refresh() is our saving grace.
Beyond the requirement of implementing a stub at least for the method, how Refresh() goes about updating an add-ins control is completely up to the programmer.
Ideally used as a location to trigger a control wide refresh in a manor that the designer controls.
Along with Refresh() which is called just as our tab is being displayed and on the F5 keystroke we also get Prepare() which is executed far less... only when a tab is about to be displayed.
For some applications, having a Prepare() and Refresh() method may seem superfluous, after all, isn't Refresh() called shortly after Prepare()? (Yes)
Having the two separate methods gives us the opportunity to localize our logic a little better, as well as to implement only what we need.
While Refresh() gives us the opportunity to refresh our data on demand from the user, we may only want to allow refreshing (due to cost) once at tab selection time.
Perhaps we have two different levels of refreshing, a full refresh that we want to occur on tab selection and a mini-refresh whenever the user presses F5.
It's these kinds of questions that need to be taken into account when using ITabExtender and deciding how functional to make Refresh() and Prepare().
I do want to pause and say that I do kind of wish that there was an official third method... a Postpare() or Cleanup() that tells the programmer when a new tab has been selected, giving an opportunity to turn off any expensive live polling they may have enabled in Prepare().
While Prepare() and Refresh() are exposed as part of ISettingsExtender, only Prepare() is ever called, and that happens only when the form is loaded either through the Settings button being pressed or programmatically from an add-in calling IConsoleServices.OpenSettings().
As nice as it would be to allow for the same automatic refreshing of data in Settings as we now have access to in the main form, I suspect that this was a design decision based on the idea that the state of settings should only be changing based on explicit user input (ie clicking a button or typing in new values), removing the importance of this.
A sample add-in demonstrating everything discussed here will be part of the last post on Thursday.
ITabExtender provides an easy way to for an add-in to be notified when it is about to be displayed and later requested to be refreshed by the user through the Prepare() and Refresh() methods respectively.
Note: The information in this post is based on undocumented and at times deduced information on Windows Home Server and is not officially supported or endorsed by Microsoft and could very easily be wrong or subject to change in future, so please take it and everything else said on this blog with a grain of salt and use with caution.
Labels: WHS Dev Tips