Commit 6241 candidate to be partly reverted ?

[Jenna]

Because nobody has answered in one of the both threads below, I start a new one.

The bug described in the second thread (changing all default ID's of local declared controls to wxID_ANY) can be quite confusing and might not be recognized at first sight.
What's more it forces the developer to touch all ID's of local stored controls, that have events (annoying and time consuming).

http://forums.codeblocks.org/index.php/topic,12345.msg94192.html#msg94192
http://forums.codeblocks.org/index.php/topic,14003.msg94191.html#msg94191

[thomas]

That is about wxSmith only, right? So should Byo not be the one who decides, since he's probably the one who knows best?

EDIT: Though I see that he's not been reading the forum for 7 months

[MortenMacFly]

Because nobody has answered in one of the both threads below, I start a new one.

I wanted to try this myself because I had the same case as Loaden described many times in other projects. That's why I thought it is useful. However, for menus I usually define my own ID's and do not let them have auto-generated. If I got you right that this would be changed on the fly which is of course not what's intended. However, if I set an ID to be a member I usually explicitly want to use the ID. If it is not set to "member" then I personally do not use it at all. That's why the concept of Loaden's patch works well for me.

However, I see the point when it would not work and in fact changing "is member" multiple times is not what I did and if it causes hassle that that's not what we want.

So I would agree to filter by type, but would suggest to leave the types as an option, including "all" and "none". That would provide most flexibility, but also causes most change (I know).

[MortenMacFly]

That is about wxSmith only, right? So should Byo not be the one who decides, since he's probably the one who knows best?

Yes, but Byo has literally retired since ages, so I'm afraid the decision is up to us.

[Jenna]

For menuitems and at least tools in a toolbar it makes no sense to keep them as member, because the menubar or the toolbar owns them after they have been added to it.
And there is no need to use "own" Id's for them (even if I also prefer to have meaningful names), but it's not up to an IDE to force the user to use a special programming style.

[Jenna]

Here comes a simple patch, that only changes the ID, if the control is local and has no events (registered in wxSmith):

Code

--- codeblocks.trunk/src/plugins/contrib/wxSmith/wxwidgets/wxscorrector.cpp 
+++ codeblocks.trunk/src/plugins/contrib/wxSmith/wxwidgets/wxscorrector.cpp 
@@ -207,7 +207,8 @@
         }
     }
 
-    if ( Item->GetPropertiesFlags() & flLocal )
+    if ( (Item->GetPropertiesFlags() & flLocal) &&
+         ((Item->GetEvents().GetCount()) <= 0) )
     {
         wxString prefix = s_IdPrefix;
         prefix << Item->GetInfo().DefaultVarName.Upper();

This is most likley the simplest solution (but without additional configuration and therefore a little less flexibility).

[MortenMacFly]

Code

--- codeblocks.trunk/src/plugins/contrib/wxSmith/wxwidgets/wxscorrector.cpp 
+++ codeblocks.trunk/src/plugins/contrib/wxSmith/wxwidgets/wxscorrector.cpp 
@@ -207,7 +207,8 @@
         }
     }
 
-    if ( Item->GetPropertiesFlags() & flLocal )
+    if ( (Item->GetPropertiesFlags() & flLocal) &&
+         ((Item->GetEvents().GetCount()) <= 0) )
     {
         wxString prefix = s_IdPrefix;
         prefix << Item->GetInfo().DefaultVarName.Upper();

This is most likley the simplest solution (but without additional configuration and therefore a little less flexibility).

OK, I'll try. BTW: I would like to open an wxSmith branch to allow certain other extensions for testing. I've still a couple of controls for wxSmith not yet committed. However, the build systems for these is not tested at all and probably wrong. So I'll open a branch accordingly and this would be commit there, too... OK?

[Jenna]

BTW: I would like to open an wxSmith branch to allow certain other extensions for testing. I've still a couple of controls for wxSmith not yet committed. However, the build systems for these is not tested at all and probably wrong. So I'll open a branch accordingly and this would be commit there, too... OK?

Yes !

[MortenMacFly]

Yes !

branch is done, commit at will. I'll do the same whenever I find the time...

[Jenna]

It's (possibly) brought up by a user again: http://forums.codeblocks.org/index.php/topic,14178.msg95264.html#msg95264

What about commiting the fix I posted some posts above.

[MortenMacFly]

What about commiting the fix I posted some posts above.

Go ahead! In fact I had applied the patch since that day but forgot about it. However, it doesn't seem to hurt my "daily" use of wxSmith. So no objections. :-)

[Jenna]

What about commiting the fix I posted some posts above.

Go ahead! In fact I had applied the patch since that day but forgot about it. However, it doesn't seem to hurt my "daily" use of wxSmith. So no objections. :-)

Done in svn r6972 !

[vid512]

You can now input multiple "wxID_ANY", but you can't input multiple "-1" (even though first "-1" gets rightly fixed to wxID_ANY). I think it would be nice to save few keypressed with allowing "-1" even when it isn't the first one.

(using Codeblocks rev 7639 from jenslody repo on Ubuntu 11.10 32-bit w/ fluxbox)