suggestions

Sep 10, 2008 at 11:37 PM
1 - I remember reading somewhere that you had doubts about this working for multiple today items.  I concur.  To fix this, I suggest that you check for a running instance of the host exe before starting one.  If one already exists, then there would already be a managed today item initialized.  This brings me to suggestion number 2.
2 - Instead of using the registry to store 'instance HWND', just use named pipes (or your favorite IPC) to send over instance information.  This way when the host exe already exists and a new today item is to be created, its instance HWND can be sent to the existing host (and of course, the original HWND would be sent that way when the host exe is first created).

Sep 10, 2008 at 11:47 PM
Also, I think you could do away with your custom TodayScreenItemAttribute completely and just check for type.BaseType == TodayScreenItem during the reflection instead.
Sep 10, 2008 at 11:48 PM
Oops, nevermind the last suggestion about the custom attribute.  I was confusing your early proof-of-concept with the latest alpha 2.
Sep 10, 2008 at 11:50 PM
Though it does look like you could do away with it and check for type.BaseType == UserControl instead (but I suppose there's a chance for false positives if you do not control all the assemblies in the search dir).
Sep 10, 2008 at 11:56 PM
Edited Sep 10, 2008 at 11:57 PM
Oops, nevermind the first suggestion either.  I see now that you are using one window and putting multiple controls (one for each hosted today item) in it.  However, I would still suggest you get rid of the registry requirement and instead pass the instance HWND over as a cmd line param to the exe or as previously mentioned via IPC.
Sep 11, 2008 at 12:03 AM
The downside to hosting all the ctrls in one native window is course-grained handling of WM_TODAYCUSTOM_QUERYREFRESHCACHE.  I would prefer that only one ctrl at a time be re-painted based on its internals only (and this should be based on more than just window height--there should be some IPC between the host and the hosted about the correct answer to that query [i.e., when the hosted needs to be re-painted for whatever reason at all, it sends message to the host who then passes onto the system the next time the QUERYREFRESHCACHE message comes in]).
Sep 11, 2008 at 12:23 AM
I guess it goes without saying but my last comment would require a native window per managed today item.  [This suggestion would also be more accurate and if the system ever decides to do anything more elaborate than WM_TODAYCUSTOM_QUERYREFRESHCACHE, you'd already be ready for it.
Sep 11, 2008 at 12:25 AM
And, you wouldn't have to code your own item separator as currently (the system would do it automatically as each today item would really be a full-blown today item).
Sep 11, 2008 at 1:15 AM
P.S.  I am making the suggested changes in the source code and will post it here when complete (if you're interested).
Sep 11, 2008 at 5:17 PM
This may also be of interested if you wish to take my suggestions (specifically the MessageQueue class for IPC):
http://blogs.msdn.com/windowsmobile/archive/2005/09/06/461805.aspx