Hello, my name is Daofa Li, and I am on the Visual C++ QA team. In this post I will be sharing with you the improvements in Dialog Editor for Visual Studio 2010.
In Visual Studio 2010, we have improved Dialog Editor in the following features:
· Add mockup image support to help layout controls in dialogs
· Add support to use the new MFC controls in design time
· Enhance the ActiveX control security in Dialog Editor
A mockup image is an image that specifies the exact layout of a dialog – including the information of the exact size and position of controls in the dialog. A mockup image usually comes from the artist/designer. The developer has to make the dialog look identical with the image. This could be a tedious process that might take many hours of fine tuning and checking until the results are satisfactory.
The good news is now the developer can use this mockup image to guide designing the dialog. In Visual Studio 2010, Dialog Editor has a semitransparent layer that shows the image in the background and that provides the exact guide on how to layout the controls. To make the dialog look identical with the mockup image, the only thing the developer has to do is to drag and drop controls to the position indicated in the image.
In the following scenario, I got the mockup image from my designer, and I will use this mockup image to guide me in designing the dialog.
I create the new dialog resource in Dialog Editor. At the bottom of the Dialog Editor window, there is a mockup bar that controls how the mockup image shows up. The Mockup bar can be toggled on or off in the “Guide Settings” dialog by checking or clearing the “Mockup bar” checkbox.
To use the mockup image, I first check the “Mockup Image” checkbox in the Mockup bar. This action will enable the rest of the controls in the Mockup bar. Then I click the browsing button (…) at the right end of the bar to open the “File Open“ dialog and select the mockup image file I am going to use for designing the dialog. The image file name is displayed in the Mockup bar and the mockup image immediately shows up as a semitransparent image overlaying the client area of the dialog form. I can drag the “Transparency” slider to adjust the transparency level of the mockup image so that it has a comfortable visual effect. By default the mockup image anchors to the upper-left corner of the client area of the dialog form. I can adjust its anchor position by changing the X and/or Y coordination offset values in the Mockup bar.
Once I complete my design, I can clear the “Mockup Image” checkbox not to show the image. Note that clearing this checkbox doesn’t remove the mockup image. Once you check it again, the mockup image shows up with its previous settings – transparency level and position.
The mockup image information is persisted in the .rc file. In the GUIDELINES section, each dialog resource that has associated mockup image will have a MOCKUP entry that specifies the mockup image information:
MOCKUP, 1, 81, 0, 0, ".\res\mockup.jpg"
The information starts with “MOCKUP” indicating a mockup image guide is using in this dialog, followed by the status of the “Mockup Image” checkbox, the transparency level, the offsets of the image position and the mockup image file.
The mockup image effects only at design time, it will not be saved as part of the dialog resource thus has no effect at runtime.
Starting Visual Studio 2008 SP1, new MFC controls were introduced, however these new controls could only be used in source code and visual effect could not be seen at design time. In Visual Studio 2010, the most commonly used “new” MFC controls were integrated into the Toolbox and can be drag and drop to Dialog Editor at design time. Below is a screenshot that shows the “new” MFC controls in the Toolbox. The “new” MFC controls start with “MFC” in their names.
I know this may sound obvious to many but I would like to mention that these MFC controls require MFC support. They may not show up correctly in the dialog at runtime if they are used in non-MFC applications.
Handling ActiveX controls in dialogs
In Visual Studio 2010, you may have slightly different experience in using ActiveX controls in Dialog Editor than previous versions. When you open a dialog resource that contains ActiveX control(s), you’ll get the following message box before the dialog resource is opened in Dialog Editor:
If you are not sure of the resource of the ActiveX controls you are using, you could choose “No” and the dialog resource will not be opened in Dialog Editor. If you trust the ActiveX controls, you can choose “Yes” and the dialog resource will be opened for you. This is a one-time “Yes” answer per session. Next time, before you unload the resource file, when you open a dialog resource containing ActiveX controls you will not get this message box if you already answered “yes”.
Another different experience you may have is you may get the following message box before the dialog runs in test mode, when you test a dialog containing ActiveX controls by pressing CTRL-T or clicking the “Test Dialog” toolbar button:
If you don’t trust the ActiveX controls or you want to save your work before running the dialog in test mode, choose “No” to stop entering the test mode. If you want to proceed testing the dialog, click “Yes” and Dialog Editor will try to run the dialog in test mode – if everything runs well, you will not get this message box next time when you run the dialog in test mode again.
I recommend you to save your work before running a dialog containing ActiveX controls in test mode because you might lose your work if any of the ActiveX controls does something wrong and crashes the Visual Studio.
There are several reasons why we need these security enhancements in handling ActiveX controls in Dialog Editor:
· ActiveX controls usually come from third party. Dialog Editor doesn’t have the knowledge about whether they are safe or not, and cannot make the decision for the developer whether it is safe to use these controls.
· When Dialog Editor opens a dialog resource containing ActiveX controls, these controls are initialized using the data persisted in the .rc file. The data could be unsafe and the ActiveX controls could be harmful to the system.
· When the dialog runs in test mode, the contained ActiveX controls are running in the system as well. If any of the controls is unsafe, it could be harmful to the system. If anything unexpected happens within the ActiveX controls, it might crash the Visual Studio and you could lose your data because Dialog Editor cannot control the ActiveX control’s running behavior.
Image Mockup ???
That's a weird non-feature!
In all my years of developing I never had an urge to use an overlay mock-up image of the UI to build it from the designer.
I'm wondering how it came to be? was it really asked by clients/developers ?
One thing I'm still waiting and will probably never happen for MFC is a good layout manager that is build in the dialog editor with a good dynamic dialog/form resizng tools (see the Mac OSX UI builder)
New MFC controls:
Yes, good thing, but should it have included the property grid ?
The mockup thing is indeed a weird feature.
To Max: maybe you could design your dialogs with the Mac OSX UI builder and use screenshots as mockups? :-D
Isn't positioning to an image mockup counter to the style guidelines for Win32 UI? I thought the point of dialog units were that your dialog positioning was relative to the font size used and that you were supposed to arrange your controls according to metrics measured in DLUs. Arranging relative to a mockup image is a bad idea IMO because it's likely to produce dialogs where the controls aren't evenly spaced or looks unusual with a different dialog font. I would rather have control-to-control spacing and alignment guide support like in the WinForms editor and many other UI editors.
Also, is the ActiveX dialog flag persisted anywhere? My experience in the past has been that even once-per-session dialogs are too annoying -- we banned a specific customization in C# projects because the MSBuild project security warning was too problematic even at once per session. I'd suggest that there should be an option to remove the dialog completely for a specific ActiveX control. Presumably if you have installed the control in the system, you have some trust in it, given ActiveX's (lack of) security model.
I only use DialogBoxIndirect. I also make menus. I haven't use a dialog editor since OS/2. I like the results. That the dialog editor was/is? crapola is a small part. Don't get me started on the bitmap editor.
Huh? I can't believe that you've spent your valuable time adding support for such a strangely useless concept as "mockup images" to the VS2010 dialog editor.
To be fair, it might not be such a waste. I guess that's the way developers at Microsoft design their own dialog boxes, so if the feature is useful for them why not making it available to everyone.
Mockups - nice feature most of us can live without. I've seen more relevant things closed on Connect as won't fix - more relevant to me, at least.
Maybe an important customer asked for it - sometimes reason enough to implement such things. Besides, transparency, too!
@Phaeron: good pointing out the UI guidelines.
ActiveX: I understand the motivation behind the messages - opening the dialog in resource editor already runs the code, which might be surprising for "a developer in a hurry".
Still, telling a C++ developer "X might be harmful to your computer" *IS* not only strange, but also questionable: there are many other attack vectors getting a developer to run some code. Won't putting a warning on a single one actually reduce alertness?
A rather expect the dialog editor to use pixels unit rather than dialog unit... Dialog unit is imprecise ... I hate it ... I want to position things in pixel unit on my dialog!!
Thank you for all the comments. Our PMs and devs will definitely take them into account.
@Max: the MFC PropertyGrid control is already added to the ToolBox.
@Phaeron: good points on UI guidelines and ActiveX controls
I personally find the mockup trick useful. Every release cycle I’m asked by marketing guys to facelift our banking UI, move the buttons top right, on the next one, bottom right, add a logo, change a logo... it never ends. When you deal with 200+ dlgs, it gets tricky to maintain a nice standard look and feel. I would have loved to be able to see the dlg on multiple OS themes though, combined with this.
"[I] rather expect the dialog editor to use pixels unit rather than dialog unit... Dialog unit is imprecise..."
Until you switch to a larger font because mom complains "it's hard to read that small".
DLU's are precise - only they are bound to the font the dialog uses. It's a simple yet effective scaling mechanism.
What is the point, when there is a lot of other areas that you can improve on... example
Toolbar editor.. bitmap or icon editor.. these things hasn't changed over the zillion years..
I am wondering how do you guys sleep at night ?
There are definitely many things we can improve about the resource editing experience for C++ as many of you pointed out (toolbar editor, icon editor, guidelines, etc...). I would add that for bitmap/icon editing, we convinced Axialis to create a free "light" version of their Icon Workshop specifically to address the deficiencies of our editor. After all, we don't think we can always be the absolute best tool for each job.
Going forward, we are committed to improving this and we are looking across the board to see how we can modernize the C++ visual resource development experience in the future. The ideas mentioned here are valuable and we'd love to hear more.
What about a grid control like bcg or codejoke grid control?
I'm still waiting. Visual c++ dialog editor like C#
MFC is bad option to build complex. Dialog. Until MS visual C++should learn to improve this