Page 1 of 1
Lock-up when using toolbar
Posted: Mon Mar 19, 2007 6:07 pm
by helmut
I thought that I have posted this before but couldn't find it.
When using the 'Previous image' and 'Next image' buttons in the toolbar, XnView sometimes blocks. XnView does not GPF, but the mouse cannot be used anymore, XnView does not respond. Once you focus a window of any another application and then return to XnView it works, again.
To reproduce:
1. In View mode (image opened) left click on "Next image" toolbar button and
keep left mouse button pressed.
2. Right click on the same button and
keep right mouse button pressed.
3. Release both mouse buttons.
4. (Normal) left click on the same toolbar button.
-> The toolbar button remains pressed (Bug
)
-> Try to click on any other toolbar button, nothing will happen. (Bug
)
Could someone please try to reproduce this?
Notes:
- The problem ca nbe reproduced with any toolbar button.
- I've also experienced this problem in
WinMerge (which is also written in C++), but in the latest version of WinMerge the problem no longer occurs. Perhaps the WinMerge people have a solution to this problem.
- Even it is unlikely that people experience this problem, it is quite annoying if it does occur and therefore should be handled with
high priority (like a GPF).
XnView 1.90.3 on Windows XP SP2
Frozen !
Posted: Mon Mar 19, 2007 8:40 pm
by Clo
• Hi !
• I can confirm, testing the same in View mode, though (I didn't install these butons in the Browser…)
• Following your steps,
all gets frozen in XView,
even the Win buttons, hence it's even impossible to exit !
• I had to kill the process from the Task Manager via
Ctrl+Alt+Del !
- Xp-Pro SP1 here still. XnView 1.90.3
G.
Claude
Clo
Posted: Mon Mar 19, 2007 9:15 pm
by XnTriq
Hi Helmut & Clo,
I can't reproduce the scenario you describe, but I've witnessed a similar “anomalous phenomenon”:
- Right-click & hold Next file and then left-click it once
- Left-click Next file again, but this time keep the left mouse button pressed
- Release the right mouse button first and then the left one too
» The Next file button remains pressed down
- Left-click Next file or any other button on the toolbar
» The Next file button returns to it's normal state
This occurs with both the
Previous file and the
Next file toolbar buttons with XnView 1.90.3 in View mode (Windows 2000). I still have the
Default toolbar setting for
Basic,
View and
Browser.
Posted: Mon Mar 19, 2007 11:07 pm
by helmut
Clo, thank you for reproducing. Actually it must say "View mode", not "Browser mode" in my above description (I have corrected it).
XnTriq, I could reproduce your phenomenon. I've changed my above description a bit, perhaps you can reproduce it, now.
Note:
Once XnView is locked due to this problem you can open another application and then XnView is "unlocked", again.
Posted: Tue Mar 20, 2007 5:27 pm
by murthy363
To reproduce:
1. In View mode (image opened) left click on "Next image" toolbar button and keep left mouse button pressed.
2. Right click on the same button and keep right mouse button pressed.
3. Release both mouse buttons.
4. (Normal) left click on the same toolbar button.
-> The toolbar button remains pressed (Bug Bug)
-> Try to click on any other toolbar button, nothing will happen. (Bug Bug)
Could someone please try to reproduce this?
Notes:
- The problem ca nbe reproduced with any toolbar button.
I too tried to reproduce with the procedure posted by helmut and experienced similar problem, but for some variations in the observations.
1) As I pressed each button, each button is getting pressed (lowered) without any effect. The previous pressed buttons are not getting released.
2) I am not able to do anything with the program including closing it with File >> Exit.
3) I had a browser window already open and and made that window focused.
4) Later, I brought XnView window back into focus. But still, the depressed buttons continued to be depressed.
5) But now, I wanted to retry to close XnView window with File >> Exit. When I pressed the 'File' tab, ALL the depressed buttons were released (
) and I am able to close the program with 'EXIT'.
6) I was also able to press any other tab and the same is working. AND i could even continue to work with the program without closing it.
I repeated this procedure quite a few times and got consistent behavior.
My system is Win XP SP II with XnView 1.90.3
In any case, I feel, that this is abnormal behavior and needs quick attention.
Posted: Tue Mar 20, 2007 5:30 pm
by murthy363
helmut wrote:
Note:
Once XnView is locked due to this problem you can open another application and then XnView is "unlocked", again.
I have just confirmed this behavior in my post a few minutes back.
Posted: Tue Mar 20, 2007 5:51 pm
by murthy363
I could follow the procedure described by xnTriq and got the similar behavior.
And when the focus is changed to some other window and returned to XnView, the program releases all the depressed buttons and restores normal functioning, which is similar to the observation against the earlier procedure described by helmut.
Posted: Tue Mar 20, 2007 7:52 pm
by helmut
O.k., there defintely is a problem. Thanks, again, for testing.
I hope that Pierre can track the problem down and solve it.
Re: Lock-up when using toolbar
Posted: Tue Mar 20, 2007 8:50 pm
by XnTriq
helmut wrote:- I've also experienced this problem in
WinMerge (which is also written in C++), but in the latest version of WinMerge the problem no longer occurs. Perhaps the WinMerge people have a solution to this problem.
SourceForge.net Bug Tracker:
Both-button-click onto toolbar button crashes WinMerge (fixed/closed)
Re: Lock-up when using toolbar
Posted: Tue Mar 20, 2007 10:06 pm
by helmut
Yepp, that's the same problem. This might help in solving the problem. Thank you, XnTriq for providing that link.
(I thought you were XnView forum librarian, but you are Internet librarian. )
Posted: Thu May 24, 2007 7:55 pm
by XnTriq
Confirmed fix (Windows 2K).
Posted: Fri May 25, 2007 12:51 am
by helmut
Good to read that his is fixed.
Re: Lock-up when using toolbar
Posted: Tue Aug 24, 2010 6:55 am
by helmut
In XnView 1.97 the problem occurs, again.