All widgets and windows should have a customizable constructor

[rossanoparis]

During an application coding, It is common to need customizable constructor for all kind of widgetd used.

This is good, but not enough, as I could need to customize my object constructor

Actually using wxUIEditor the programmer is not allowed to personalize objects creation, but it is a common habit instead.
Offen during widgets construction it is necessary to refer to objects or parameters shared among the application.
The class constructor represents the natural way to implement it

e.g. This is the actual code generated for a wxButton widget inherited from a CMyButton class

 m_btn = new CMyButton(panel, wxID_ANY, "MyButton");

The new featue should generate a code like this; where I'm free to insert my customization (CMyClass* pMyObject)

 m_btn = new CMyButton(panel, CMyClass* pMyObject, wxID_ANY, "MyButton");

The same for Panels, Trees, Lists, ... everything.

If you could extend the nice concept implemeted with this commit custom controls constructor, to all widgets construction, it would be woderful.
I think this is the last effort to really have a very clever RAD tool.

Best regards
Rossano

[KeyWorksRW]

Does it matter to you where the parameter(s) gets inserted? If it gets inserted as the first parameter, it will work with everything -- but if it's the second parameter as in your example, it won't work with any control that doesn't require a parameter (such as wxMenu).

My inclination would be to add it as a string property, with a check to add a trailing comma if needed. That gives the dev the option of adding as many parameters as they want.

[rossanoparis]

It doesn't matter the position where a customization is inserted, what is worth is a way to customize the constructor. This is a great feature to have for a RAD tool ... thank you

[KeyWorksRW]

Excellent, I will add support for it as the first possible parameter.

This will not make it into beta #1, but will definitely be in the release. I'm thinking I will probably do a second beta, and if so, it will be in that beta.

[KeyWorksRW]

tldr; version: I add a derived_parameters property to controls. I add a ctor_parameters property to forms, which is only available if use_derived_class is unchecked.

For controls, this is fairly straightforward to add. The only code generated is the constructor -- the header the dev supplied will contain the actual declaration.

For forms, it's the other way around -- the property can specify both the type and name of the parameter, but it is the dev's responsibility to create the actual constructor. That also means the constructor must always be 2-step construction, meaning that when the dev defines the constructor, it must call Create() to initialize the wxWidget form.

For example, assume a dialog form:

class MyDialog : public wxDialog
{
public:
    MyDialog(std::string_view some_string, int some_value);

    bool Create(wxWindow *parent, ...

};

In this case there would be no constructor that calls Create() like there is with a non-custom dialog. Also note that while MyDialog::Create() will be generated in the C++ source file, there will not be a constructor since I have no idea what to do with those custom parameters.

If the use_derived_class is unchecked, then the constructor is created by the dev after the generated comment blocks surrounding the generation of the MyDialog::Create() function. One could also uncheck the new generate_translation_unit and only the header file would be generated, leaving the dev to create the required constructor in their own translation unit. What would not work is double-inheritance. I.e., you could not have a custom base class which derives from MyDialog. In that scenario, there really isn't any point to custom parameters since if you doubly inherit, you can already provide whatever parameters you want, and in your own constructor, call the Base class constructor which in turn calls the wxWidgets constructor.

Currently, unless double-inheritance is used, the dev must provide their own initialization function, and creating the form requires calling that form. E.g.

class MyDialog : public wxDialog
{
public:
    MyDialog() {}
    void MyInitialize(wxWindow *parent, std::string_view some_string, int some_value);

    bool Create(wxWindow *parent, wxWindowID id = wxID_ANY,
        const wxString& title = wxEmptyString,
        const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize,
        long style = wxDEFAULT_DIALOG_STYLE, const wxString &name = wxDialogNameStr);

Creating the dialog would mean:

    MyDialog dlg;
    dlg.MyInitialize(some_parent, "foo", 44);
    dlg.ShowModal();  // assumes MyInitialize called Create(some_parent)

So here is my proposal. I add a ctor_parameters property. The dev fills that in with something like wxWindow *parent, std::string_view some_string, int some_value. I then generate:

class MyDialog : public wxDialog
{
public:
    MyDialog(wxWindow *parent, std::string_view some_string, int some_value);

    bool Create(wxWindow *parent, wxWindowID id = wxID_ANY,
        const wxString& title = wxEmptyString,
        const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize,
        long style = wxDEFAULT_DIALOG_STYLE, const wxString &name = wxDialogNameStr);

In the class C++ file, the dev must create the constructor:

MyDialog::MyDialog(wxWindow *parent, std::string_view some_string, int some_value)
{
    m_save_str = some_string;
    m_save_value = some_value;
    Create(parent);
}

The invoker creates an instance of the dialog using:

    MyDialog dlg(some_parent, "foo", 44);
    dlg.ShowModal();

Or, alternatively the ctor does not call wxDialog::Create() and instead the invoker must call dlg.Create(some_parent). That has the advantage of checking for an error return before calling ShowModal().

All of this can tie-in with the passing in a value to any derived controls, since the ctor for the form could initialize class members, and then pass those members as the parameters for the derived controls.

Of course this doesn't provide any advantage for double-inheritance. In that case it's simply a matter of MyDialog calling MyDialogBase::Create(). What it does do is make it easier to switch from double inheritance to single inheritance (modify the generated class rather than deriving a class from the base class). That fits in well with other changes I've been making so that it's easier to use single inheritance.

[rossanoparis]

Kind @KeyWorksRW thank you for sharing your proposal.

It seems functional, even though I need a clarification regarding the two member variables used in your example.
Perhaps I misunderstood your explanation.

Who creates m_save_str m_save_value, is it possible from the RAD tool ?
I ask that because, if the class MyDialog is the class edited by wxUIEditor, it would be necessary to create the two member in the header file:
std::string_view m_save_str; and int m_save_value;
Is that part of your proposal?

[KeyWorksRW]

You can add class member variables and functions to the generated header. This can be done either through the inserted_hdr_code property or the newer class_methods and class_methods properties.

[rossanoparis]

thank you