Problem in pull-down menus

[driessen]

Hello,

My customers are complaining that, after having used my application for some time, the pull-down menus aren't working anymore. If they make a choice to one of the items in a menu, nothing happens.

Then they quit my application and restart it again, everything is running just fine again.

Does anyone has any idea why this type of behaviour is happening?

Thanks a lot in advance for any help.

[Antonio Linares]

Michel,

Do you define the MENUITEMs the usual way or do you load their actions from a database, or use a macro for them ?

I mean the usual way as:
MENUITEM "test" ACTION Test()

Are you using a main MDI window ?

Does the menu fails with both the mouse and the keyboard ? Does your menu uses accelerators ?

Just guessing and thinking for a debugging plan on a next post...

[driessen]

Antonio,

My menuitems are indeed defined the usual way. It's all about the menues in my main window oWnd.

It is not the menu itself which is failing (maybe I wasn't clear about that). I can open the menu but the ACTION is not executed and just brings me back to my main window.

It has a behaviour like it is that one of another buffer is full. I hope you understand what I want to explain.

[Rick Lipkin]

Michael

I have had several instances where I am using a MDI window with a BuildMenu() menu bar with a Button Bar underneath.

I have noticed that if I create a MdiChild and create another BuildMenu() menu bar which over lays the MDI menu, when I close the MdiChild and control returns to the MDI, ocasionally none of the options on the button bar work nor do the pull down menus .. I have to close the application from the "X" in the corner.

I have noticed that if I do not create the second BuildMenu ( menu bar ) in my MdiCHild .. when control returns back to the MDI .. everything seems to work. Only when I create a second menu in a child do I see this behavior.

Rick Lipkin

[Antonio Linares]

Michel,

Is your main window MDI ?

Do you create pulldown menus for MDICHILD windows ?

[driessen]

Antonio,

My main window is the only window with pulldown menus. No other window nor dialog box has pulldown menus.

[Antonio Linares]

Michel,

Is it created as:

DEFINE WINDOW ... MDI

or without MDI ?

thanks

[driessen]

Antonio,

Without MDI.

[Antonio Linares]

Michel,

Could you post here or send me by email a screenshot of your main window ? thanks

[driessen]

Antonio,

I send you by private mail the screenshot you asked for.

I want to tell you another matter concerning this problem.

Could this code be the reason for the problem?

Code: Select all  Expand view

      BuildMenu() // building the oMenu
      oWnd:SetMenu(oMenu)
      oBar:End()
      BuildBar() // building the changed bar

I use this code quite a lot to change my menus and the buttonbar.

Thank you very much in advance.

[driessen]

Antonio,

I changed the code into :

Code: Select all  Expand view

      oMenu:End()
      DeleteObject(oMenu)
      Memory(-1)
      BuildMenu() // building the oMenu
      oWnd:SetMenu(oMenu)
      oBar:End()
      BuildBar() // building the changed bar

I have got the impression that the problem has dissappeared. Could that be the solution?

Thanks a lot.

[Enrico Maria Giordano]

Code: Select all  Expand view

DeleteObject(oMenu)

If oMenu contains a FWH TMenu class intance then you can't release a FWH object using DeleteObject() Windows API. It is only for Windows handles.

Code: Select all  Expand view

Memory(-1)

I remember this for 16 bit FW/Clipper not for 32 bit FWH/[x]Harbour.

EMG

[Antonio Linares]

Michel,

Try this way also:

Code: Select all  Expand view

    oMenu:End()
      BuildMenu() // building the oMenu
      oWnd:SetMenu(oMenu)
      oBar:End()
      BuildBar()

If the above works then it would mean that destroying a menu previously to create a new one could be related to get lower handles. I think the problem could be related to numbers too high that go out of a certain scope and are not properly processed. This is just a guess.

[Antonio Linares]

Another possibility is that if the previous menu was not getting destroyed, then the app could run out of (Windows) resources. Sort of a memory leak.

[driessen]

Thanks a lot to everybody for any help.