If you're a regular reader of my blog, you're probably a spam bot. :P In any case, you might've noticed that certain parts of the site have been neglected a bit. I haven't posted on the blog much, and the EGS statistics are horribly out of date.
The reason for this is that I've been busy on my master's thesis. Today, I did a presentation about my work, which went pretty well I think (I don't have the results yet so I can't know for sure). I've been sick for the past week and still hadn't recovered completely, but it still went well regardless.
Now the presentation's done and my thesis pretty much complete, which means that finally, after more than six years, the end is in sight. If all goes well (and I don't see why it wouldn't at this point) I will receive my master's degree on November 24th, a day before my birthday. In a way it's almost scary; I've been a student for six years, then suddenly I won't be anymore. There's also some practical concerns. Students can get a creditcard regardless, but once I stop being a student I'll need an income to keep it. Since I'm still waiting for the final word on my scholarship for Japan, I'm not sure how that's going to work. I'll also lose my 100Mbps Internet connection, which is for students only. But, c'est la vie.
I've been writing my thesis in Office 2007, and I must say, I'm really impressed. MS managed to make Office more powerful, yet far easier to use. Of course there's still some bugs (it's only Beta 2 TR after all), but I have very high expectations of the release version.
Today's presentation in particular I gave using my laptop, running Windows Vista RC2 (build 5744) and PowerPoint 2007. I was pleased to see that my favourite (but very underused) PowerPoint feature, presenter view, hasn't been neglected in the new version. With presenter view, you get the regular presentation on the VGA out (attached to a beamer usually) and a special view on the LCD screen that shows the current slide, a thumbnail list of slides, the duration of the presentation, and (most importantly) the notes you added to the current slide. Far more useful than just mirroring the LCD and VGA displays, since it allows me to get a better idea of where I'm at, and I can keep notes without having to use cards or put too much information on the slide itself.
In PowerPoint 2007, presenter view has been reorganised a little. In previous versions, the slide thumbnails were on the left, and the notes on the bottom. Now, the slide thumbnails are on the bottom, and the notes on the right. This means there's more room for the notes. Besides showing the presentation duration, it also shows the current time, which is also new.
Considering I'm studying computer science, I'm surprised there's not more students who know about this very useful feature.
And by the way, if you're curious about what my thesis is about exactly, I'll have to keep you in suspense for a bit longer; it's simply too complicated for me to effectively explain in a blog post. But rest assured that once my thesis is officially finished, I'll put it up here so you can read it for yourself.
So IE7 was released yesterday. Since everybody and their dog were blogging about that, I decided not to waste a post on it, despite the fact that it would've been an excellent opportunity to remind everybody of my Find As You Type add-on.
But IE7's release did mean I finally had to bite the bullet and look for a workaround to one of IE7's bugs. This particular bug means that if you have any right-floated italic text on your page, doesn't matter where, the page gets a rediculously huge horizontal scrollbar. You can see this bug in action here (includes screenshot of the bug).
This bug affects one of my sites, namely the front page of obsdewilgen.nl (site in Dutch). The dates on the updates on the right are right-floated and italic, so they triggered the bug. I had put off doing anything about that since IE7 was still in beta, despite the fact that Dave Massy had already informed me that they weren't going to fix this.
But now I couldn't delay any longer. I figured I'd just have to change the text to not be italic, but I'm glad to say I found a work around! Simply set overflow-x:hidden on the body element, and there you go.
It's a shame this bug's in there, since it's a regression (IE6 didn't have the problem), and I really wish they'd fixed it, but thankfully with this workaround I can still get my site to look as I intended it in IE7.
Let's hope this bug'll be gone in IE8. :-)
A little bit later than I had hoped, I now bring you the third article in my series on Internet Explorer add-on development. As promised, we're going to look at dealing with user input.
This article is really only relevant if you want to handle keyboard input, but you probably at least want to allow a user to use the arrow keys to navigate your toolbar buttons, so the odds are good that you need this if you're writing a toolbar. The Find As You Type add-on also has a textbox on the toolbar, so it needs this even more.
As it says on MSDN, if you want to handle keyboard input you must implement the IInputObject interface on your object, and when you implement IObjectWithSite::SetSite, you should QueryInterface the IUnknown object you get passed for IInputObjectSite and store this pointer somewhere.
This IInputObjectSite pointer is used to tell IE when you have the keyboard focus. It has a single method named OnFocusChangedIO, which you should call whenever your toolbar receives or loses the input focus.
This means you should handle the WM_SETFOCUS and WM_KILLFOCUS messages. Last time, we subclassed IE's rebar control, but this is not the place to handle these messages! Internet Explorer really isn't interested in you telling it when its own rebar control got focus. It wants to know when your controls got focus.
This means we must do yet more subclassing. Every control in your add-on that can get the keyboard focus must be subclassed. In the Find As You Type add-on, these are the toolbar itself and the textbox. You can use the same procedure as used previously, just substitute the window handles, window procedures and the variable used to store the old window procedure. Don't forget to put always call the original window procedure at the end of your own and to put the original back when the control is destroyed, just like last time.
In this case, you own the windows you are subclassing, so you can store the pointer to your toolbar object directly in those windows (for the toolbar, we already did this last time) and we don't need to use FindWindow in the window procedure, just call GetWindowLongPtr on the window handle that was passed to the WndProc. We can now handle the WM_SETFOCUS and WM_KILLFOCUS messages and call IInputObjectSite::OnFocusChangedIO passing true and false respectively.
In concert with this, you should implement IInputObject::HasFocusIO to return true when you have the focus and false when not. You can set a flag when handling the focus messages, or you can use GetFocus to see if one of your windows has the focus.
The more interesting part comes with TranslateAcceleratorIO. Even if you don't want to do anything special, you must call TranslateMessage and DispatchMessage here, otherwise keyboard input can break in strange ways, which tend to be inconsistent across browser version. In my case it seemed to work right in IE6, but broke in IE7. So call those two functions.
For IE7 compatibility, you should also check if the message is referring to any of the window navigation keys, such as tab, shift-tab and F6. When you get any of those keys, don't call TranslateMessage and DispatchMessage. Instead, return S_FALSE, so IE can properly respond to those keys. If you have more than one control, you can choose to handle the tab key messages to navigate between your own controls. IE6 doesn't seem to send tab key messages to toolbars, but IE7 does.
If you have any actual accelerators, here's the place to implement them. You can manually check the message, or add an accelerator table and call TranslateAccelerator. You can use this for shortcut keys and mnemonics used by your toolbar.
You might have noticed that TranslateAcceleratorIO is called by IE only when your toolbar has the input focus. It is indeed impossible to handle keyboard shortcuts if your toolbar doesn't have the focus using this method. Vista appears to have a way to solve this (although I have not tested if it actually works) with the IInputObject2 interface, which defines a TranslateAcceleratorGlobal method. This solution, if it works, would still be limited to when your toolbar is loaded (even if it doesn't need to have the focus) and would be Vista specific.
The other way to respond to keys globally that doesn't have these drawbacks is by using a Browser Helper Object and a keyboard hook. But I will leave that for a future post.
Earlier, I wrote about how I'm trying to get the Monbukagasho (MEXT) Scholarship to go to Japan for two years.
As I briefly mentioned in that post, the next step in the process was to get admission to the University of Tokyo. After all, what's the point in getting a research scholarship if I don't have a university to go to?
Yesterday, I received an e-mail from the University of Tokyo, Graduate School of Information Science and Technology, Office of International Relations, saying that my application has been processed and I have been accepted! All that's left now, if my understanding is correct, is to get final approval for the scholarship from Monbukagakusho itself in Japan, meaning that I'm actually starting to believe I could really get it.
So, as the title of this post says (for those who can't read Japanese), "boku ha toudai-sei desu", I'm a Tokyo U student!
Microsoft Windows Vista has brand new common file dialogs, but unfortunately the OpenFileDialog, SaveFileDialog and FolderBrowserDialog classes from System.Windows.Forms do not use them; they still get the old-style dialogs.
Ookii.VistaDialogs is a .Net 2.0 class library that allows you to use these new-style dialogs exactly the same way as you use the normal dialogs. In addition, it has been created in such a way that you can target both Vista and older versions of Windows (which don't have this new-style dialog) without any additional effort on your part.
The curious might want to know why exactly .Net doesn't use the new style dialogs. Vista provides a new, more powerful, API for accessing the common file dialogs, and obviously .Net 2.0 doesn't use this API, but this isn't the problem. In most cases, even when you just use the old GetOpenFileName API you get the new style dialog. The thing is, the Vista style dialogs do not support hooks, so if you use a hook, you get the old style dialog. And that's where the problem lies: .Net uses a hook so it can't use the Vista style dialogs.
Unfortunately, some of the functionality provided by .Net's FileDialog classes could only be achieved using hooks with the old API, so if I wanted to use the Vista style dialogs, I'd have to use the new API, and try to replicate all the functionality that way. The benefit to this is of course that if I want to, I can easily add more advanced functionality from the new API in the future (currently, Ookii.VistaDialogs just replicates the old functionality with the new dialogs, it doesn't expose any of the new features of the new API).
Using the new API seemed simple enough; it was after all a bunch of COM objects. Unfortunately, there was no type library for these objects, and their IDL definitions were hidden in a huge (60,000 lines) IDL file. Also, one of the functions took a HWND as parameter, which would need to be a IntPtr in my library to make sure I can correctly support both x86 and x64, and I needed some methods to use the PreserveSig attribute to get the functionality I need. TlbImp isn't good at those last two.
So what I ended up doing was creating my own IDL file with just those definitions from the big file I needed, compiling that into a type library with the MIDL compiler, then importing that using TlbImp, disassembling the generated interop library with Reflector, and then manually making the changes I needed.
Then, I could finally start on the classes themself, which fortunately wasn't all that difficult (the new API really is great). These classes have the exact same public interface as the original FileDialog classes in .Net, so all you need to do is replace all instances of the original classes with my classes in your code, and you're good to go. Like I said the classes fall back if the Vista style dialog is not supported, so it supports older versions of Windows as well.
Subscribe