User forums > Using Code::Blocks
wxSmith C&P in Releases 15.12 and 16.01
dmoore:
--- Quote from: Pecan on March 08, 2016, 03:59:21 pm ---
--- Quote from: tigerbeard on March 07, 2016, 03:45:29 pm ---Anyone please confirm that behaviour?
--- End quote ---
Confirmed. Cut and Paste are removed on CB restart.
This is at the request of Linux users (I forget why) and users who do not use the cbKeyBinder plugin, or who use the safe mode of CB, so they will have the use of Ctrl-C and Ctrl-V.
In the past, there were reports that binding copy/cut/paste keys cause interference with the OS.
I do not know why wxSmith does not see the global (or OS) key definitions.
--- End quote ---
The problem with the old way of doing cut/copy/paste through an app level accelerator is that it overrides the native cut/copy/paste behavior of widgets. E.g. you try to ctrl+c on a widget (e.g. the text box for incremental search) that has the focus, and instead you copy whatever happens to be selected in the editor. Not good.
I think the fix is that wxSmith needs to handle wxID_CUT, wxID_COPY, and wxID_PASTE to respond to the system cut/copy/paste signals.
tigerbeard:
--- Quote ---Confirmed. Cut and Paste are removed on CB restart.
--- End quote ---
Thanks.
--- Quote ---In the past, there were reports that binding copy/cut/paste keys cause interference with the OS.
--- End quote ---
Ok, interesting what restrictions can come up when trying to be multi-plattform.
--- Quote from: dmoore on March 08, 2016, 04:43:28 pm ---The problem with the old way of doing cut/copy/paste through an app level accelerator is that it overrides the native cut/copy/paste behavior of widgets. E.g. you try to ctrl+c on a widget (e.g. the text box for incremental search) that has the focus, and instead you copy whatever happens to be selected in the editor. Not good.
--- End quote ---
I am not sure how the accelerator exactly works, but wouldn't wxSmith in this case get the ctrl-c only when its active, i.e. I just clicked into the tree to highlight an item and wxSmith has focus. So another non-wxSmith widget should not have focus anyway?
Isn't C::B using wxWidgets for this? Then that would mean wxWidgets is behaving differntly between Win/Linux which would be a bad thing indeed.
--- Quote from: dmoore on March 08, 2016, 04:43:28 pm ---I think the fix is that wxSmith needs to handle wxID_CUT, wxID_COPY, and wxID_PASTE to respond to the system cut/copy/paste signals.
--- End quote ---
At least it provides the right handling, as it works fine after the changes during the same session. I understood the wxAccelerator so, that on a keybutton it sends a specific event, e.g. wxID_COPY. If thats what is happening wxSmith does exactly that. It does not, however, process the key presses "WXK_CONTROL" and the C key, which I think would be very bad if every plugin had to do that.
If that behaviour is be design, maybe it is less surprising to remove the Cut,Copy,Paste options in the key handling tool completely, or at least disable them with a text hint?
dmoore:
--- Quote from: tigerbeard on March 08, 2016, 06:38:43 pm ---At least it provides the right handling, as it works fine after the changes during the same session. I understood the wxAccelerator so, that on a keybutton it sends a specific event, e.g. wxID_COPY. If thats what is happening wxSmith does exactly that. It does not, however, process the key presses "WXK_CONTROL" and the C key, which I think would be very bad if every plugin had to do that.
If that behaviour is be design, maybe it is less surprising to remove the Cut,Copy,Paste options in the key handling tool completely, or at least disable them with a text hint?
--- End quote ---
Agree that plugins should not need to do their own keystroke processing. That said, I have attached an experimental patch connecting the wsSmith editor to wxID_CUT/COPY/PASTE event IDs and changing the Cut/Copy/Paste IDs used in the main menu of the App to those system default ones. This seems to work, but perhaps needs to be tweaked a bit.
dmoore:
Also as a gist here: https://gist.github.com/spillz/6a76ab3929da9285c05b
Btw, I also agree that the keyboard shortcuts should stay set if you set them. That seems to be a bug.
dmoore:
And one more comment:
--- Quote from: tigerbeard on March 08, 2016, 06:38:43 pm ---
--- Quote from: dmoore on March 08, 2016, 04:43:28 pm ---The problem with the old way of doing cut/copy/paste through an app level accelerator is that it overrides the native cut/copy/paste behavior of widgets. E.g. you try to ctrl+c on a widget (e.g. the text box for incremental search) that has the focus, and instead you copy whatever happens to be selected in the editor. Not good.
--- End quote ---
I am not sure how the accelerator exactly works, but wouldn't wxSmith in this case get the ctrl-c only when its active, i.e. I just clicked into the tree to highlight an item and wxSmith has focus. So another non-wxSmith widget should not have focus anyway?
Isn't C::B using wxWidgets for this? Then that would mean wxWidgets is behaving differntly between Win/Linux which would be a bad thing indeed.
--- End quote ---
The problem is not wxWidgets, but us. We are doing non-standard stuff with our menus (i.e. not using the standard IDs) and possibly with keybinder too. My hazy memory is that keybinder globally grabs the keystrokes that have been assigned in its config instead of remapping accelerators, but I could be wrong about that. I need to take a closer look.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version