kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/21/2012 11:05 AM, Dick Hollenbeck wrote:
> On 03/19/2012 04:12 PM, Dick Hollenbeck wrote:
>> Jean-Pierre and Wayne:
>>
>> Please grep for these two symbols in my latest commit.
>>
>> It is an initial attempt to institute some common dialog behavior.   Two common behaviors
>> I really enjoy are:
>>
>> 1) ESC key aborts dialog
>>
>> 2) s_LastPos and s_LastSize handling, which retain dialog sizes, such as
>> eeschema/dialog_edit_label.cpp when editing large EESCHEMA multi-line texts.
>>
>>
>> Arguably 1) could be done in a class between wxDialog and formbuilder written class, and
>> done only one time, but this would entail having to tell formbuilder to derive from a
>> custom class, and I don't know if that works.
>>
>>
>> However 2) needs class specific storage, and is not easily done in a base class beneath
>> the formbuilder generated one. 
> After sleeping on it, I would like to discuss this alternative option before SHIMMING all
> the dialogs with the macro DIALOG_EXTEND_WITH_SHIM.
>
> If we put one shim in underneath the wxFormbuilder generated dialogs, we only have
> instance of the code.
>
> I see now that wxFormbuilder can extend from a custom class that is very similar to
> wxDialog.  (Search for "subclass" in the formbuilder UI.)
>
> This alternative approach has some advantages in terms of code size, and source code
> disruptions.
>
> If we can get the class name, we can use that in a hashtable to keep the size and
> position, for all formbuilder classes in a single table.
>
>
> The alternative strategy entails:
>
> 1) writing a decent wxDialog derivative as a shim at a lower layer pair, at least one shim
> is needed, but maybe a couple.
>
> 2) Use wxFormbuilder over time to derive from this shim dialog class, which is then a shim
> above wxDialog but beneath all the wxformbuilder classes.  This item can be done over time.
>
>
> This alternative strategy does not precluding having more than one shim which sits
> immediately above wxDialog.
>
> Can we use RTTI to get the derived dialog class name?  If so, 1) is not too hard, to
> implement my precious retentive size and position support.

I added DIALOG_SHIM class, and is in my view a better way to go since it is less code
since this shim sits right on top of wxDialog rather than on top of the formbuilder
classes, so only one shim class is needed, rather than one for each dialog.

Be aware that the "sublcass name" and "subclass header" properties are supported at the
"dialog window" level in the formbuilder *.fbp.

You enter

DIALOG_SHIM
dialog_shim.h

for these two fields and they go into the XML *.fbp file, verify this.

Bad news is that upon loading the XML file, formbuilder does not display those properties,
instead shows blank, even though it is obviously still using them.

Can somebody please file a bug report with the wxformbuilder people, PLEASE.

I give a lot, I'm asking very little.

Thanks,

Dick