Clicking on 'other' buffer scroll bar causes buffer to be sorted

[rgknowles]

I've loaded two large UNICODE files (one 97MB, 480K lines, the other 27MB, 160K lines) into SlickEdit and tiled them horizontally.
With one buffer in focus, use the mouse to click on the *other* buffer's vertical scroll bar (any part: thumb, page scoll area, or single line scroll arrows).  Click on it again.  The UI will freeze while the buffer gets sorted (with duplicates eliminated) and marked as modified (use UNDO to recover).  This is 100% reproducible for me when I use large files and attempt to scroll the buffer that is not in focus.  It is quite noticeable since it takes 30 seconds or so to sort (and then another to UNDO).
According to the key bindings dialog, I have no keys or mouse actions) bound to any of the sort commands.
Happens on V11 (and patches), did not happen on V9.

[ScottW, VP of Dev]

I just tried to reproduce this and I couldn't. Can you paste in the information from the Help > About SlickEdit screen? Also, could you attach a short excerpt from each file? I'm wondering if the contents are making a difference somehow.

You should also try to reproduce this using a default SlickEdit configuration. First backup your SlickEdit config directory! Sorry for yelling, but this is critical so that you can restore it later. Then delete the contents--not the directory--just the contents of the versioned subdirectory, which should be named "11.0.2". Be sure you are not running SlickEdit while you do all this.

Then start SlickEdit. it should prompt you for an emulation and ask to tag your files. If it doesn't do this, it's not creating a default config. Now try to reproduce the problem. If you can't, then something in your config got whacked, which means your best bet is to reconfigure this new config to match your old. If you are still able to reproduce this problem, then your config has nothing to do with it and you can copy everything back to the 11.0.2 subdirectory.

This is the weirdest one I've heard all week, but we'll do our best to help you resolve it.

--Scott

[Clark]

(rgknowles)  If you sure you can reproduce this problem in V11.0.2, contact support about this problem.  I will have support send you a new "vsapi.dll" to try that could address this issue.  Use my name when you contact support so they will know to talk to me.

[rgknowles]

I'm not able to repro this currently (with current config or the default config [adjusted with some of my must-have preferences]), but I'm running V11.0.2 now and it was on 11.0.1 that I noticed the problem on.  Is there a way to "roll back" to 11.0.1 so verify I can repro this again there?  Since I don't have the exact data files anymore to do the exact repro, I'd like to verify the issue on 11.0.1 before saying 11.0.2 fixed it.  I could re-install 11.0.0 and apply the 11.0.1 patch (and spend an hour configuring my preferences), but that patch appears to be no longer available.

I originally reported the problem to support@slickedit.com on 1 Sept 2006 (at 2:24 pm), which was shortly before the 11.0.2 patch was released.  I posted the problem (along with a couple of others also reported to support) since the Community appeared to be where the real action was happening.

[Clark]

Now I'm certain that this was fixed in 11.0.2.  The problem started in 11.01 when I added some tricky win32 message handling code to allow users to press ESC to cancel any recursive file listing operation in SlickEdit.  This was bugging me a lot since I would accidently type "list c:\" and have to kill the editor.  It turns out I missed screening out key up messages.  Basically any macro which called process_events() could get the active editor window changed but only if the Ctrl key was pressed.  This rarely occurred but it could.  I never hit this bug but one person in our development group did. Thankfully, undo would restore your sorted file.

As I always say...If you don't write any code, you don't get any bugs:-)

[rgknowles]

Clark,
  I don't see much correlation between my actions (clicking on the 'other' buffer's scroll bar) and your scenario, other than process_events is likely called when the mouse button is clicked, but if it meant that some messages were processed incorrectly it might be the cause.  I'll defintely let you know if I encounter the problem again.

[Clark]

I think you found a different hole in the code I wrote.  However, Dennis put some additional code else where to avoid this sort problem.  I will make sure the code I wrote screens out scroll messages.