The Sandbox Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Vista style file dialogs for .Net 2.0

Back to Forum: The Sandbox
  • User profile image
    Sven Groot

    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 (want to know why?).

    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.

    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.

    For detailed usage instructions see the included readme.txt.

    UPDATE 2006-12-02: Uploaded version 1.2.

    Version history:

    • Updated to use Interop files from the Windows SDK "VistaBridge" sample.
    • Fixed a resource loading bug that could lead to incorrect UI strings on Vista when the Windows UI language does not match the system code page when certain properties of the VistaFileDialog classes were set.
    • First release.

  • User profile image

    Wow! This is sweet. You mention some hooks that needed to be installed to get all the functionality the current .NET classes provide. By using the new dialogs, those hooks are no longer required?

    I hope this gets adopted as fast as possible and is already avaialble in .NET 3.0!

  • User profile image
    Sven Groot

    littleguru wrote:
    Wow! This is sweet. You mention some hooks that needed to be installed to get all the functionality the current .NET classes provide. By using the new dialogs, those hooks are no longer required?

    Yes, that's the case.

    .Net's own file dialog classes use the old API (naturally), and they must use a dialog hook. For example, the dialogs fire the FileOk event (which is a cancellable event) when the user clicks OK. With the old API, there is no way to determine when the OK button is pushed without using a hook. It is because .Net uses a hook that it gets the old dialogs, because the new dialogs don't support hooks. If you use the old API without using hooks, you get the new dialogs, but for .Net this is impossible if you want to preserve all functionality.

    The new API is completely different from the old one. It provides far more powerful ways to customize the dialog, and it also provides a proper event model (in the COM way so an event interface that needs to be implemented on an event sink object which is then registered with the dialog). This is what I used to replicate the additional functionality. It's really a very nice API (the only drawback is that it's hell to interop with due to the lack of a type library and the use of handle values).

  • User profile image

        Sven, I am sorry to tell you that you are actually reinventing the wheel, the Windows Vista SDK already comes with a great example of how to wrap the new vista dialog APIs in .net, they are both callable from windows forms and WPF applications, it is located in:

    Your Installation Driver:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\CrossTechnologySamples\VistaBridge


  • User profile image

    This is really amazing. Nice work and neat code Big Smile

  • User profile image

    Here is the MSDN link for the SDK sample mentioned above if you don't want to install the whole Windows SDK:

    However, the example application shows many things and depends on WPF, so to be able to compile/run it, you'll need it anyway.

  • User profile image
    Sven Groot

    Thanks for reminding me about this thread. Smiley

    I still had an update to upload. It fixes a bug, and uses the interop classes from the sample Footballism mentioned instead of my own.

    EDIT: If you're wondering why I don't just use the library from that sample instead of writing my own, it's because the library from the sample doesn't take non-Vista OSs into account, so you'd still have to write your own fallback code unless you want to support only Vista. With my library you get that for free, and since it uses the exact same public interface as the original FileDialog classes it's trivial to plug it into an existing application.

  • User profile image

    Yup, what Sven said Smiley.

    I'm actually the VistaBridge developer (or the main one, at any rate - there have been several contributors over the past several months that are adding content), and Sven speaketh the truth. The VistaBridge sample lib currently has very little fallback for pre-Vista OS versions, and that is somewhat by design, at least in terms of our priorities around geting exposure to the new Vista APIs. I'm working on a version 1.1 (which really should be 0.9, but hey) that will be on my blog in "a while" that has a bit more fallback behavior, but it won't be super-rich - 1.1 will have more feature work rather than revisiting what is there now, so don't expect miracles there.

    More info at me blog:

  • User profile image
    Sven Groot

    Hi Jeff, great to hear from the guy behind the sample. Smiley

    It's clear that the VistaBridge sample and my own Ookii.VistaDialogs serve a different purpose: VistaBridge aims to make new functionality available to .Net apps, while with Ookii.VistaDialogs I just wanted to get the file dialogs to look "right" on Vista (especially since I've grown very fond of the "favorite links" bar Cool ) in such a way I could easily put it in apps targetting multiple versions of Windows.

    Both approaches are valid, of course.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.