4) Dialog test mode. Personally I don't care about this much, but pretty much every other resource builder, including a free alternative, has this feature.

5) Alignment tools. This is an absolute must! There isn't even a snap-to-grid option. Resource Builder forces the user to place one... control.... at... a... time... I have an emulator debug panel with 40 text edit boxes, 40 labels and a dozen buttons and other controls. I wanted to use Resource Builder to switch my interface from VCL to win32 dialogs, but theres no way I'm going to manually edit each and every object for size and position tweaking, especially when there is no basic control duplication support.

6) More of a ease-of-use request. Sure, true and false are obvious choices for boolean style flags, but why not make the items checkboxes and allow single or double clicking to change the state? Having to select true/false from a drop down list box takes a lot longer than double clicking and it eliminates the possibility of going down the list rapid-fire and making changes as needed.

This looks like a gripe list, and it is, but when it comes down to it, I'm probably going to have resort to using Resource Workshop 4.5 to get my project done in a reasonable amount of time, even after purchasing Resource Builder 2.0.

I do like the look and feel of Resource Builder. Its just a shame that the dialog editor has been neglected when it is probably the most frequently utilized component of a resource editor.

If you use Reopen to reopen a resource project, the tools->compile option remains disabled, even if you modify a resource and save the file. I'm not sure if this happens if you first get the compile option enabled, but it definitely happens when you reopen a resource file immediately after starting the program.

The attribute list for COMBOBOX controls is always defaulting to CBS_OWNERDRAWFIXED for the style, even when the loaded resource script clearly shows that there is neither a CBS_OWNERDRAWFIXED nor CBS_OWNERDRAWVARIABLE flag. In addition, imported COMBOBOX controls are being set to OWNERDRAWFIXED in the created script when they should not be. Aside from the sync problem between the attribute panel and the actual settings, the default for COMBOBOX controls should be CBS_DEFAULT and CBS_HASSTRINGS, since this is the most frequently used type of combobox.

Feature Request:

Component names are autogenerated and cannot be changed. Right now they are pretty useless. In addition, the resource script uses control IDs directly. I would like to see support for #define in the .rc files and be able to use the control name field as an identifier, eg IDC_CONTROL_NAME. This will make editing scripts by hand much less painful and it will eliminate the need to manually create a set of #defines that are needed to reference controls using the WinAPI commands.

I'd also like to see support for the remainder of the window styles, especially the extended styles such as WS_EX_NOPARENTNOTIFY.

No attribute changes to edit box window styles are saved. The style is always written as ES_LOWERCASE | WS_VISIBLE | WS_CHILD. You can set ALL window style attributes to TRUE and char case to ES_DEFAULT, save the dialog and reload the RC, and all window style attributes will have been reset in the script, even if WS_VISIBLE appears as TRUE in the attribute panel. Changes to CharCase are not recorded either. All changes to the edit box states in the attribute panel are recorded (ES_* constants).

Edit boxes are incorrectly defaulting to ES_LOWERCASE. They should be defaulting to ES_DEFAULT (no case conversion). This may or may not be related to the above bug. In any case, edit boxes created from scratch seem to default to ES_LOWERCASE, and they should not.

I've also found that scripts imported from Resource Workshop 4.5 cannot necessarily be loaded back into Resource Workshop 4.5 after your import process mangles them and converts everything to CONTROL statements. I'd like to see a little effort into improving export compatibility at least until the text editor is no longer the most reliable method of creating resource scripts with Resource Builder.

Thanks for releasing a temporary bug-fix release. There are still bugs in the attribute panel code.

Changes to the dialog style attributes are not registered. This includes both the Styles and WindowStyles sections. The dialog style line in the RC file is always being written as "STYLE DS_SETFONT |WS_OVERLAPPED |WS_CAPTION |WS_SYSMENU |WS_THICKFRAME |WS_MINIMIZEBOX." The font is not updated either. The line is always written as "FONT 8, "MS Sans Serif."

Well, now I'm not completely sure this is the case. I do know, however, that the dialog size is not being updated. I resized my dialog by dragging the window frame. The width and height were updated in the attribute panel but when I selected "Edit as text," the width and height values were not changed from the original values. You can verify this by reopening a resized dialog and noticing that the sizing is not what you last changed it to.

Also, I am noticing some bizarre and extremely annoying glitches involving edit boxes. By performing some unknown action (although I think its by playing around with the dialog window styles), it is very possible to cause Resource Builder to reset the WS_VISIBLE style of all child controls to FALSE. I edited a dialog and recompiled my program in C++ Builder only to have the dialog appear totally blank. All 180+ controls on the dialog had the WS_VISIBLE stripped!