Author Topic: Possible bug (Read 48590 times)

Ulfhednar · « **on:** August 08, 2013, 16:15:12 »

FYI - Possible bug.

I have noticed a 'strange' event a couple of times with the in-line rename function.
When doing an in-line rename if I use <e> or <l> in the new name, the field will jump to edit a segment as if <ctrl> had also been pressed.
I discovered pressing <ctrl> a few times would unstick the selection focus so I can enter the new name.

Mathias (Author) · « **Reply #1 on:** August 08, 2013, 16:34:25 »

(Plz. Keep bug for new stuff in beta to the beta section)

Yes this has been reported. But I have not been able to reproduce it . But I changed the code a lot since the latest beta so if it is still an issue in the next beta let me know.

Ulfhednar · « **Reply #2 on:** August 08, 2013, 17:05:54 »

Sorry I was focused on your original announcement of the change in the in-line rename function.

Ulfhednar · « **Reply #3 on:** August 09, 2013, 18:29:05 »

As I have a generic bug post title I will add this here -

I sometimes find my cursor is locked inside the search result pane region.
This means my cursor can go to the top/bottom of my monitor display but no further laterally than the dividing line between MC panes.

I cannot determine if there is any common cause as it is very infrequent. I do more than one search a day & see it maybe once in 7-10 days.
(Today I had time to remember to report it!)
Only way I can get the mouse out of that space is to minimize the MC window. Then everything returns to normal.

Jungle · « **Reply #4 on:** August 09, 2013, 18:51:06 »

I confirm bug with inplace rename for current beta 1452. Steps:
1. Launch MC
2. Open inplace rename. OK. <e> and <n> acts like chars
3. Cancel rename
4. Press and release Ctrl key
5. Open inplace rename. BUG. <e> and <n> toggle ext/name selection
6. Cancel rename.
7. Open inplace rename. All OK again.

Bug with mouse cursor is easily reproducible on Win 7 x64 and MC v3.2.1 x64. It was described, captured and sent to Mathias. But on WinXP x32 i'm unable to reproduce it neither in MC 3.2.1 nor in MC 3.3.0.

Mathias (Author) · « **Reply #5 on:** August 10, 2013, 15:43:00 »

Still can't reproduce it.. But I have change a lot of other things around this. so that might have fixed the issue.

It will try to push out a new beta today. So let me know if you still can reproduce in build 1457+

Jungle · « **Reply #6 on:** August 12, 2013, 06:35:10 »

Bug with horizontal mouse cursor locking still exists in 1457. Appears after column resizing. The easiest way to see it is resizing Size/Date column (via separator between these columns).

Win 7 x64 Enterprise, MC 3.3.0 b1457

P.S. I haven't noticed such effect in other apps. I also tried closing all apps before launching MC.

Mathias (Author) · « **Reply #7 on:** August 12, 2013, 08:55:25 »

Can't make it happen.

Are you doing something special ? like clicking while dragging, or something. The only reason I see something like that can happen is if mouse up is never sent.
So mouse up must be lost in some way. But don't see how, And I can not reproduce it. and then it is almost impossible to fix.

Jungle · « **Reply #8 on:** August 12, 2013, 10:26:25 »

I just start MC and begin resizing, nothing special. Tried also with default settings and MultiCommander style - the same result.

Mathias (Author) · « **Reply #9 on:** August 12, 2013, 11:08:44 »

I works for me on all machines I tries on. For it to not work the 'mouse up' event must be blocked. So maybe it is OS related, settings in the OS, or some other program that hook it self into Windows, or a combination of things that cause a conflict or something..
I don't know, very strange.

Jungle · « **Reply #10 on:** August 12, 2013, 11:52:27 »

Maybe some kind of debug tool can help?

P.S. I've noticed that after cursor is locked new resizing always unlocks it.

Mathias (Author) · « **Reply #11 on:** August 12, 2013, 12:52:48 »

Not really locked, but cursor is set into clip region where it can only be moved inside. but it is removed when button up event is received or operation is canceled ( Windows message WM_LBUTTONUP or WM_CANCELMODE )

Why does events is not received for you I don't understand.

Ulfhednar · « **Reply #12 on:** August 13, 2013, 09:35:28 »

The cursor lock-up has been rare for me [w7 x64 ult; NVDA 320.49 VGA driver.].
As I said I could move up & down the whole desktop but not past the MC pane divide. Escaping the search region allowed me to hit minimize, which reset the behaviour. Progs tiled behind seemed to be locked behind MC. Moving, closing & minimizing the other programs was possible within the space. They didn't come forward on screen however.
On 1457 this effect hasn't happened yet.

Maybe this is related to the drag n drop focus grabbing I mentioned in another post? (Dragging a media file to VLC brings MC to the front/top & obscures the target window.) In the past I've found click/hold/drag would keep the target on top & allow me to drag a file from the lower level window. No change in stacking.
Sorry if this is a red herring, trying to think of any other clues...

I have noticed something new today, I don't usually use <ctrl> & <pgup>, <pgdn>, <+> etc but I noticed today those key combos didn't work for navigation. (Perhaps I need to turn something on in options?)

Jungle · « **Reply #13 on:** August 13, 2013, 10:24:56 »

Quote from: Ulfhednar on August 13, 2013, 09:35:28

Maybe this is related to the drag n drop focus grabbing I mentioned in another post?

Not sure. As i said i close all apps, launch MC and begin resizing. Just a few resize operations reqiuired to get cursor trapped.

Ulfhednar · « **Reply #14 on:** August 13, 2013, 19:24:55 »

Quote from: Jungle on August 13, 2013, 10:24:56

Quote from: Ulfhednar on August 13, 2013, 09:35:28
Maybe this is related to the drag n drop focus grabbing I mentioned in another post?
Not sure. As i said i close all apps, launch MC and begin resizing. Just a few resize operations reqiuired to get cursor trapped.

I haven't been able to replicate that. For me it is (maybe) some combo of resizing the columns in the search pane, & maybe <shift> or <ctrl> select.
It's only done this a few times for me & it won't do it today!

Mathias (Author) · « **Reply #15 on:** August 13, 2013, 23:20:15 »

Quote from: Ulfhednar on August 13, 2013, 09:35:28

Maybe this is related to the drag n drop focus grabbing I mentioned in another post? (Dragging a media file to VLC brings MC to the front/top & obscures the target window.) In the past I've found click/hold/drag would keep the target on top & allow me to drag a file from the lower level window. No change in stacking.

When dragging something OUT of MC. MC has not control what so ever on what windows that it is dragged over. It is windows it self that handles all the switching of windows.

Quote from: Ulfhednar on August 13, 2013, 09:35:28

I have noticed something new today, I don't usually use <ctrl> & <pgup>, <pgdn>, <+> etc but I noticed today those key combos didn't work for navigation. (Perhaps I need to turn something on in options?)

Go to next/prev sibling folder works for me. maybe you clear the keys for it ?

Ulfhednar · « **Reply #16 on:** August 14, 2013, 12:20:43 »

I recall you mentioning this before Mathias, & I understand that you must 'obey' the OS as far as this level of interaction goes.
However if I open Explorer panes x2 & drag from the underlying pane, the focus/stacking does not change. (See attached)
I cannot replicate this behaviour with MC with click-hold-drag.
I thus imagined that some hook into the display management isn't quite right.
You have greater understanding of the calls MC makes & how Win responds but to me it appears anomalous. $:-\$

I will dig about as regards the nav keys, I haven't edited anything to my knowledge but maybe something is still damaged from a bad install I had a while back.

Mathias (Author) · « **Reply #17 on:** August 14, 2013, 12:53:11 »

Quote from: Ulfhednar on August 14, 2013, 12:20:43

I recall you mentioning this before Mathias, & I understand that you must 'obey' the OS as far as this level of interaction goes.
However if I open Explorer panes x2 & drag from the underlying pane, the focus/stacking does not change. (See attached)
I cannot replicate this behaviour with MC with click-hold-drag.
I thus imagined that some hook into the display management isn't quite right.
You have greater understanding of the calls MC makes & how Win responds but to me it appears anomalous. $:-\$

I will dig about as regards the nav keys, I haven't edited anything to my knowledge but maybe something is still damaged from a bad install I had a while back.

It is not that I must obey the OS.. it is that I got no choice.. When a drag operation is started.. It is handed of to the OS.
and MC does not get to do anything until the user drop the file.

However when I drag here. Nothing changes focus for me while dragging. only why I can make a program pop to the top is to hover over the taskbar for that program during drag.

Ulfhednar · « **Reply #18 on:** August 14, 2013, 17:53:24 »

Well, I only obey when I have a gun to my head so it is a no choice kinda thing

You can have MC beneath other windows, click-hold-drag from MC without focus/stack change, but I cannot, as soon as I click MC will jump to the top.
I cannot do this between 2 MC windows or MC & a 3rd party window. MC with selected item will always jump forward.

Using Explorer the windows stay in the same order as they started.
In the screen shot I can click-hold-drag the files in the pane below (*.chk) & I can drop it into the top pane without any effect on stacking. The top window (on right in the pic) stays put on top. Click-release will change the stacking order.

So the question is why? It seems as if something linking the interaction of desktop (e.g. DWM.exe) & MC is sometimes awry. With all the 0000000s of configs out there it might be tough to track down. Is there anything I can run to monitor the environment?

ice-man · « **Reply #19 on:** August 14, 2013, 22:07:51 »

Ulfhednar :
I Think you are mixing up things and that is confusing Mathias

The issue is not drag and drop.. and that z-order is changed during drag..
it has nothing to do with drag at all.

It has to do with that MC is set to focus when mouse button down is received.
(When a new program is set to focus Windows will by itself bring that program to the front )
Explorer and some other apps set the program/window as focus when the mouse button is released (ButtonUp)

TC and a lot of other programs also have this issue.

Ulfhednar · « **Reply #20 on:** August 15, 2013, 12:15:18 »

Quote from: ice-man on August 14, 2013, 22:07:51

Ulfhednar :
I Think you are mixing up things and that is confusing Mathias

The issue is not drag and drop.. and that z-order is changed during drag..
it has nothing to do with drag at all.

It has to do with that MC is set to focus when mouse button down is received.
(When a new program is set to focus Windows will by itself bring that program to the front )
Explorer and some other apps set the program/window as focus when the mouse button is released (ButtonUp)

TC and a lot of other programs also have this issue.

I am not talking about click-select; drag-drop. That does change the Z order (& 'always' has in Explorer etc). If this focus change event isn't clear I can try to video it & post the result.
I can only go on what I read here, Mathias seems to say MC behaves differently for him. If he said that it was no different then my question is moot/irrelevant.

Quote

However when I drag here. Nothing changes focus for me while dragging. only why I can make a program pop to the top is to hover over the taskbar for that program during drag.

I don't use TC - tried it (several versions) & didn't like it.
I think if TC behaves in this way then the question of focus grabbing stands. i.e. there is something that allows or forces a certain range of stacking behaviours in relation to the type of cursor interaction.

ice-man · « **Reply #21 on:** August 15, 2013, 13:28:42 »

Quote from: Ulfhednar on August 15, 2013, 12:15:18

Quote from: ice-man on August 14, 2013, 22:07:51
Ulfhednar :
I Think you are mixing up things and that is confusing Mathias

The issue is not drag and drop.. and that z-order is changed during drag..
it has nothing to do with drag at all.

It has to do with that MC is set to focus when mouse button down is received.
(When a new program is set to focus Windows will by itself bring that program to the front )
Explorer and some other apps set the program/window as focus when the mouse button is released (ButtonUp)

TC and a lot of other programs also have this issue.

I am not talking about click-select; drag-drop. That does change the Z order (& 'always' has in Explorer etc). If this focus change event isn't clear I can try to video it & post the result.
I can only go on what I read here, Mathias seems to say MC behaves differently for him. If he said that it was no different then my question is moot/irrelevant.

No I'm not talking about click.. a click is mouse button down and then up..I only talk about button down there.
(That is also what you start with when you are about to do a drag and drop.. )

The reason I think Mathias do not see any problems with drag and drop is because he is looking at the wrong place.
Because the issue is not a drag and drop issue.
Why I think so if because MC switches to the front on button down. BEFORE the drag action have even started.
(If you just press mouse button down on an file and do not move the mouse. A drag and drop action is not started. It is not started until the mouse moves while button is down, and you then get a image around the cursor showing what is dragged)

Or maybe we are talking about different problems. But I can't see any problem with z-order after the drag have started.

Quote

I don't use TC - tried it (several versions) & didn't like it.
I think if TC behaves in this way then the question of focus grabbing stands. i.e. there is something that allows or forces a certain range of stacking behaviours in relation to the type of cursor interaction.

It was just an example.. Did not mean for you to go use it. What I was referring to was that the button down and focus change is normal and standard behavior of windows. If you take ANY other application then WE like Notepad, IE, you see that when pressing mouse down it when the window is half hidden by another window that will bring the window you are pressing down on to the front. only program that does not do that in Windows Explorer. That tells me that the standard way windows works is to bring it to the front and Windows Explorer is going out of its way to not behave as a standard window. So if we want that behavior in MC then MC also must also handle that it self. IF Windows now allows 3de party apps to opt out of it

Ulfhednar · « **Reply #22 on:** August 16, 2013, 10:22:22 »

Yes you are right Iceman it is a 'unique' Win Explorer behaviour.
Also exists in Dir Opus & IIRC XYplorer & xplorer2. (Tried a few of these FMs & only like 2 - MC & DO.)

The reason I include drag as a qualifier is because I can think of no other reason for click & hold on a file in a sub-level window. The act of holding/moving the item invokes the z position modifier. Otherwise the window pops forward - Explorer included.

The problem for me is the need for Explorer to sometimes not change focus, exists with all file managers. There are times when you want to drag to a top window without changing the Z order.

I was trying to ascertain if MC also had this Exploer-type behaviour. If I click-hold-drag in Explorer it stays put, in MC it doesn't.
Mouse button down = MC to front.

Mathias (Author) · « **Reply #23 on:** August 17, 2013, 17:42:57 »

Ahh Yes MC does set focus on click down and that is why Windows decided to send the MC window to the front.

However it is not as easy just to remove the set focus to the button up. I have tested the a while ago and that resulted in strange focus issues in another scenarios in MC. So it is a bit of work to get that working. I actually have it on my list but it is not a top priority item. But someday I might have the time to take a look if it can be solved.

Ulfhednar · « **Reply #24 on:** August 17, 2013, 23:33:55 »

Thanks Mathias, I was uncertain if this was intentional.
Given negative side-effects then it is understandable that it is left as is.
Really it is not a priority, but nice if you have opportunity to get it to work.

...mystery solved...

*

@ Iceman, I wasn't thinking you meant me to use TC just that I am unfamiliar with it because I didn't like it enough to learn its' idiosyncrasies.

News:

Author Topic: Possible bug (Read 48590 times)