Reassigned keyboard shortcuts disappear when switching builds

[scarphin]

I found this old topic here http://forums.codeblocks.org/index.php/topic,6562.0.html similar to my problem but I realized the cause to be the switching between builds. Like for example when I launch a custom build after say an official build or nightly, my shortcuts get reset. This is true in every combination of builds listed below, anybody else experiencing this?

OS: Win7 SP1
CB: 13.12, 16 Nov nightly, custom build with mingw-4.8.2_x64 & wxwidgets-3.0.0

[scarphin]

A further investigation revealed that the 'cbKeyBinder10.ini' isn't loaded when a different build is launched. I can say this because when a new build is launched and the reassigned shortcuts are lost, the 'cbKeyBinder10.ini' file at location 'appdata\romaing\codeblocks' contains the reassigned shortcuts and then when cb is closed, default shortcuts are saved onto this file. What may cause this, any ideas?

[oBFusCATed]

Do you have some steps to reproduce this?
For example run build xxx, assign these keys, run build yyyy.
I've seen this problem and I'm willing to fix it, because it is annoying!

[scarphin]

Steps to reproduce in my case:

1- Quit 'build x' which has custom key bindings working. After 'build x' quits 'cbKeyBinder10.ini' contains custom key bindings as expected.
2- Launch 'build y' and key bindings are reverted to default. During execution of 'build y', 'cbKeyBinder10.ini' still contains custom key bindings.
3- Quit 'build y' and default key bindings are saved to file 'cbKeyBinder10.ini'.

Step 2 is not always the case. Sometimes launching another build doesn't revert the bindings back to default but most of the time does.

More details if it may help, I'm not using the default shortcuts profile. I had created a new one to store my custom bindings and the 'cbKeyBinder10.ini' file after step 3 above contains my custom profile but with default key bindings. Below are the headers of the profiles in the 'everything-default' file:

Code

nSelProfile=1
[keyprof0]
desc=Our primary keyprofile
name=Primary

[keyprof1]
desc=Our primary keyprofile
name=scarphin

Should I post the whole file? Also should I mention that the bindings are NOT affected after consequent launches of the same build!

because it is annoying!

Very!!!

[oBFusCATed]

I need the values of x and y. So please try to remember then next time you switch versions.

[scarphin]

Well, x and y should be any value from the list in my first post but I think I found the problem and fortunately it's by my side. Being said the problem is when the shortcuts get saved by my custom build (mingw 4.8.2 64-bit, wx 3.0.0) an extra 'dash' is inserted between 'bind' and the number after it (only for some entries), like below:

Code

bind-31753-type4660=&View\\Status bar|Show/hide status bar|
bind-31752-type4660=&View\\Script console|Show/hide the script console|
bind-31750-type4660=&View\\Focus editor|Set focus on the active editor|
bind-31747-type4660=&View\\Switch tabs|Switch between open editor tabs|Ctrl-TAB|

The working file has the syntax:

Code

bind1019-type4660=View\\Status bar|Show/hide status bar|
bind1020-type4660=View\\Script console|Show/hide the script console|
bind1022-type4660=View\\Focus editor|Set focus on the active editor|
bind1025-type4660=View\\Switch tabs|Switch between open editor tabs|Ctrl-TAB|

And when cb tries to read that entries with an extra dash, I think it reverts them back to defaults and saves it like that. The reason why I thought switching any cb build caused the problem is because I was copying the already defected file over 'cbKeyBinder10.ini'. I can swear I had this problem before with the official builds though.

Btw should I report problems with my build (mingw, 64bit, wx 3.0.0) or does it have to be tdm, 32-bit, wx 2.8.12)?

[oBFusCATed]

Btw should I report problems with my build (mingw, 64bit, wx 3.0.0) or does it have to be tdm, 32-bit, wx 2.8.12)?

Generally running C::B compiled with wx3.0 is for people wishing to provide patches, nothing is guaranteed.
But if post the exact steps to reproduce the problems we could try to fix them. But please use one of the wx2.9/3.0 related topics.
This one is for something totally different.