Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

wxSmith: Ambiguous Create() error if deriving from another class

(1/1)

MortenMacFly:
The story:
I am using wxSmith to design a wxDialog that also derives from wxThreadHelper.

Thus when I try to compile the dialog the compiler complains:

ContentDlg.cpp:99: error: reference to `Create' is ambiguous

C:/Devel/wxWidgets/include/wx/thread.h:643: error: candidates are: wxThreadError wxThreadHelper::Create(unsigned int)
C:/Devel/wxWidgets/include/wx/msw/dialog.h:50: error:                 bool wxDialog::Create(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int, const wxString&)

ContentDlg.cpp:99: error: `Create' was not declared in this scope

What to do? I can surely change the Create() call in the auto-generated code section to wxDialog::Create() but everytime I change the dialog design the error returns as the code is overwritten (obviously). Is there a "right" way to do it?

Byo...?!

byo:
Hmm, the Right way... no. But I have "stable" solution to put your own Create call instead of relying on the auto-generated one. The solution is quite simple (I've written about it somewhere but don't remember now where it was).

In the "extra code" of the root element (the wxDialog's one) put the closing block comment:

--- Code: --- */
--- End code ---

now in the source file add the desired Create call and opening block comment right before the initializing code block:


--- Code: ---
wxDialog::Create(...);
/*
//(*Initialize(SomeClass)
...

--- End code ---

and the original Create call is now disabled-by-commenting ;)

The only drawback is that it also comments declaration of local variables (used when item has "Is member" set to false) - so either all items must be members or you'll have to add them manually before the initializing code section.

After that you can freely work on the resource without the need to touch the code.

I know this is only a workaround. And from what I've observed, the customization of Create() call becomes more and more desired, so... it's on my TODO list now.

Hope the fix I've presented will be enough for some time, in few weeks I should start working on wxSmith harder than in past few months.

Regards
   BYO

MortenMacFly:

--- Quote from: byo on August 14, 2008, 12:40:46 am ---In the "extra code" of the root element (the wxDialog's one) put the closing block comment:

--- Code: --- */
--- End code ---
now in the source file add the desired Create call and opening block comment right before the initializing code block:

--- Code: ---wxDialog::Create(...);
/*
//(*Initialize(SomeClass)
...

--- End code ---

--- End quote ---
Hehe! Nice catch. This works indeed. Thanks!

BTW: Is there any particular reason *not* to always use the base class for the Create call in the code generation? Thus the generator would always produce wxFrame::Create(...) and/or wxDialog::Create(...)... etc?!

byo:

--- Quote from: MortenMacFly on August 14, 2008, 08:51:53 am ---BTW: Is there any particular reason *not* to always use the base class for the Create call in the code generation? Thus the generator would always produce wxFrame::Create(...) and/or wxDialog::Create(...)... etc?!

--- End quote ---

I thought about that but there are few reasons against such solution.
* The first one is that the base class doesn't have to be derived from wxDialog/wxFrame/wxPanel at all. It can simulate it's behavior.
* Second is that even if there's proper base class, the derived one could have some extra functionality added inside of the overridden Create() function.

Because of that I guess that amount of problems fixed would equal to amount of the introduced ones :). So currently I don't see any better solution than giving the ability to customize the Create() call.

Regards
   BYO

Navigation

[0] Message Index