Developers

"Win32 dialogs just aren't as whizzy as HTML. In HTML I can have 'resizable' dialogs with colors and fonts and pictures ..."

Win32 developers face a number of hurdles that are making Win32 applications difficult to develop and achieve the richness of such things as HTML. New platform UI advances are not being easily exposed resulting in a lack of incentive to move to new versions of the operating system. A lot of the functionality being added to the OS today requires the developer to re-write their code to take advantage of it.

In general, RCML's goal is to reduce the amount of complex coded that needs to be written to obtain common UI features.

Here is a list of examples of things that are require needless coding, are too hard or just not possible right now:

1. The upper and lower bound of the slider cannot be set in the RC file
2. The contents of the list box are not specifiable in the RC file
3. The contents of the combo box are not specifiable in the RC file
4. Only BMP and ICO file formats are supported by statics
5. There is no relative positioning of controls, only absolute positioning
6. There is no exposure of fonts and colors on a per control basis
7. There is no sound support (sonnificiation) of UI in dialogs
8. There is no rich text or HTML-like support in the static control (e.g. links)
9. Tool-tips and context help too hard to implement
10. Tabbing order and mnemonics are easy to mess up
11. Resizable dialogs not possible without mammoth amount of coding
12. Showing delay dialogs for potentially time consuming operations
13. Displaying splash screens when application is starting
14. It is not possible to change the text on Message Box buttons
15. Providing the “Do not show me this again” option

How does RCML address Developers needs?

To address the lack of extensibility of the existing resource format and dialog box API, developers will be able to extend base implementation of the RCML resource loader and customize it according to their needs.

RCML will provide an enhanced version of the DialogBox API (called RCMLDialogBox) that will perform a lot of the simple tasks that currently require menial coding. By using attributes on the controls the loader performs a lot of the initialization tasks without the developer having to write any code. For example, to set the minimum and maximum values on a slider control, the developer would simply have to set the MIN and MAX values in the RCML tag.

Where the platform has added new functionality, such as the filename auto-completion in the Windows 2000 shell, the resource loader can be enhanced to provide this in it’s DialogProc so that all RCML applications would get the new functionality for free. This would mean that it would be advantageous for a user to upgrade their OS to get this new functionality in their existing applications.

Other features to address the other needs of the Win32 developer:

• Allow controls to be positioned relative to other controls
• Allow display styles to be set declaratively using a STYLE tag
• Tool-tips, context help and balloon tips made first class citizens in RCML and handled automatically by the RCML dialog proc
• Dynamically introspect the dialog to provide automatic resizing capabilities with directed overrides by RCML authors
• Use GDI+ to load any image format supported by GDI+
• Add support for sound notifications on dialog controls
• Provide a simple set of APIs for displaying delay dialogs and splash screens with minimal coding effort
• Provide support for automatically dealing with “don’t show me this again” dialogs

Finally, in order to provide an extensible model, it will be possible to derive a new C++ loader class from the base RCML implementation shipped in the OS. This way developers can over-ride any functionality they do not like and extend the functionality that already exists.

If you have any more needs, or wish to debate the above, click here