For the addXXX() methods that add dialog controls to a user dialog there is a lot of inconsistency in both the naming of the methods and the ordering of the method arguments. This has lead to a lot of confusion and makes it difficult remember the correct method syntax without referring to the documentation all the time.
I think this is partially due to the edition of dialog controls over time, and maybe it is easier to see a solution with hindsight then it is to design it to begin with. There are two facts that could unify the addXXX() methods.
1.) Microsoft has an official name for every single dialog control and of course every control is a control. I beleive it would be better If each of the addXXX() methods simply used Microsoft's name for the control. And, tacking the word control on some methods and not on others shouldn't be done. Each one is a control and tacking control on the method name is redundent.
2.) Every single control has to have a resource ID, the four co-ordinates x, y, cx, and cy. Every single control has a set of style flags that may or may not be used. Then, some controls have text associated with them and some do not. Finally, ooDialog allows the specification of a "data attribute name" for some controls, but not for others.
I propse that the to unify the addXXX() methods, they should all have this format:
add<MsName>(id, x, y, cx, cy, styleFlags, text, attributeName)
For controls that do allow text or attributeName, those arguments will not be allowed. The style flags are optional for every control, so that argument is always optional. Where controls do allow text and attributeName, currently the args are always optional, so text and attributeName are always optional. For static controls and group boxes, Windows always requires the ID, but allows the static ID (-1) to be used. So for those controls, the id arg will be optional and default to -1. In addition some of the methods currently support the automatic calculation of either cx or cy, so for those methods cx or cy may be optional.
Converting ooDialog to the native C++ API offers a relatively painless and opportune time to implement this. For each control that ooDialog supports, the add<MsName>(...) method could be implemented with the C++ API, and use the above format. The existing addXXX() methods that do not conform to format could rearrange the argument array and forward to the appropriate method.
For instance, the addScrollBar() method already conforms to the proposed format and is simply implemented with the C++ API.
The addEntryLine() method does not conform. Microsoft calls the control an "Edit" control and the args to addEntryLine() do not fit the format above. So, a method would be implemented with the C++ API that looks like the following to the Rexx programmer (<> brackets indicate the optional args):
addEdit(id, x, y, cx, <cy>, <style>,
The existing addEntryLine() would simply re-order the arguments and forward to the addEdit() method. All existing addXXX() methods would continue to work as they currently do. Users can continue to use the existing methods if they choose. They will really just be aliases for the actual implementation.
The only fly in the ointment is that there are some methods that have the "correct" name, but the wrong argument ordering. These are addGroupBox, addCheckBox, addListbox, addComboBox, and addRadioButton. Because the argument ordering is not "correct" they can't forward to the actual implementation. For those methods, I propose using an abbreviation for the implementing method. These are easy for me to remember, not sure if it will be for others:
The list of methods would then be as follows
addStatic(<id>, x, y, cx,cy, <style>,
addStaticText(<id>, x, y, cx, cy, <style>,
addStaticImage(<id>, x, y, cx, cy, <style>)
addStaticRectangle(<id>, x, y, cx, cy, <style>) (or could be addStaticRect())
addGroupBx(<id>, x, y, cx, cy, <style>,
addPushButton(id, x, y, cx, cy, <style>,
addCheckBx(id, x, y, cx, cy, <style>,
addRadioBtn(id, x, y, cx, cy, <style>,
addEdit(id, x, y, cx, <cy>, <style>,
addComboBx(id, x, y, cx, cy, <style>, <attributeName>)
addListBx(id, x, y, cx, cy, <style>, <attributeName>)
addScrollBar(id, x, y, cx, cy, <style>)
addListView(id, x, y, cx, cy, <style>, <attributeName>)
addTreeView(id, x, y, cx, cy, <style>, <attributeName>)
addTab(id, x, y, cx, cy, <style>, <attributeName>)
addTrackBar(id, x, y, cx, cy, <style>, <attributeName>)
addDateTimePicker(id, x, y, cx, cy, <style>, <attributeName>)
addMonthCalendar(id, x, y, cx, cy, <style>, <attributeName>)
addProgressBar(id, x, y, cx, cy, <style>)
Since I don't see any downside to this, I'm starting to implement it. However, this leaves plenty of time for suggestions, comment, criticisms, etc..