Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.


I've run across a rather unusal problem. I changed the accelerators for some menu items on FRW_MAIN. For example, I changed the accelerator for "Cut Row" from Alt+X to Ctrl+Shift+X . Everything works fine except the menu text still displays Alt+X when FRW_MAIN runs (see images below).

The FRW_MAIN record in SYSREPOSWINEXES and SYSREPOSWINS correctly show the new accelerator text and new accelerator values. If I do "Save As " and run the form outside of Frameworks, the menu displays as expected. So I'm quessing that something in Frameworks is causing this.

I've always added menu items (and accelerators), but this is the first time I have tried to redefine an accelerator.

I'm hoping someone can point me in the right direction. Thanks.

New accelerators In Form Designer:

But when FrameWorks runs:


  • Hi Don,

    I am going to try and experiment with this to see if I can duplicate what you are experiencing. I would be very surprised if FrameWorks logic is causing this, but one can never be too sure.

    Are you using inheritance? Is it possible that you have one version of FRW_MAIN in the FRAMEWORKS application and another in the AQM application? I was wondering if perhaps you made your changes in the parent application and forgot to bring that into the child application.
  • Don,

    My first pass at testing this proved inconclusive. That is, my menu accelerator changed as one would expect. Now all I did was modify my Edit menu to have a 'Cut Row' item and I first used Alt+X as the accelerator and then changed it to Ctrl+Shift+X. Obviously my form doesn't have everything your form does.

    This really makes me want to pursue a more logical answer. You said that when you run this form outside of FrameWorks the menu shows up as expected. I'm not sure what you mean by that. How do you run FRW_MAIN (or a copy of it) outside of FrameWorks?
  • Hi Don,

    To answer your first question, there is no inheritance. However, I had a form named FRW_MAIN_TEST in my application. I didn't think this should be an issue, but just to be safe I deleted it. As expected this had no effect.

    When I save FRW_MAIN as RS_MAIN, then run it in Form Designer, the menu displays as expected. This seems to imply that the form is not corrupted.

    I have since discovered that if I add an accelerator to an existing menu item, that new accelerator does not display at all when FRW_MAIN is run, but it executes just fine.

    I'm also pretty sure this problem does not manifest itself on stand alone windows that are run in FrameWorks with their own menus. Since the MDI children have no menus, I guess what I'm saying is that this issue, as far as I can tell, is specific to FRW_MAIN. Can it in any way be related to FrameWorks security system?

    What I don't under stand is where the bad text, for example "alt+X" is coming from. If I do a search of that text it does not show up on anything related to FRW_MAIN, nor does the numeric accelerator value associated with "alt+X".
  • Don,

    I'm glad we are both perplexed.

    FrameWorks does manipulate menu items based on security settings. However, all it does is use the Windows API and Send_Message function to delete menu items. It would make more sense to me, for instance, if the accelerators got misaligned. Displaying old accelerators is a puzzle.

    Can you check your Verify_User_Access() subroutine and tell me the date of the last comment in the header block?
  • The date for Verify_User_Access is 11/14/05.

    Another thought. OI 9.1 and later use field 12 of SYSREPOSMENUCONTEXT to store the name of the context menu bmp. This conflicted with Frameworks use of field 12 for CM_STYLE_FUNCTION$ and CM_DISABLED_FUNCTION$ which caused Frameworks context menus to display incorrectly. I had to change the FrameWorks context menu equates to fix this problem. Since the same thing was done by OI to standard menus, was there anything that had to be done in FrameWorks is this repect?
  • Don,

    We've done a fair amount of work in Verify_User_Access to resolve the way menus are handled. I think some of this had to do with OI 9.x. However, there have been enough other changes that I don't think replacing your code with the latest is advisable. I would like to send you the latest version (via email) and then suggest that you compare the two. I'm sure you can update major portions of your version and with any good fortune it might fix the problem.

    Can you send me the changes you made to resolve the new menu structures? You can send that via email. I would like to see if we have already dealt with this. I don't recall seeing any problems with the Context Menu Manager in this regard.

  • Don,

    Comparing the new code would definitely help. Thanks.

    The Context_Menu_Equates changes are on the way.

  • I found the problem. There was a menu overlay for FRW_MAIN in the SYSREPOSLANGUAGE file. This was overriding the display of menu text that I had changed. I'm not sure how this record gets created. I have never used OpenInsight's foreign language capabilites, but apparently OpenInsight created an English "foreign language" for me.

    Well, mystery solved. Chalk this one up to OpenInsight.
  • Well, great detective work Sherlock. Thank you for responding back as I'm sure this will be something that will surprise others down the road.

    FrameWorks FTW! :-)
Sign In or Register to comment.