While scrolling down the text viewer with Mouse pressed to create a long selection, after about 1 1nd 1/2 page the scrolling suddenly stops and the selection is not being extended. I noticed that this sudden lack of control is accompanied by the BB icon jumping to the right in the task bar, as if some other icon appeared for a fraction of a second to the left of the BB icon. In any case, being able to mark a long selection by scrolling always worked. Now it does not under Windows 10.
By scrolling I mean: I begin the selection, and then I move the mouse pointer below the bottom edge of the BB window. The text will start scrolling, while being marked in reverse color. In the past I could scroll at will. If I moved the mouse up (holding it pressed) the text would stop scrolling. I could resume scrolling by moving the cursor back down, while still holding down the LM.
This always worked, but now it does not.
Selection problem in build 1.7.1
Selection problem in build 1.7.1
I have had the following problem reported to me; has anyone else observed it?
-
- Posts: 55
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: Selection problem in build 1.7.1
No - it sounds from thier description that some other application or process momentarily came alive and captured their mouse input. I suspect it would be difficult to diagnose unless you had access to their computer and it happened on a regular basis.
There's a old article here that I don't expect to provide a solution but may give a few clues on the sort of behaviour to look for when trying to identify the culprit:
http://www.drdobbs.com/avoiding-trouble ... /184416474
There's a old article here that I don't expect to provide a solution but may give a few clues on the sort of behaviour to look for when trying to identify the culprit:
http://www.drdobbs.com/avoiding-trouble ... /184416474
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Selection problem in build 1.7.1
This is most probably related to 'ghosting' a non-responding application window after about 5 seconds
by the Windows OS. Seems to be subtly different in Win10.
A large text selection is not required, all you need is a modal mouse tracking loop.
In 1.6 and 1.7 I cannot reproduce the problem. In 1.7-b1 I can.
It would be required to find out with which change in 1.7.1 this behavior was introduced.
- Josef
by the Windows OS. Seems to be subtly different in Win10.
A large text selection is not required, all you need is a modal mouse tracking loop.
In 1.6 and 1.7 I cannot reproduce the problem. In 1.7-b1 I can.
It would be required to find out with which change in 1.7.1 this behavior was introduced.
- Josef
- Ivan Denisov
- Posts: 363
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Krasnoyarsk, Russia
Re: Selection problem in build 1.7.1
Doug reported the same bug ?
viewtopic.php?f=19&t=161
viewtopic.php?f=19&t=161
Re: Selection problem in build 1.7.1
I have now observed this in 1.7.1-a1 (build 914).
I move the mouse below the Window to scroll, move it up to stop, then move it below again. After 2 or 3 seconds the window flickers, and the scrolling stops.
This happened every time for 4 or 5 tries.
I closed BlackBox, then reloaded it, and now the problem is gone.
There are no other programs running.
I move the mouse below the Window to scroll, move it up to stop, then move it below again. After 2 or 3 seconds the window flickers, and the scrolling stops.
This happened every time for 4 or 5 tries.
I closed BlackBox, then reloaded it, and now the problem is gone.
There are no other programs running.
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Selection problem in build 1.7.1
Yes, this is the very same problem.Ivan Denisov wrote:Doug reported the same bug ?
viewtopic.php?f=19&t=161
It is neither related to 1.7.1 nor to 1.7 but it also appears in 1.6.
Somehow it seems to be related to passing the focus (between Windows applications).
- Josef
-
- Posts: 55
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: Selection problem in build 1.7.1
You might already know this, but just in case: a quicker way of creating a long selection using the mouse is to:Robert wrote: While scrolling down the text viewer with Mouse pressed to create a long selection...
1. Select the first part of the text with the mouse as normal.
2. Release the mouse button.
3. Use the scroll bar to navigate to the last part of the text that you want to select.
4. Press and hold the shift key.
5. Click on the last character of the text you want to select.
All of the text between the start and the end should then be selected.
In practice it's easier to do than it might seem from reading this! AFAIK this is normal Windows behaviour and can be used in Word, Excel, Astrobe etc. etc.
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Selection problem in build 1.7.1
As far as I know, the only way to get rid of window ghosting is to switch it off.
See my previous post about that.
viewtopic.php?f=19&t=161&start=10#p924.
Is there anything lost if it is turned off?
I mean, is there any situation for a BlackBox user where the window ghosting would be helpful?
In a single-threaded system any long running command leads to window ghosting
and the user may think that something is wrong with BlackBox.
It could also be turned off by means of a preference setting.
- Josef
See my previous post about that.
viewtopic.php?f=19&t=161&start=10#p924.
Is there anything lost if it is turned off?
I mean, is there any situation for a BlackBox user where the window ghosting would be helpful?
In a single-threaded system any long running command leads to window ghosting
and the user may think that something is wrong with BlackBox.
It could also be turned off by means of a preference setting.
- Josef
-
- Posts: 262
- Joined: Tue Sep 17, 2013 6:50 am
Re: Selection problem in build 1.7.1
After more experiments I think I am closer to a solution.
If all messages are processed, i.e. removed from the message queue, the ghosting does not appear.
The following is an experimental modification of HostPorts.Input.
In my tests there is no ghosting and I have not seen any side-effects so far.
However, there is no guarantee that it is free of side-effects because there may be messages that need to be processed.
- Josef
If all messages are processed, i.e. removed from the message queue, the ghosting does not appear.
The following is an experimental modification of HostPorts.Input.
In my tests there is no ghosting and I have not seen any side-effects so far.
However, there is no guarantee that it is free of side-effects because there may be messages that need to be processed.
Code: Select all
PROCEDURE (rd: Rider) Input* (OUT x, y: INTEGER; OUT modifiers: SET; OUT isDown: BOOLEAN);
VAR msg: WinApi.MSG; wnd, mw: WinApi.HANDLE; pt: WinApi.POINT; res: INTEGER; set: SET;
BEGIN
wnd := rd.port.wnd; mw := WinApi.GetCapture();
res := WinApi.UpdateWindow(wnd);
res := WinApi.PeekMessageW(msg, 0, 0, 0, 1); (* << modified: removes any message from the message queue; only mouse messages will be processed *)
IF (res # 0) & (msg.hwnd = mw) & (msg.message >= WinApi.WM_MOUSEMOVE) & (msg.message <= WinApi.WM_MBUTTONDBLCLK) THEN (* << modified *)
...