BUG: wxSmith generate an ID ANY to new menus.

[cfgnunes]

has a bug in build 6906,
the wxSmith generate an ID ANY to new menus.
when put an wxMenu.

Thanks!

[Jenna]

Can you please describe the steps to reproduce this issue.
And please tell us which OS you use and whether it's a self or prebuild version of C::B.

If I add wxMenu to a frame and add menu-items to it, wxSmith creates proper ID's with wxNewId().

[cacb]

Can you please describe the steps to reproduce this issue.
And please tell us which OS you use and whether it's a self or prebuild version of C::B.

If I add wxMenu to a frame and add menu-items to it, wxSmith creates proper ID's with wxNewId().

I have seen this bug. Unfortunately, I didn't report it at the time.

If my memory serves me, what happened was that editing the variable name in the properties area, caused the corresponding ID to automatically switch to wxID_ANY, causing a lot of havoc.

Sorry that this is a bit vague, but it is a real issue. This was WinXP and I don't build C::B myself.

[Jenna]

Confirmed, it does not happen if I revert the patch described here: http://forums.codeblocks.org/index.php/topic,12345.0.html
Committed to trunk in svn r6241.

But on linux, I can not even try it, because C::B crashes (nearly always) if I change the variable name (most likely) in wxPropGrid (wxBoolProperty::GetValueAsString(int)).
This might be related, because the "correction" should only be done for local variables, but is done always.
I will look into it, if I am back on my working system.

[Jenna]

The change to wxID_ANY is wanted (see here: http://forums.codeblocks.org/index.php/topic,12345.0.html for details), but only if an item is local (not member).

Due to an uninitialized bool value, the item is always recognized as local, even if the checkbox ("Is member") was initially set, so editing anything leads to a change to wxID_ANY.
(The initialization-issue is fixed in svn r6912.

In my opinion the behaviour is incorrect anyway, at least for wxMenuBar's and wxToolBar's items and maybe others, because they are allowed to be local, because after SetMenuBar or SetToolBar, they are not needed any  longer, but the use of wxID_ANY makes them useless.

One solution would be not to change the ID's of local items where it leads to errors (filter them by type).
The other (in my opinion better solution) would be to skip the autocorrection completely and partly revert svn r6241.
In my opinion it makes more sense to change the default ID for items that can not trigger events (like wxStatictext) to wxID_ANY.

If the user accidently changes the scope of any item with default name from member to local (and back) in the current implementation, he/she has to change the ID manually to make the item usable with events again. If the autochange is recognized at all, if not there will be hard to track down errors.


I will add a link to this thread on the older one, to discuss the problem.

[Jenna]

New thread started here: http://forums.codeblocks.org/index.php/topic,14028.0.html.

Any discussion should be made there.