2008/9/2 Dick Hollenbeck <dick@...>:
[...]
If wxFormBuilder were to be used, then the discussion could be limited
to two class names per dialog window. But let me stray briefly to
state some general preferences first.
I prefer *all* upper case class names, not just first letter of each
word. The reason is that this distinguishes class names from function
names, for which I prefer the upper case first letter only. Any prefix
should be indicative of function or purpose. I think using Ki_ is not
providing value here, since it does not indicate function or purpose.
But I am not opposed to prefixes in general.
Regarding the two classes per dialog, one of which would be derived from
the other, we might think about adopting a pair of prefixes to show that
these two classes are related and share a common purpose by way of a
common basename, for example, with "basename" being variable per such pair:
fbr_basename.cpp holding a class with name FBR_BASENAME autogenerated
by wxFormBuilder
dlg_basename.cpp holding the class derived from FBR_BASENAME with name
DLG_BASENAME which has the hand coded event handlers.
fbr_xyz.cpp and dlg_xyx.cpp would always be considered part of a set
implementing the dialog window. dlg_xyx.cpp in a rare case might not
be needed if there were not custom event handlers.
Could we agree on such a scheme, if JP were to accept the wxFormBuilder?
IMO very strange coding standard - I've never seen such in any open
source code and commercial code. But decision about this is not mine.
I would prefer DialogClassBase or DialogClassGenerated for code from
wxBuilder and DialogClass for derived code.
I probably need DialogBase class for handling font set up - this has
to be set before controls are created. wxFormBuilder creates them in
class constructor (one another disadvantage of wxFormBuilder).
Could we create coding standard wiki page?
Michal
