Re: Switch Bug
- Posted by ghaberek (admin) Jun 06, 2011
- 1634 views
I'm not sure of the reason but if you define new_id's for the built in wxID_ constants, things work as expected. I tried the following:
wxID_CUSTOM1 = new_id(), wxID_NEW = new_id(), wxID_OPEN = new_id(), wxID_SAVE = new_id(), wxID_SAVEAS = new_id(), wxID_PRINT_SETUP = new_id(), wxID_PRINT = new_id(), wxID_EXIT = new_id(), ......
The bug here seems to pertain to the values of the constants. The built-in IDs start numbering from 5000, whereas new_id() starts at 100. When you do this, you get wxID_CUSTOM1 = 100, wxID_NEW = 101, wxID_OPEN = 102, etc. I redefined the constants with their original values (see below) and got the same result: everything jumped to case wxID_EXIT then.
constant wxID_CUSTOM1 = new_id(), wxID_NEW = 5002, wxID_OPEN = 5000, wxID_SAVE = 5003, wxID_SAVEAS = 5004, wxID_PRINT_SETUP = 5011, wxID_PRINT = 5010, wxID_EXIT = 5006
Also, probably not necessary but I passed in the Menu id's to the set_event_handler...
constant menuids = {wxID_NEW,wxID_OPEN,wxID_SAVE,wxID_SAVEAS,wxID_PRINT_SETUP,wxID_PRINT,wxID_CUSTOM1,wxID_EXIT} set_event_handler( mnuFile, menuids, wxEVT_COMMAND_MENU_SELECTED, routine_id("menu_handler") )
It sorta defeats the purpose of using the built in id's, but it seems to work!
Hope this helps,
Ira
That doesn't seem to have any effect. I typically do this when I group event handlers together, like file_menu_handler(), edit_menu_handler(), etc.
My reaction was that it should be
case mnuFile_New then
not
case wxID_NEW then
etc
HTH,
Pete
Nope, this is correct behavior for wxEuphoria. For menu items especially, the "this" object is always the main wxFrame, and the "id" object changes with each event that occurs. This behavior comes from wxWidgets, which uses ID numbers to trigger events rather than object handles. This way, multiple objects can trigger the same event, like the "File > New" menu item and the "New" toolbar button. It makes thin a helluva lot easier.
-Greg
