BlueGriffon 1.8 key mappings get confused

[garretwilson]

I'm on Windows 7 Professional 64-bit. I want to map BlueGriffon's keys for certain elements:

1. I map the <code> button on the toolbar to Ctrl+Shift+C. This works. Yay! (Of course, I need to restart BlueGriffon; see Bug 673.)
2. I map the link button on the toolbar to Ctrl+L and restart BlueGriffon.
3. I select some text and hit Ctrl+L. Rather than bringing up the Link menu, it closes the currently opened document!
4. Even worse, now Ctrl+Z closes the currently opened document! Yes, that's right---even though apparently Ctrl+Z is still mapped to Edit>Undo!
5. If I go back and remove the Ctrl+L mapping, Ctrl+Z will still close the current document!!
6. I remove the Ctrl+Z mapping from Edit>Undo, and Ctrl+Z still closes the current document. (sigh)
7. I realize I had mapped Ctrl+F4 to the "close tab" functionality, so I remove that mapping. Finally my Ctrl+Z is mapped to Edit>Undo again.
8. I re-map Ctrl+F4 to "close tab", and finally I can close a tab with Ctrl+F4. My Ctrl+Z is still mapped to Edit>Undo. My Ctrl+Shift+C is still mapped to <code>. But my Ctrl+L doesn't bring up links.

So apparently just mapping Ctrl+L to the link button can corrupt the entire table! It somehow remaps Ctrl+Z, even when I un-map Ctrl+Z, and I have to remove the Ctrl+F4 mapping to be able to start remapping everything else.

This is reproducible. (I noted this issue before on the forum, but it was ignored.)

[garretwilson]

This reared its head today when I tried to map Ctrl+Shift+C to <code> on a different installation on Windows 10. Suddenly Ctrl+Z would close the tab. I had to unmap Ctrl+F4 again.

The whole key mapping system easily gets corrupted. And as I mentioned in Bug 673, it doesn't even save correctly. I'll copy that information here, since nobody looked into it on Bugzilla.

I'm trying to save my file. I hit <Ctrl+S>, like 98% of other applications in the world. My file doesn't change on disk.

No problem! I'll map <Ctrl+S> to the save menu! I go into Tools > Preferences and map <Ctrl+S> to File > Save. It accepts it. I close the dialog and try to save. Nothing happens. I go back into Tools > Preferences and my <Ctrl+S> mapping is no longer there.

BlueGriffon 1.8 is not accepting my mapping of <Ctrl+S> to File > Save on Windows 7 Professional 64-bit.

(...)

OK, this is very odd. Every time I would go out of preferences and go back in, my key assignments would be gone (and would not function). But after restarting BlueGriffon... there they all are.

Something strange going on about getting these to "take" without a restart.

Note that even after the changes "take", the corruption issue reported here still remains.

[garretwilson]

Here's yet another example. I wanted a keypress to enter <kbd>, so I went to preferences and went to the keyboard shortcuts to Toolbars > Encapsulate selection into an inline element. I added a keypress of Ctrl+Alt+K. Then I restarted BlueGriffon (as I mention above is required).

• My Ctrl+Alt+K keypress does not work.
• Even worse, my Ctrl+Alt+C, which had been mapped to <code> on the toolbar, no longer works and doesn't even appear in the keyboard shortcuts.
• To top it all off, the keyboard shortcuts doesn't even provide any selections under Toolbars > Encapsulate selection into an inline element anymore! Apparently the entire mapping has been corrupted!

It seems whatever do to map keys will corrupt the mapping. This has been reproduced on another machine with a clean install.

[maazl]

I think the problem is related to some corrupted entries in shortcuts.sqlite.

43      #emButton       shift,control   E
32      #imageButton    shift,control   I
13      #menu_BGpasteNoFormatting_cm    shift,control   INSERT
33      #linkButton     shift,control   L
26      #formatMenuPopup> :nth-child(14)        shift,control   Q

The critical line here is 13. I gues the key should be VK_INSERT rather than INSERT. If I remove this line other keys with modifiers shift,control start working again. If not than they match to the insert action.

I have no idea how this wrong entries get into the database. If I recreate the shortcut it is created correctly.
However, at the time I added the new entry other key bindings changed from VK_xxx to just xxx and the configuration is broken again. The shortcut editor seems to destroy valid key bindings for special keys on save unless they have just been created. So the origin of the bug is probably while reading the current bindings. Maybe someone disliked the VK_... in the view and removed it while reading which broke everything. ;-)

[...]

I guess this is the source of the problem: