kicad-developers team mailing list archive

[jean-pierre charras <jean-pierre.charras@...>]

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