← Back to team overview

kicad-developers team mailing list archive

Re: DialogBlocks discussion once again.

 

Dick Hollenbeck a écrit :



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?


Dick




I had a look to wxFormBuilder 3.0 and it seems a very good tool.
Switching from DialogBlocks to wxFormBuilder is Ok for me.

Wayne, I know an autogenerated dialog code is not the best.
It is more difficult to understand (and maintain by hand) than dialogs created by hand (and by a skilled guy)
and it is far from an optimal code.

But some guys can be skilled programmers and do not know very well the use of wxSizers (and a lot others items useful in nice dialogs)) in wxWidgets. So using a tool like wxFormBuilder (when correctly used) can be a very acceptable way of work. Using a tool like wxFormBuilder could be also a way to understand the use of these useful items.

--

Jean-Pierre CHARRAS

Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
GIPSA-LIS - INPG
46, Avenue Félix Viallet
38031 Grenoble cedex






Follow ups

References