User forums > Help
C::B loosing keyoard short cuts
tigerbeard:
I tried to use it, but I'm afraid, it not very a practicable approach.
I started on the CLI with
--- Code: --- codeblocks --personality=test1
--- End code ---
It did not use the default configs but Factory reset configs. In the config folder using several personality would be a huge number of totally disjunct config files, test1.xxxx, test2.xxxx, default.xxxxx. Before starting another new instance I would need to copy all relevant files to a new prefix and then start with that prefix.
If I would make an update to any of those configs there is no practical way to get that into all others.
BlueHazzard:
Could you not simply:
1) Start one CB instance
2) Fix your shortkeys
3) Save all, and close CB
4) Open as many instances you like
5) If you change some key bindings you have to do it in one single instance
I know this is somehow not "userfriendly" (and it bugs me a lot, because it happens to me every fu*** time) but i frankly do not know how other applications handle this (or how it should be handled). Here the last closed instance overwrites the previous settings and this is somehow logic....
tigerbeard:
--- Quote from: BlueHazzard on May 11, 2022, 08:35:04 am ---Could you not simply:
1) Start one CB instance
2) Fix your shortkeys
3) Save all, and close CB
4) Open as many instances you like
5) If you change some key bindings you have to do it in one single instance
--- End quote ---
I am not sure I can follow you. Obviously having 3 instances open, changing a shortkey in one and save and *then* close the others will overwrite the saved data. I think that is fine. But when I follow your procedure in step 4 all instances should open the same (updated) config file. All should have the new shortcut. Even when they all overwrite it the new shortcut should not be lost, should it?
And in practive, I can confirm this is working find 90% of the time. What troubles me is that after CB crashes I loose that abd I do not understand why. Thats what confuses me:
* when my apps crash they ususally do not have time to save a config file. I would expect that when C::B reads its config file I close them afterwards, so they are not damaged on a crash. So I am not sure how a crash can loose shortcuts
* I keep my shortcut config read only. Usually that works. Programs have the short cut. But after those crashes, they all loose it. How can that happen if the info is only stored in the keybinder file which is read only and where I verifiy that the setting is still there? So my guess is that the short cut is actually stored elsewhere. I did not find where, though.
* There is a similar mystery with the F2 Tab "tabs". I always re-sort them. Every time. In every instance. Not each time, but very often the sort order is lost. I have not idea where this is saved.
--- Quote from: BlueHazzard on May 11, 2022, 08:35:04 am ---I know this is somehow not "userfriendly" (and it bugs me a lot, because it happens to me every fu*** time) but i frankly do not know how other applications handle this (or how it should be handled). Here the last closed instance overwrites the previous settings and this is somehow logic....
--- End quote ---
I think there is an easy solution for this. At least it works fine in my own apps. This is how they work
* I have a menu entry "save config". It saves the config file(s) and nothing else. In CB the save concept is not fully clear to me. After a changeing a shortcut always I select "Save workspace" AND "Save all" beause I have no idea which one saves what.
* My options have a switch "Autosave Config on Close". When I de-select the option all config settings are read but never written unless I use "save config". That way any number of instances do always look and feel the same. And every time I change something config relevant, I save it.
In one app I put it a step further where I have the options "Save to NAS", "Load from NAS". Those use a configured file path from a central storage and update the local configs to and from the remote one. With this I can use the same config on any computer in the network but I also can work offline. Its easy to include a backup options and offer a "what did you change" line like a version control system.
* Actually I distinguish config files (with actual configuration data) and something I call a "Last Workspace" file. Basically this is a config file but it only contains data to get the user to the point where he left off last time, e.g. dialog positions, last open file lists, last loaded files etc. This file is saved always and it matters very little when its lost or overwritten by another instance. It just opens the App as the last I had closed.
Maybe there is a flaw somewhere, but I did not come across it yet.
Pecan:
Questions: @ tigerbeard
1) Are all running CBs the same CB version ?
2) Do all your running CBs run the same plugins. ?
3) Is the menu system exactly the same on all running CB's ?
I too have experienced missing keys after a CB crash, but have never been able to figure out what's happening.
I also experience scrambled key defs after running the debugger with the same personality. But this I understand because the layout and menu for the debuggee CB is different from the debugger CB. In that case the debuggee's keys would overwrite the debugger keys.
tigerbeard:
--- Quote from: Pecan on May 11, 2022, 10:51:25 pm ---1) Are all running CBs the same CB version ?
--- End quote ---
yes. There is only 1 installations
--- Quote from: Pecan on May 11, 2022, 10:51:25 pm ---2) Do all your running CBs run the same plugins. ?
--- End quote ---
yes.
--- Quote from: Pecan on May 11, 2022, 10:51:25 pm ---3) Is the menu system exactly the same on all running CB's ?
--- End quote ---
yes, I did not change the menu
--- Quote from: Pecan on May 11, 2022, 10:51:25 pm ---I too have experienced missing keys after a CB crash, but have never been able to figure out what's happening.
--- End quote ---
Thanks for confirming. Are you aware of any shortcut key storage beside "<CBconfig>/default.cbKeyBinder20.conf"?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version