Prev: localhost
Next: How to subclass an MFC window?
From: David Webber on 30 Jun 2010 13:45 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:e0maYnGGLHA.3732(a)TK2MSFTNGP02.phx.gbl... > "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message > news:eTNEZZGGLHA.5668(a)TK2MSFTNGP04.phx.gbl... >> The new MFC classes remember your accelerators in the registry. > > What a crappy design. Do they at least have a property that lets you > disable that crappy behavior? Not sure ---- yet :-) The LoadFrame() of the main window loads accelerators from the resources (as I think it always did) and then at some stage soon afterwards it overrides them with ones loaded from the registry. Rather than stopping it, I would like to get a look-in in between (reasons below). Research is in progress! > I presume they added this to allow user to edit accelerators. Yes. > Do they have a UI for that? Yes. You get a customisation property sheet - launched from a default command on the view menu, and from little drop-down arrows on customisable toolbars. One of its property pages allows you to add/remove/change accelerators. > Why don't they persist just the changed ones (which there aren't any since > you haven't edited them during the first run)? I guess its easier for them just to store the whole accelerator table in the registry without missing out the ones which are the same as they were in the rc file. In fact, all the routines for editing accelerator tables seem to end up with the bottom line of replacing the whole accelerator table. I have been experimenting with adding some accelerators computationally during program initialisation (reasons below). I have a first draft working. The procedure is schematically to define a set of accelerators I want ACCEL myAccel[ ] and then: 1. Get old accelerators with const HACCEL hAccelTableOld = pMainFrame->m_hAccelTable; 2. Copy into an array of ACCEL structures using ::CopyAcceleratorTable() to get ACCEL *pAccelOld pointing to an array of known size. 3. Create a new array pAccelNew, from merging pAccelOld and the supplied myAccel[ ] (more awkward than it looks) 4. Use one of the new classes: CKeyboardManager *pKBM = CWinAppEx->GetKeyboardManager(); pKBM->UpdateAccelTable( NULL, pAccelNew, nAccelCountNew, pMainFrame ); This last step, replaces the accelerator table in pMainFrame, and also handles the accelerator name on the menus (I've confirmed that) and toolbar tool-tips (I hope). And possibly in the customisation dialogue if I'm lucky. Anyway now, during initialisation, I can (programatically) add a new set accelerators to the ones loaded from the .rc file. I want to do this, after they are loaded from the rc, but before they're replaced with ones from the registry. Why? Well I'm still into shortcuts like "Ctrl+>" The > is Shift+. on my British keyboard, and there's no way I've discovered of defining that in a .rc file, and certainly no way of making sure it's Ctrl+> on all national keyboards. However that shortcut *can* be added from the customisation dialogue. And I think that defining an ACCEL structure and adding it myself programmatically on the fly during initialisation will work too. So now all I have to do is ask the keyboard drivers which virtual key code corresponds with > and than I can add it so that the accelerator Ctrl+> will work on everyone's keyboard. It's starting to look possible, :-) Then there is the small matter of it appearing as Ctrl+Shift+. on the menu, but it appears that there is a virtual function somewhere in the system which creates the text "Crtl+Shift+." from the ACCEL structure, and it looks like I might be able to override it so it says Ctrl+> This might seem like a small matter, but Mozart has *always* used these 'illegal' shortcuts (by means of my patent system which avoids accelerator tables altogether) and users are going to expect continuity. It looks like I can't integrate my own shortcut system with the 'feature pack classes' so the next attempt is to bend the accelerators to my will. It's a million to one chance but it might just work! Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm |