Floating preview questions

[admin]

A possible cause can be a defect keyboard. If you have the chance try to plug in another keyboard.

[xyxel]

Hello TheQwerty, Yes that was the third of such threads I didn't mention because I overlooked it this time, and it's exactly the problem encountered by myself, incl. not-updating of even the status line - remember, in my case at least, every time, faulty or not, the SECOND entry in the status line, i.e. the SIZE of the new file, IS updated: Could that not be a hint in order to better identify the problem, perhaps?

Don said there, can't be XY's fault, and you answered,

"Well I saw this again this morning.. restarting XY didn't fix it. Running a freshly extracted copy of XY that was renamed to 'xyplorer-test.exe' exhibits the exact same behavior, so it's definitely some interation between XY and something on the system.

So I'll concede the source of the problem is probably not XY, but XY has so far been the only program to show any negative side-affects from whatever is wrong. That fact implies, at least to me, that there is also a bug in XY's handling of the missing piece."

I'd like to back this opinion: It's the interaction between XY and something other, and I never encountered any similar problems with any other application in many years of pc use and abuse.

But I'm hard trying to better identify the problem. It's hard for me to work without my macro program, but I'll persist with that, and now, two hours later, XY (100) works correctly.

We have been FOUR people encountering this problem (and bothering to relate it here, that is), so I understand Don's stance "must be something else", and indeed, in MY workflow, for many years now, my macro program goes without saying, is part of the system, but then, most people do not use a macro tool, and other macro tools then, so in my case, it could very well be the macro tool even if I only came to suspect it very late in my thinking about possible reasons...

Hello Don, I'm using (an external screen and) an external keyboard (but that works correctly in any other instance). Next time XY will unbehave, I'll try the laptop keyboard for browsing, but probability for that possible cause is low. Remember the MIDDLE item of the three statusbar entries IS updated, and within the pane, selection GOES forward / backward to the next / previous item. So the keyboard seems to work fine here. As said, the probable culprit might be, in my case, the macro tool - I'll observe further, without the macro tool running (even if that's a problem for me).

[xyxel]

(XY running smoothly...)

I see, the "IP" mentioned in the other thread is immediate keyboard down / up codes / whatever processing... But I suppose that's the wrong field to look into, since there is that PARTIAL update anytime, with correct or with faulty behavior.

Don's

"apparently it had to do with the way I detected HOW a selection was made. You may have noted that selections by keyboard only update the IP when all keys are up again. This is to allow fast usage of Key Up/Down in a list by bypassing the IP. Some part of this detection was done a bit dirtily (this code was over 10 years old... it got dusty). I polished this and it seems to work."

there doesn't seem to be exotic in the light of my suspecting the macro program; indeed such a macro program intercepts any keystroke, down, up, hold, either processing it or giving the way to normal way of things, but first, anything is checked by the macro program.

But then, Don thought he got away with the "bug", when in fact, many versions later, I encounter it.

BUT THE REAL SECRET behind all this MUST lay within my observation that in ANY case, the middle element of the status bar, i.e. the size IS updated, even when the third and last element, the file name, is NOT updated (and the properties ain't, and the preview isn't):

In every such faulty case on my system, the file SIZE in the statusbar IS updated (and, as said, the selection within the pane itself is updated). And this, for my (naive) understanding of it, "says", it cannot be something with the processing of the key pressing, but it MUST be something within the code that is executed within XY, when the key pressing is processed there.

This being said, it could be something in my macro tool, but "at another place", not when it intercepts the key pressing, but elsewhere, with some API problems like the ones Muroph described there, my macro tool perhaps changing some "switches" XY then supposes to be "in another position", but within the "real" code, afterwards: why, by interference at the key processing level, the PARTIAL update of things?

(That's my understanding as a layman of course.)

(My fault: "IP" meaning Info Panel here. I got it, at last!)

Muroph on page 3 there:

"OK, here's what happens:
the file shown in the status bar's 3rd field is the same as the one in the IP (i.e. it's the wrong file).
but the file size, in the 2nd field, is always correct."

So it's exactly what I'm describing many versions later...

Muroph there: "but win7 is really fresh, with only a few apps installed", and the bug coming again and again...

Don, you spoke of a "debug log" there. Why could this not be run whenever the behavior occurs, but had to be done within a 24 hours' time window then? If it wasn't for the time window - how to assure when the behavior will be there again? -, running such a debug log seems to be a very good idea to me!


My intermediate resume would be: SOME other applications / tools / processes unknown to the user but running change some Windows setting upon the internal processing code of XY relies, falsely supposing those settings / variables have a certain value, when in fact, those third-party routines have changed these to another value. Hence PARTIAL processing within that internal XY routine only, i.e. the routine "thinks" it is running correctly, but doesn't get the message back from the Windows file system (NTFS) that parts of its commands transferred to it haven't been processed. Which would mean the internal code of XY would need to first CHECK for the value of some internal Windows settings / state of things which at this time it supposes to be within their normal state, but which is a false assumption, given some such external processes happen to FIDDLE with those. AND it seems these unwanted switches often are NOT reverted to default values by simply shutting down the system, then turning it on again, but are only switched back to normal value "by accident", i.e. by the same processes having adjusted them beforehand, or even by other processes, and perhaps by internal check routines of other processes that check for those values and switch them back to default state if they encounter them deregulated, a thing the XY routine here would have to do also, in order to prevent these partial-only file display updates. AND it's interesting that would be a setting in XP, and in Vista and in Win7, so it's a problem that hasn't taken care of itself by Windows versioning. (XY running smoothly...)

EDIT :

In the light of the current thread "Focused Items"? - http://www.xyplorer.com/xyfc/viewtopic.php?f=3&t=8321 - re "focused" vs. "selected", it seems important to specify that within XY misbehavior explained above, and contrary to what I said there, when the misbehavior occurs / occured, within the normal pane (what you call the "catalogue", yes? not to be confounded with the "tree" of course), it was this:

I falsely said that there (and there only, not in the "IP"), the "selected" item was updated, when in fact, FOCUS was shifted to the current item.

I.e.: RightArrow did indeed, there, shift focus to the item "1 item to the right" of the up-to-then current item, but it did NOT display that rectangle with medium-grey background around the file name there, but only the dotted light rectangle around the "new" filename, without the medium-grey background (= indicating "selection"), i.e. focus (= rectangle) shifted indeed, but selection (="filling" of the rectangle) did NOT shift - but was simply lost, in case: If there HAD been real "selection" (= file name with rectangle with background), that vanished, but only focus (= the rectangle without the filling) being shifted to the "new" item, no more "selection" whatsoever, whilst the content of the "IP" stayed frozen with the properties of the previously "selected" item.

In this scenario, you could "select" any other file, but only with mouse click (not with arrow keys which only shifted the "focus"), and on changing "selection" with mouse click, the properties in the IP were updated, only to be frozen on THAT item's properties now if afterwards you shifted "focus" (not "selection") onto another item, with arrow keys.

(Other arrow keys similar of course, and in every instance, the size of the file in the taskbar was updated.)

I think that this "detail" is of utmost importance in the understanding of what goes wrong with XY in such instances, since, contrary to your assumption, Don, in the thread "Focused Items"?, when this "bug" occurs, "selection" and "focus" of files within the "catalog" / normal pane are NOT synchroneous anymore, "selection" vanishing, being replaced by "focus" alone!

(So, in all previous posts of mine here read "selection"/"selected item" for "focus"/"focused item": only then my descriptions are correct.)