The geretated enums for windows and controls should be customizable

[rossanoparis]

I try to explain my self.
We must consider the scenario described with the following sketch.

In this scenario my aim is to catch wxButton events which are defined on three different wxPanel, using a unique function defined in their parent class.
Actually this is not permitted as windows IDs are always declared in this way:

PANEL1

enum
{
    BUTTON1 = wxID_HIGHEST + 1
};

PANEL2

enum
{
    BUTTON2 = wxID_HIGHEST + 1
};

PANEL3

enum

{
    BUTTON3 = wxID_HIGHEST + 1
};

Considering to use a single function in order to catch events from those buttons is not achievable, as the control ID has got the same value for all three buttons.
Of course there are different way to work out this kind of issue, alas all of them require to write uselessly code.
Try to imagine instead of having three buttons we have tens of them.
Anyway the natural way to solve it is to define different IDs values instead of writing code which seems a work arounf and not a linear approach.

Best regards
Rossano

[KeyWorksRW]

My inclination would be to add a unique_enum_values checkbox to the Project properties. If checked, then code generation would ensure that all generated forms have unique enumerated values. E.g.:

class FirstPanel
{
    enum
    {
        BUTTON = wxID_HIGHEST + 1,
        EDIT_CTRL,
        CHECKBOX
    };

class SecondPanel
{
    enum
    {
        BUTTON = wxID_HIGHEST + 4,
        LISTBOX
    };

class ThirdPanel
{
    enum
    {
        BUTTON = wxID_HIGHEST + 6,
    };

As long as you used a single project for all the forms, and unique_enum_values was checked, then all generated enums for all classes would be unique across the entire project. The handler function would be something like:

void ButtonHandler(int btn_id)
{
    switch (btn_id)
    {
        case FirstPanel::BUTTON:
            doSomething();
            break;

        case SecondPanel::BUTTON:
            doSomething();
            break;

The source code for the handler function would require an #include for every class's header file, though I would assume in most cases you'd need to do that anyway in order to access other controls/windows within the panel.

[rossanoparis]

Thank you @KeyWorksRW

Excuse me, I think your approach has got a lack of vision. In case of a monolithic project it could work, but in case of projects which depends on other libraries or shared code, it is affected by the same probably issue.
As I see it, if you could look at your well thougth RAD tool as a tool able to handle big projects with many GUI shared among them, the only solution is to thread objects IDs in their "natural" way, you should let the user decide how to number windows and widgets IDs.
Believe me, any try to automate windows IDs numbering, can lead a developer to find a work around in many circumstances, and this thing should be avoided.
The main attitude of a RAD tool is to help the developer writing code as "linear" as possible in all circustamces even for developer which are involved developing big projects not only small application.
Any deviation from this approach could be limiting for your project.

Regards
Rossano

[KeyWorksRW]

I'm planning on adding a per-form property that allows you to set the initial value, but I would like to also add methods that are less error-prone for someone's project, especially in a case where there are multiple people working on that project. The issue with manually adding the initial id, is that you cannot reliably predict the order that the enums will be generated. That means you absolutely must:

• make sure that your initial value will never fall within the range of another class's enum range
• ensure that every class has a unique initial enum value.

Both of those are risky for a long-running project where maintenance by someone less familiar with the code can be a problem. It also requires coordination between devs if there are multiple people working on the project. Letting the RAD tool create unique id values avoids both of those problems, but only if the entire UI is contained within a project. As you noted, that is not always going to be the case, hence the need for setting that initial value.

The other thing I was thinking about adding is special handling of an id when a '=' char is part of the id. For example, say the user specified an id of myid=100. Instead of adding this to the enumeration list, wxUE would instead create (within the class declaration):

    static const int myid=100;

That allows you to ensure that the id has an exact value, rather than relying on the initial enum id plus whatever offset due to where your id got generated in the enum list.

All of this would give you four different approaches to an id's value:

1. have the id value generated automatically (what happens now)
2. have the id value be unique for every generated class in the current project file (new)
3. specify the initial starting value of the enumeration list (new)
4. specify the exact value of the id (new)

[rossanoparis]

Once again thank you @KeyWorksRW, your attitude to listen to proposals is much remarkable.

Indeed you are correct, it's up to the "project manager" handle such kind of coordination among developers, in order to keep a solution tidy and "problems free".
Several things must be taken in consideration approaching a large solution composed by several applications, IDs numbering it's only one of them.
Below I describe the way I normally refer to, regarding the IDs numbering.
Generally speaking, we can divide a solution using three levels, or contexts.
The lower is the level the less is the IDs required, because of its level nature, the highest consume of IDs it is represented by the context number 2, but at that level the developer is free to use any ID above the last offset applyed, there are no any risk of IDs "overlapping" among applications.
Try to imagine how difficult could be to maintain a solution below described, without a RAD tool able to work with single projects organized using folders; tens or even hundreds of UI projects should be used instead, indeed a big mess ...

Your proposal would be very welcome and appreciated, especially the idea to use constants instead of enums
I think you got the point.

Nowadays, in my opinion, there is only a RAD tool able to handle large projects, it is "DialogBlocks"
Unfortunately it is out of date and not maintained anymore, but regarding the IDs management still it is the best as it permits to define and redefine IDs offset and even prefix and postfix for IDs naming.
If you could really merge your approach with its approach it could represent the best result; indeed it could.

[KeyWorksRW]

By any chance do you have an existing reasonably large DialogBlocks project file that you could either point me to on the web or attach a zip file here? I've found and used active project files for the other RAD tools, but I never found a good reference version for DialogBlocks. That leaves me guessing as to how it's used, and since I don't use it myself, I never noticed the way they handled ids. I've been experimenting with their prefix/suffix, but I have yet to get it add those to any new ids.

It probably makes sense if I add a custom editor as an option for the id property. When chosen, wxUE would display a dialog giving a variety of choices of how to create the id. I suspect most people don't even realize that the existing property control has an auto-complete for all wxWidgets ids -- adding that to a dialog would make it a lot easier to discover. You could then choose between stock id, enumerated id, fixed id (static const int), fixed value, a choice of prefixes/suffixes (i.e., support more than one prefix/suffix), etc. You'd still be able to simply edit it directly in the property box, but this would make it easier to discover all of the options that are actually available for ids.

[rossanoparis]

Kind @KeyWorksRW here you are

I don't think you need to waste time with DialogBlocks as I've already said it's very out of date; however it was well thought to handle large projects since the beginning.
Despite this, I can't wait to get rid off such tool because it generates a very old style code using only #defines, plus other deprecated approaches and it is completely detach from wxWidgets evolution.

DialogBLocks C++ generations options (per class)

DialogBLocks download
DialogBlock download

DialogBLocks project
( You must buy a licence in order to handle such kind of project, perhaps without a licence it permits to read it only )
manager.zip

I rekon with the modification you are going to implement regarding IDs plus the motifications you've already implemented (generation of single files for each class, folders to handle large projects, two-step construction, constants to handle wxWindows attributes, parametric constructurs for custom controls, etc ...)
You should emphasize such kind of features, no one is able to offer them nowadays with other RAD tools I've seen.
You are really very close to offer an up to date RAD tool with real powerful features.
I can't wait for a new release with all the new features implemented, at that time I'll be able to get rid off DialogBlocks and I could plan to use your RAD tool, which I can't use because of the missing features you are implementing ...
I'm using wxFormBuilder, but again, it is lack of many features useful to handle large projects in a linear way.

Actually in our projects we are using a mix of RAD tools DialogBLocks and wxFormBuilder.
Indeed it is a bad situation which is starting to be unsustainable, we need to choose only one RAD tool to operate with.
Your tool is really the one able to perform in a professional environment, please don't give up! :)

If you find my suggestions and proposals interesting and reasonable, I'm here to help in this way.
If you could provide a beta version with the last modifications I could certanly plan a test in order to confirm the feasibility of our projects porting.
During those tests perhaps some other suggestions could arise.

Best regards
Rossano

[KeyWorksRW]

Issue ##984 created for enhancing ids per this discussion.

[KeyWorksRW]

The ID Editor is now in place and working. However, there are a few things about the ID Editor dialog that are potentially confusing. These will make more sense once the beta is available and you can actually interact with the dialog. I'm adding them to this discussion because except for 4, I don't currently have any ideas for resolving the potential confusion.

1. If you specify a wxWidgets stock ID, you will be shown the stock label and if available, the stock help text. However, currently these do not override any existing label or help text. We can't automatically override them, because the user might want their own text.

2. You cannot edit the project list of prefixes and suffixes from the dialog. Editing those from the dialog would be very complicated, since the changes to them need to be added to the Undo stack separately so that the user doesn't undo those changes by undoing the id change. It also gets complicated if the dialog is cancelled, or the prefixes/suffixes are re-edited within the dialog.

3. The hint for the value is "wxID_HIGHEST + 1" -- but you have to type in that full value if you want to use it (since it's just a hint).

4. Currently, there is no check to see if the value you use has already been used in the dialog. There's also no way to automatically update the value if it is numerical (or ends with a numerical value). See issue Handle duplicate custom id value in ID Editor dialog #1000

[rossanoparis]

Kind @KeyWorksRW

Excuse me, but I didn't understand the way you have taken.
Regarding the previous posts, they were related to your enquiry concerning how DialogBlock works.
But, as I wrote, you shouldn't consider it, as it is out of date ...

I reckon for your RAD tool, it is necessary a kind of parameterization based on which the user can select how window controls IDs will be generated.
It is not necessary a dialog to reassign such IDs

Here is my idea ...

Genetated code for: enums && Auto increment

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 1,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

Genetated code for: enums && Auto increment && custom starting ID

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 10000,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

Genetated code for: enums && custom ID

    enum
    {
        MY_CTRL_ID1 = 10000,
        MY_CTRL_ID2 = 10101,
        MY_CTRL_ID3 = 10205,
        ....
    };

Genetated code for: constants && Auto increment

   const int  MY_CTRL_ID1 = wxID_HIGHEST + 1;
   const int  MY_CTRL_ID2 = MY_CTRL_ID1 + 1;
   const int  MY_CTRL_ID3 = MY_CTRL_ID2 + 1;
   ....

Genetated code for: constants && Auto increment && custom starting ID

   const int  MY_CTRL_ID1 = wxID_HIGHEST + 10000;
   const int  MY_CTRL_ID2 = MY_CTRL_ID1 + 1;
   const int  MY_CTRL_ID3 = MY_CTRL_ID2 + 1;
   ....

Genetated code for: constants && custom starting ID

   const int  MY_CTRL_ID1 = 10500;
   const int  MY_CTRL_ID2 = 11000;
   const int  MY_CTRL_ID3 = 10701;
   ....

[KeyWorksRW]

The dialog is in addition to what has already been implemented for the next version. It shows up to the right of the property as a standard property-grid button. It doesn't add any additional functionality to code generation, it's just a way to make it easier to set the id property.

The ability to set the initial enumerated value is in place. Assigning an id to a value results in it being added to the header file as a const int value. Currently, that means ids where no value is specified, get added to the enum list, and those with a value get added as a separate list of const int values.

The following from your list are now possible:

---

Generated code for: enums && Auto increment

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 1,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

Generated code for: enums && Auto increment && custom starting ID

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 10000,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

Generated code for: constants && custom starting ID

   const int  MY_CTRL_ID1 = 10500;
   const int  MY_CTRL_ID2 = 11000;
   const int  MY_CTRL_ID3 = 10701;
   ....

---

I have questions for you about the other two:

---

Generated code for: enums && custom ID

    enum
    {
        MY_CTRL_ID1 = 10000,
        MY_CTRL_ID2 = 10101,
        MY_CTRL_ID3 = 10205,
        ....
    };

While the code is valid, it's an unusual use of an enum -- at least from what I've read, it's considered a better coding practice to use the const int assignment rather than assiging each value in an enum. Is there a particular reason you would like this option?

Currently if you added an id with MY_CTRL_ID2 = 10101 it would be generated as const int MY_CTRL_ID2 = 10101;. If you then added MY_CTRL_ID3 but did not assign it a value, it would be added to the enum so you would get:

    enum
    {
        MY_CTRL_ID1 = 10000,
        MY_CTRL_ID3,
        ....
    };

    const int MY_CTRL_ID2 = 10101;

---

Generated code for: constants && Auto increment && custom starting ID

   const int  MY_CTRL_ID1 = wxID_HIGHEST + 10000;
   const int  MY_CTRL_ID2 = MY_CTRL_ID1 + 1;
   const int  MY_CTRL_ID3 = MY_CTRL_ID2 + 1;
   ....

So no enum at all, just use const int for everything whether a value is assigned or not? That would still mean that specifying MY_CTRL_ID2 = 10101 for an id would generate:

   const int  MY_CTRL_ID1 = wxID_HIGHEST + 10000;
   const int  MY_CTRL_ID2 = 10101;
   const int  MY_CTRL_ID3 = MY_CTRL_ID2 + 1;
   ....

[rossanoparis]

If it will be possible to obtain the code below in a single header, I think you did a great job.
You can skip other cases I described, as they are not useful at all.

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 1,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

   const int  OTHER_CTRL_ID1 = 10500;
   const int  OTHER_CTRL_ID2 = 11000;
   const int  OTHER_CTRL_ID3 = 10701;
   ....

or

    enum
    {
        MY_CTRL_ID1 = wxID_HIGHEST + 10000,
        MY_CTRL_ID2,
        MY_CTRL_ID3,
        ....
    };

   const int  OTHER_CTRL_ID1 = 10500;
   const int  OTHER_CTRL_ID2 = 11000;
   const int  OTHER_CTRL_ID3 = 10701;
   ....

[KeyWorksRW]

Yes, you can get exactly that with the current implementation.

I'm still on track for a beta around the end of this month so that you can try it out.

[KeyWorksRW]

Beta 1.1.1 is now available and includes this change.

[rossanoparis]

kind @KeyWorksRW, I couldn't wait to test this feature ...
let me express my best compliment regarding the way you followed in order to implement it.
It is really versatile and it is able to cover every project needs. Well done!

I have a clarification to ask, regarding the prefixes management.
I've noticed that in case of a prefix renaming, the old one remains as it was generated, I would have expected an "automatic" renaming, it is necessary modify manually all the IDs instead.

... let's say, it's not a big deal, it's a behavior that must be known.

[KeyWorksRW]

I'd be concerned about an automatic renaming changing the wrong thing, but adding the functionality to do this with more control over what is and is not changed would be useful. It also ties into another change I'd been thinking about which is a way to automatically add prefixes and suffixes to all custom IDs, but with the ability to limit that change to specific forms, or all the forms in a folder. I've created issue #1017 as a way to deal with both renaming and automatic naming.

[rossanoparis]

thank you

[KeyWorksRW]

The 7/11 daily build should contain a new menu command on the Tools menu that will let you edit multiple custom ids at once (removing or setting prefixes and suffixes). Modifications can be limited to a single form, all the forms in a folder or every form in the entire project or anything in between. I'm hoping that's not going to be overly confusing. I tried several iterations of the UI before coming up with the current one, but I'm still a bit concerned about someone using it for the first time to be overly confused about how it works. If you have the time and are comfortable grabbing any daily build from 7/11 on, I would be greatly appreciative of your feedback.

[rossanoparis]

Thank you @KeyWorksRW

I have tried it and I didn't find it confusing or other.
Perhaps, if I were you, I'd work a bit on window layout

Here is my proposal

The "OK" button should be removed and perhaps even the "Preview Changes" button could be removed; using list events, text controls events and combo events you should be able to update "Preview Changes" without a user interaction.

[KeyWorksRW]

Thanks for checking this out! I like the grouping of the prefixes and suffixes vertically instead of horizontally, and will make that change.

The reason for the button is that it allows you to make multiple changes to different collections of forms without having to open up the dialog box again. My thinking was that it would be really annoying if you had a dozen or so folders, and wanted to set a different prefix for all the forms in each folder. It would be annoying to have to re-open that dialog a dozen times. What I'm not sure is how likely that scenario would be. From what you've told me previously, you have a lot of custom ids in your project(s). Which would you prefer -- running the dialog once to make multiple different prefix/suffix changes in different groups, or run the dialog multiple times if needed?

The reason for the Preview button is that the changes you make in the 4 text boxes don't show up unless you press enter. I didn't want to refresh that grid every time you typed a character (I suspect that would cause a lot of flicker if one was trying to edit the entire project with hundreds of custom ids). The preview button means you can tab or click and make all the prefix/suffix changes you want without the grid changing until you press the Preview button (or the Commit button if you don't care about previewing the changes).

I have redesigned the layout of the dialog -- it should be in tonight's daily build.

[rossanoparis]

Thanks for checking this out! I like the grouping of the prefixes and suffixes vertically instead of horizontally, and will make that change.

Thank you

The reason for the button is that it allows you to make multiple changes to different collections of forms without having to open up the dialog box again. My thinking was that it would be really annoying if you had a dozen or so folders, and wanted to set a different prefix for all the forms in each folder. It would be annoying to have to re-open that dialog a dozen times. What I'm not sure is how likely that scenario would be. From what you've told me previously, you have a lot of custom ids in your project(s). Which would you prefer -- running the dialog once to make multiple different prefix/suffix changes in different groups, or run the dialog multiple times if needed?

I understand your doubt, any way I'd prefer to reopen multiple times if needed, as it is very rare to adjust IDs one time for the entire project

The reason for the Preview button is that the changes you make in the 4 text boxes don't show up unless you press enter. I didn't want to refresh that grid every time you typed a character (I suspect that would cause a lot of flicker if one was trying to edit the entire project with hundreds of custom ids). The preview button means you can tab or click and make all the prefix/suffix changes you want without the grid changing until you press the Preview button (or the Commit button if you don't care about previewing the changes).

Yes, you are right about it, I agree with you that buttun must be kept

I have redesigned the layout of the dialog -- it should be in tonight's daily build.

I'll take a look

[rossanoparis]

Kind @KeyWorksRW I think you did an excellent job.
Indeed you can release that features as they are, I mean "Preview button" and "Commit Change"

[KeyWorksRW]

This is the last critical item that's going into the 1.1.2 release. Initially, wxWidgets 3.2.3 was going to be released on July 7th, but that's been delayed. I'd like to pick that up if possible, but if it gets delayed past this coming weekend then I'll post a release without it.

…

On Tue, Jul 11, 2023 at 11:32 PM ROSSANO PARIS ***@***.***> wrote: Kind @KeyWorksRW <https://github.com/KeyWorksRW> I think you did an excellent job. Indeed you can release that features as they are, I mean "Preview button" and "Commit Change" — Reply to this email directly, view it on GitHub <#982 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKGN3UZ7OEYDIJRQCJPT363XPZAIPANCNFSM6AAAAAAXQYS3PI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rossanoparis]

It sound good, but please don't rush for me, perhaps it would make sense waiting for the next wx release ...
A part this, I'd have other suggestions regarding the application layout, may I open another "discussion" about it ?

[KeyWorksRW]

You are always welcome to open a discussion about anything to do with wxUiEditor, whether it be layout, code generation, or anything else. While I may not implement every suggestion you make, I will definitely consider any suggestion.

…

On Wed, Jul 12, 2023 at 6:48 AM ROSSANO PARIS ***@***.***> wrote: It sound good, but please don't rush for me, perhaps it would make sense waiting for the next wx release ... A part this, I'd have ather suggestions regarding the application layout, may I open another "discussion" about it ? — Reply to this email directly, view it on GitHub <#982 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKGN3UZO4EJRAT2GWNHAXPTXP2TL5ANCNFSM6AAAAAAXQYS3PI> . You are receiving this because you were mentioned.Message ID: ***@***.***>