Hello,
We are working with fwh808 and after working several hours in our application, the menus stop working. They still appear, but if you click an item there happens nothing. Only closing the application will work, just minimizing won't help. This happens with normal menus and also with contextmenu. Has anyone experienced something similar and found a solution?
oWnd:SetMenu(oMenu)Regards,
Michel D.
Genk (Belgium)
I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773
Gilbert,
Class TMenuItem uses a CLASSDATA nInitId that holds a growing numeric value used to set a numeric ID to every menuitem.
As Michel has pointed, if you keep building menus, again and again, this CLASSDATA could reach an out of range value. To check it from your app, simply do MsgInfo( TMenuItem():New():nInitId )
If there are no running menus in your app, and prior to create a new menu, you could do:
TMenuItem():New():nInitId := 20000
to reset nInitId to its initial value
Antonio,
the problem indeed shows up if the ID of a menu item raises above 32.768 (2^15). In our application there is always running a menu, so it won't be possible to reset this value to 20.000. Is there another option? Maybe raising the value range for the ID's to a higher number?
Gilbert,
Once you build your main menu, please check whats the nInitID value and reset it to that value, not to 20000.
Otto,
If you are using a MDI main window and you create different puldown menus for each MDICHILD window, then everytime you create a menu for a MDICHILD window nInitID will be increasing its value, until 32768 and more. And then you may experience such problem, if nInitID is not reset.
Another case is building POPUP menus, again and again, as nInitID will be increased.
This may happen if the application is working for many days without stop.
Antonio,
Is there no way to automically decrement the counter when a menu is closed?
James
METHOD End() INLINE If( ::hBitmap != 0, DeleteObject( ::hBitmap ),), ::nInitId--Antonio Linares wrote:James,
We could do it and see if there are some side effects.
Gilbert, would you mind to test it and see how it goes ? thanks
This would be the required fix in Class TMenuItem:
METHOD End() INLINE If( ::hBitmap != 0, DeleteObject( ::hBitmap ),), ::nInitId--
Un Saludo
Carlos G.
FiveWin 25.12 + Harbour 3.2.0dev (r2502110321), BCC 7.7 Windows 11 Home
Carlos,
La idea es no usar IDs que ya esten en uso
The idea is not to use already in use IDs
Antonio,
>The idea is not to use already in use IDs
Ah, it seems this is not just a counter but rather a unique ID. Is that correct?
If so, then it would seem that decrementing the ID is going to have fatal effects. If the menu being ended is not the last one created then the a duplicate ID will be created when the next menu is created.
I think we would have to use an array that was CLASS DATA and then remove the ID of the menu being ended. Then whenever a new menu is created, the class could look in the array for an unused number, or if not found, then use the next available ID.
I think this would be quick because the array would never be longer than the number of menus in use.
Does this sound reasonable?
Regards,
James
James,
You are right, it is not a counter, it is a unique ID, but:
There can be different menuitems using the same IDs, as long as they don't belong to the same menu.
The IDs are used to send a WM_COMMAND with the ID as parameter to its container window or dialog.
Same as we can have controls with the same ID in different dialogs.
Can the number be checked and if it gets above a certain size then it can be reset back to 1.
Gale,
1 should not be used as it may conflict with a control ID that you may be using (i.e. a pushbutton OK)
Better use higher values
Anyhow the fix that I have proposed should work fine. Just waiting for Gilbert feedback 