.  RUDE Q&A

What is RCML?

Rcml is an XML based resource file format, based on the GUI requirements of Win32 applications.

How do I generate RCML files? 

You can automatically generate RCML files from existing Applications or Windows that you see on the screen. As part of the SDK we provide a tool called "RCMLGen.Exe". Click Here. If you have VC installed try out our Tutorial!

What new features are there in RCML?

Simplicity! We designed RCML to be a simple file format. You should be able to design more realistic dialogs without writing code!

How does the resize work?

There are two different reasons for a user to want to resize a dialog.

  1. They want to see more content, e.g. more items in a list. Click Here
  2. The dialog is too small and they want to 'zoom in' and get bigger fonts. Click Here

In essence the resize code works out a table of rows and columns from the location of the controls on the dialog. It then places the controls into the cells - like 'reverse engineering' a TABLE layout in HTML.

Once the table has been determined, it then proceeds to find which controls resize and which don't. This can be overridden by RCML authors.

How do I work out why my layout is wrong?

Simply use the ANNOTATE attribute and it will visually show you the resizing being used.

 

What platforms will you support down level?  When will this support be available?

We will support down level platforms.  The great thing about RCML is that we are not platform specific.  We do not make any WinNT specific calls.  That means you do not have to be reliant on the OS. 

When will the specs be frozen?

The specs are supposed to be at least 90% complete by M1 (August 13). So probably a few weeks after, but definitely before M2.  http://rcml/scheduleupdate.htm 

When can we start coding to it?

July 20 is the first official SDK drop of our M0 build.  http://rcml/drops.htm    

When will tools be available and how stable will they be?

 

We will be getting some type of support in VC 7. Essentially it will be a dialog editor and text editor. This is a huge step for RCML. It provides an opportunity for anyone to easily edit an RCML file. We will have extended support in VC 7.5.  Also, just as in the early days of HTML, notepad can be used to edit RCML files.

 

When will support be in LocStudio?

 

The LocStudio XML 2.0 parser is set to come out in Dec/Jan 1999 timeframe.  We might get some sort of minimal support by then.  Most likely we will have extended support in the XML 3.0 parser which is schedule for April/June 2000.

 

What is RCML going to do about hotkeys?

 

Most likely RCML will not support hotkeys in version 1.  The reason is that it is a localization nightmare according to the Text+ team (David C. Brown).  Furthermore, there isn’t any scheme proposed by MSAA to provide automatic hotkeys.  Hotkeys need consistency, so it’s VERY hard to generate at runtime.  We’ll leave this for now, but perhaps log if we find duplicates or missing keys.

 

What is your packaging scheme? Since MUI+ will only be ready in the NT6 timeframe, what will you do for NT 5.1?

 

Once the RCML file is final, it can be referenced from the .RC file and bound into the EXE that way.  Furthermore we will do nothing to prevent us from implementing MUI+ when it is ready in the NT6 timeframe. 

 

What type of control changes are necessary?

None!  RCML can work without any additional changes to the existing controls.  However, to get added functionality we would like to make a few changes.  Please look at this document. It is a work in progress. http://rcml/prelimcontrolchanges.doc >

How do you deal with the plethora of problems when you use DLUs? They are supposed to scale with fonts etc, but don’t.

Here is an informative email thread.  The simple answer is that we do support DLU's along with other units such as pixels.

>

    Label   [edit control]
    ?      [edit control]

 

As we should all be able to see, the line height changed to accommodate the taller character in the second line.  This doesn't happen with controls, my explanation as to why went along these lines:

A dialog unit is the average of the width and height of a set of characters (A-Za-z). As a result, if you use a character which is 'taller' or 'wider' the characters will likely be clipped.

NOW: Use real numbers inside the DLU scaling algorithm - the current code uses integers and jumps in steps of 10 to 15 % at a time, thus causing up to 15% clipping.

FUTURE: Stop recording dialog item positions as absolute coordinates, and start recording the alignment operations the designer used. Apply those alignments at run time to the actual measurements of each control. For edit controls the designer must choose the languages to be supported and accept that more languages means taller controls. Averaging the size of A-Z a-z is a low quality compromise at best - the more languages and scripts we handle the sillier it looks. 

Will there be 64-bit support in RCML?

 

Yes.  RCML will follow the guidelines set forth by NT USER in order to comply with 64-bit code.  Depending on when USER sets their specs, we might have support in version 1, but definitely by v2.

 

Will you support the GML spec?

 

Yes.  Supporting the GML Spec is an M1 goal.  Please look at our timetable here http://rcml/scheduleupdate.htm

What font support do you have?

We migrate the CCS Styles for fonts to a logfont.  Here is an email thread on the subject.  

Do you have Wizard/Property Sheet support? How extensive?

 

Currently we have wizard/property sheet support for Win32 Developers.  We are creating a new Wizard/PropSheet schema which will contain all the pages in one file (as opposed to the one dialog per file we have implemented today).

We have converted intl.cpl (Regional Settings in the Control Panel) over to RCML.  Look here <insert link to intl.cpl conversions>

What kind of testing do you have in place? For down level?

 

Currently we have one dedicated full-time tester on RCML.  If we decide to go down level in version one, we can expect to get more testing resources.  The test schedule is approximately dev schedule + one month.  This means that whenever the dev’s finish a milestone, they will get test sign-off approximately one month later.

   

What are your dates?

 

Please look at http://rcml/scheduleupdate.htm

 

What customers do you have lined up already?

 

Window NT 5.1 and Exchange Server are our primary customers for V1.  We do expect the list to grow considerably since many groups have expressed interest in RCML as a format that solves their problems with the current RC format.

 

How do you handle clipped text?

 

We work out how big the content is and then re-size the control accordingly.  Currently the code cannot handle any tricky designs, however, we have come up with an elegant solution that will be coded in by M1.

 

What type of runtime support do you have? Can you change the layout of the dialog on the fly?

 

We provide the ability to do string substitution on WM_INITDIALOG. You can use entity substitution. This makes your code a lot easier too. Here is an example http://rcml/examples.htm  Another dynamic issue is interacting with the dialog while the text or controls change.  Currently we do not have that support available, but it should be in our version 1.

 

How do you deal with commenting (for localization people)?

 

Currently any comments made in the RC file are lost at compile time.  Therefore the developer cannot tell the localizer what strings should and should not be localized.  RCML will keep all comments in the file so the localizer can access it.  Since RCML is an XML based application,  it provides the ability for any group to easily add comments during any stage of the product cycle.  

 

What are your performance numbers?

 

We scale pretty well. My test with 300 controls comes up in a blink

The working set hit at startup is not that bad and it comes mainly from OLE32 and msxml. GDI+ and video are delay-loaded and USER32 and the DLLs that depend on them are loaded as well in the non-rcml version of the app.

Here are some mails:

Do you have any version info?

 

We have 'partial' version information. This is not in sync with NT5 version information (a few reasons, mainly enlisting, and confusing people into thinking this was an NT5 component).

To get the version information, get properties on RCML.DLL or RCMLGen.EXE.  We have updated the TESTINFO element to get the version information.

 

When I use your generator, my statics come up empty and sometimes my icons/images don't show up.  Why?

Currently we display the dialogs outside the application for testing purposes.  That means when we generate RCML files from your EXE, we do not currently use your applications dialog proc.  So any controls that are changed during runtime will not work during the test phase.  However, once the dialogs are bound back into the EXE or simply displayed from within the application, the dialog will display correctly. 

If the files are separate does that mean that localization has twice as many files in their database?

Not necessarily.  The designer will probably keep the RCML files external to the EXE when they are editing the dialogs.  However, they can always bind  it back into the EXE and send it to the localizer. 

What type of Unicode support do you have?

We support both ANSI and UNICODE rcml files. Internally the binaries are UNICODE and provide UNICODE and ANSI entry points. For down-level platforms, we're building an ANSI version of the DLL and generator (this last one not implemented, but no big deal in doing it). If the nls+ project JulieB is pursuing gets approved, we're going to use those wrappers and ship one set of UNICODE binaries that will work on all platforms. As you know the GML stuff is not implemented yet, so we don't know to choose the right strings based on locales yet.

Will this cause a proliferation of resource files?

No.  Although we currently have it as one RCML file per dialog, this is not very difficult to handle since RCML is just basically a text file.  In fact it is probably easier to handle RCML files than it is to walk the current resource tree.

When you finally ship your product, the RCML files should be bound INTO the executable the same way bitmaps and icons are bound 

How do you deal with bidi and orientation changes?

We are currently working with various localization teams from across MS to come up with a viable solution. 

Are you working with COM+? Is there some common ground you can reach on an XML format?

 

We have spoken with members of the COM+ team and have decided that at least for now, we are two separate file formats.  Perhaps in the future we can reach some middle ground in how we deal with string tables and maybe even use the same binary format, but currently there are no plans.