Wish-list: Behavior when specifiying the Class of a control/window

Recently, in my project I wanted to create a custom titlebar for my
project. I decided I could create a titlebar that was essentially a
window control right within DB v3.14.

To do this in DB I created top-level-element, CustomTitleBar derived
from type wxPanel and configured my custom titlebar controls there.
Then, I went to another dialog, SidePic, and turned off the regular
title bar and added a blank wxPanel in the spot where the
CustomTitleBar panel was to go. I took care to include the
"CustomTitleBar.h" file by manual edit of SidePic.h. I then edited the
new wxPanel in the property editor so that the "Class" field read
CustomTitleBar.

When I went to compile I was surprised to discover that DB had defined
ANOTHER CustomTitleBar class right in my SidePic Dialog class. Having
two declarations of CustomTitleBar made the compiler unhappy and I
didn't want to move my actual declaration into SidePic since I wanted
all my windows to use my custom titlebar control. I futzed with a
smattering of "#if 0"'s for a bit to disable this unwanted class but
ultimately gave up and took the wxPanel out of SidePic from DB's point
of view and inserted the CustomTitleBar manually after the controlled
code block in CreateControls.

So, while it was very nice to be able to design the titlebar within
DB, I could wish that specifying an alternate class for a control or
window would give you the option NOT creating the alternate class
within the dialog class file itself. At the very least, if the class
is based on wxPanel, and the Specified class is actually defined in
DB, it would be cool if DB didn't create a second definition

Regards,
Royce

Messages in this topic (1) Reply (via web post) | Start a new topic

.

Hi Royce,

As I understand it, you want to check the "External implementation"
property where you
reference the CustomTitleBar class. This will stop DB from generating
the class again.

Best regards,

Julian

roycepipkins wrote:
> Recently, in my project I wanted to create a custom titlebar for my
> project. I decided I could create a titlebar that was essentially a
> window control right within DB v3.14.
>
> To do this in DB I created top-level-element, CustomTitleBar derived
> from type wxPanel and configured my custom titlebar controls there.
> Then, I went to another dialog, SidePic, and turned off the regular
> title bar and added a blank wxPanel in the spot where the
> CustomTitleBar panel was to go. I took care to include the
> "CustomTitleBar.h" file by manual edit of SidePic.h. I then edited the
> new wxPanel in the property editor so that the "Class" field read
>; CustomTitleBar.
>;
> When I went to compile I was surprised to discover that DB had defined
> ANOTHER CustomTitleBar class right in my SidePic Dialog class. Having
> two declarations of CustomTitleBar made the compiler unhappy and I
> didn't want to move my actual declaration into SidePic since I wanted
> all my windows to use my custom titlebar control. I futzed with a
> smattering of "#if 0"'s for a bit to disable this unwanted class but
> ultimately gave up and took the wxPanel out of SidePic from DB's point
> of view and inserted the CustomTitleBar manually after the controlled
> code block in CreateControls.
>
> So, while it was very nice to be able to design the titlebar within
> DB, I could wish that specifying an alternate class for a control or
> window would give you the option NOT creating the alternate class
> within the dialog class file itself. At the very least, if the class
> is based on wxPanel, and the Specified class is actually defined in
> DB, it would be cool if DB didn't create a second definition
>
> Regards,
> Royce
>
>
>
>;
>
>
>
> Yahoo! Groups Links
>
>
>
>;
>
>

--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD: www.anthemion.co.uk/dialogblocks

Messages in this topic (2) Reply (via web post) | Start a new topic

.