who is able to succeed on that (on linux) ?
For me always like this :
- select something
- right click in order to select (Copy selection to clipboard) ==> nothing more selected
==> unable to copy something
Does not work here either, "Ctrl+C" also fails, but "Shift+Del" works.
It is cause by one of my commits, which changed the API. :(
Will check in a minute...
Hm, my commit is 8798 and I don't think it is the cause for the problem.
killerbot: do you have a working version?
It is your commit.
The issue is caused by sdk/loggers.cpp:189:
wxWindowUpdateLocker noUpdates(control);
The update-locker seems to clear the selection.
I think it's not needed there, because the function only reads the style and does not do anything critical.
Removing it, should not do any harm and makes the issue go away.
Yes, but you cannot tell from the commit itself.
Hm, isn't it safer to save the selection and then restore it (if there is API available)?
Quote from: oBFusCATed on May 12, 2013, 01:34:53 AM
Hm, my commit is 8798 and I don't think it is the cause for the problem.
killerbot: do you have a working version?
nope, I think this problem is already present for some long time
Quote from: oBFusCATed on May 12, 2013, 03:03:45 AM
Yes, but you cannot tell from the commit itself.
Hm, isn't it safer to save the selection and then restore it (if there is API available)?
It's not obvious, that wxWindowUpdateLocker clears the selection, it's also not documented and might be a bug in wxWidgets.
I did not test it with other windows or with wx from trunk.
Nevertheless, if this one line is removed it works as expected !
And I don't think we need to freeze the textcontrol to fetch it's style.
Why should it be safer ?
The update-locker was originally only used when the wrap-mode is changed and that is probably correct here to avoid flickering.
I don't know if it is really needed. In this case a slection will also be cleared, but this can probably be ignored or the selection can be stored and recreated if it is really wanted.
Maybe we should remove the Freeze()-Thaw() stuff in the loggers completely.
Even if it might flicker on linux. On windows they have no effect at all as far as I know.
But they always scroll the textcontrol to the first position.
We can possibly work around this by storing (and restoring) the scroll-position, but I don't know if it is really neeeded.
I don't see any issue, if we do not use Freeze() and Thaw() here.
Only tested on my fedora 18 system with gnome-shell.
Have you tried to build a larger project with lots of warnings to see what is the performance?
Quote from: oBFusCATed on May 12, 2013, 11:58:03 AM
Have you tried to build a larger project with lots of warnings to see what is the performance?
No.
We only have
Freeze() and
Thaw() in the
ListCtrlLogger::Append()-functions (if we remove the from
TextCtrlLogger::GetWrapMode() and
TextCtrlLogger::ToggleWrapMode() ).
I did not remove them from there,as they seem not to cause problems.
OK. Go on and commit if you like :)
the patch works. ;D
In order to make the user not wonder if he actually did copy something, can the "visual" selection be maintained, just like in the editor window when you right click ?