|
|
Post by Grog on Jun 6, 2014 3:09:16 GMT -5
Hi - running SPFLite v8.0.4155 under Win7
#1 - When selecting a directory in the File Manager tab, the files of that subdirectory are displayed (good), but the cursor is moved to (if selection was by mouse click) or stays at (if <newline> plus <enter> was used for the selection) the screen location of the selected subdirectory from the previous display.
If the new subdirectory's contents do not contain enough entries to fill up to the line the previous display's selection was made at, then the cursor is moved to Home.
When the scroll amount is CSR, the scrolling behaves as if the cursor was at Home.
I would expect the cursor to be placed at Home every time a new directory is navigated to, including selecting a subdirectory, and ENDing back out to the parent directory. Would that agree with your thinking?
#2 - When a file (such as a simple .txt file) is selected from the File Manager tab, the <filename> tab appears with the files's data. (Good.) The cursor is usually not visble. I would like it to be visible.
Moving the cursor with mouse clicks or arrow keys does not make it visible again, although the "current line" indicators do change. Pressing <enter> or scrolling with a PF key or Alt-Tabbing away and back do make the cursor appear.
I thought it might be a timing issue with the cursor blinking in that the cursor was in a darkened state and the timer may not be ticking, but I see no way to turn off cursor blinking so I can't test that theory.
Any thoughts?
Otherwise, it seems to be a nice piece of software with a very snappy feel. Nice work.
|
|
|
|
Post by George on Jun 6, 2014 14:00:01 GMT -5
Grog:
#1 I think I agree with you on this, Home is more logical when the location of the display is changed. I'll tidy that up.
#2 Another user has spotted this, and I will go back in and try and stomp this out. You wouldn't believe how many times I've 'fixed' this already. Using the Std. Windows cursors has a lot more 'wrinkles' than I had thought. Anf yes, cursor blinking is no longer an option, it is all under Windows control now.
George
|
|
|
|
Post by George on Jun 7, 2014 15:33:53 GMT -5
I'd appreciate help here trying to find a repeatable scenario that triggers the disappearing cursor. I'm not doubting anyone's report as I HAVE seen this happen. I've made no changes (yet) to any routines related to this since the problem was reported. And if possible, please move to the latest release available, which right now is 8.0.4157. Just install over the existing version, no need to uninstall / reinstall.
George
|
|
|
|
Post by Grog on Jun 7, 2014 22:13:27 GMT -5
I confirm that the cursor is now consistently placed at Home when a subdirectory is selected in the File Manager tab under v8.0.4157.
Re the amazing invisible cursor trick, it (almost?) always happens when a file is selected from the File Manager tab for me, so it is hard for me to discern necessary and/or sufficient conditions to make it happen.
Since pressing <enter> is one reliable way to make it reappear, might an additional simulated <enter> after a file selection circumvent the problem? If so, you might be able to figure out which part of the null-input <enter> cycle code fixes it.
Other than that, no further clue here...
Thanks!
|
|
|
|
Post by George on Jun 8, 2014 9:19:58 GMT -5
Grog: Thanks, maybe its a timing thing. I've been opening edits, shutting them down, over and over again and I now can't seem to trigger it. I'll check out the Enter flow. It triggers what 3270's used to call an Attention Interrupt, which causes a lot more activity that a normal keystroke, but that path is exceedingly long, it's gotta be in the mainline flow itself. I'm still looking and poking.
George
|
|
|
|
Post by George on Jun 9, 2014 9:29:19 GMT -5
Robert: Been there. Done that. Tried it all again exactly as you described. Works perfectly. I guess I'm going to have to try this on some other systems, maybe it works here on Win 8.1 but will fail on others. Time to fire up the wife's laptop (Win7 32) and my Netbook (Win7 64) and also the virtual machine XP system and see how they do.
Don't know what else to try.
George
|
|
|
|
Post by George on Jun 9, 2014 12:24:17 GMT -5
OK, Progress. Works on Win 8.1 64 bit Works on XP Fails on Win7 32 bit. Works on Win7 64 bit. So much for Windows consistency. P.S. Debugging is supposed to be just that - debugging. Not a random "let's see, what else can I try". Regardless, I now have a version that seems to work on the Win7 32 bit system here, I'd appreciate it if any others with this problem could try the attached version. Just rename it from .ex_ to .EXE and stuff it in the install directory, don't uninstall what you have, there's no need. SPFLite80.ex_ (380.5 KB) Please let me know how this does on your system. George |
|
Grog
New Member
Posts: 1 
|
Post by Grog on Jun 11, 2014 9:55:25 GMT -5
Yes, it is Win 7 32-bit.
The temp download version has fixed the problem.
Looks like you've fixed it!
|
|
|
|
Post by George on Jun 11, 2014 10:09:42 GMT -5
Grog:
Thanks for the news, I think I'll package up a release with the last couple fixes, nothing new in the way of problems has turned up in the last couple days.
George
|
|
|
|
Post by George on Jun 11, 2014 10:33:20 GMT -5
Robert: I've checked out some other editors on my system (NotePad, Jarte, HnD) and I see the same kind of occasional stuttering with them as I do with SPFLite. Mind you, I never see the cursor disappear during rapid scrolling. As to threading, we've been here before too. SPFLite is basically a single threaded program. During a normal edit, the only other thread active is the File Watch thread which is started at the beginning of the edit session. It is typically asleep waiting for a notification from Windows that the folder containing the file has been altered. Which means that during a cursor scrolling operation it is undoubtedly asleep. Also by changing to Windows cursor support, SPFLite no longer has a cursor blink rate timer pop routine being dispatched regularly. And this has removed the prior need to define CriticalSection code which could be a source of interference. If you are experiencing the cursor actually disappearing at times, I can certainly understand wanting this fixed. But the flow for a simple repeating right arrow key could not be simpler: - Keyboard hook detects the -> key.
- Maps it according to KEYMAP - (Right)
- Dispatch the KB primitive routine.
- The (Right) routine calculates a new cursor location
- The SetCaretPos API is called to tell Windows of the new position.
- Return to Windows to sleep awaiting the next key.
Sure there's lots more code to accomplish all that, but the SPFLite activity involved to do this is as minimal as it can be. There's absolutely nothing I can even think of to attempt to 'fix' this problem. I'm open to suggestions. George |
|
|
|
Post by George on Jun 12, 2014 10:29:40 GMT -5
Robert:  The whole process is already inherently interrupt driven, after all, it's a keyboard/mouse driven process. A key comes in, you process it, you return to Windows and your thread sleeps. And for simple cursor movement keys, particularly left/right cursor movement, the processing couldn't be simpler. Just to refresh my memory, I walked a right-arrow key through from the point it gets posted by the keyboard trap, to it's return back to Windows. It's probably about 100-125 instructions (source code lines) of execution. That's hardly going to be a measurable interference with Windows. There's really not much wiggle room there for 'optimization'. When we were developing the Macro support, I can remember creating a small macro that effectively did what (Down) does. And you could key-repeat that macro just about as fast as the native (Down) key. And that meant opening and reading the macro file, firing up thinBasic, interpreting the macro code, interfacing between the macro and the mainline, and then shutting down thinBasic for each keystroke, which is a thousands of times longer path than a simple (Right) KB primitive would take. There's simply no way I can believe that SPFLite processing is interrupting or otherwise causing Windows to be delayed in updating the cursor. As to queuing, the keyboard trap already queues all the keyboard traffic by sending WM_USER messages to the mainline via the standard Windows message queue. I hardly think you mean the code should receive the WM_USER message and then somehow queue it again. To who? yourself? Another thread? No way I'm tackling making the keyboard handling a multi-threaded process!). I'm not at all clear here what you're suggesting. I know this is annoying to you, but I'm stuck here with no way to solve it. George |
|
|
|
Post by George on Jun 12, 2014 11:29:35 GMT -5
Well then, I just don't understand this area at all (not surprising) since no matter how long I take to proces a WM_USER message, it doesn't seem to bother Windows at all.
Take for example the (Enter) key that follows the entry of a macro name on the command line. The return from that WM_USER message for the (Enter) key will not be done till the macro is totally finished, which may include file I/O, display of message box pop-ups to the user, and all manner of other interactions with Windows, possibly extending to many, many seconds. Yet no Windows functions seem to be affected at all by the fact that the return from the WM_USER message has not been completed yet.
Yet you're telling me that by returning quicker, Windows will now be free to update the cursor in a more timely fashion.
Sorry, I can't reconcile what I see happening all the time with what you say is the cause of this Windows interference.
The SPFLite message queue is the queue for SPFLite messages, nobody else's messages, the only thread that can possibly be blocked or interfered with by this queue is SPFLite itself. That is proven by the macro example above. I still don't understand why you believe the handling of this queue would in any way be interfering with Windows.
George
|
|
|
|
Post by George on Jun 13, 2014 9:15:31 GMT -5
Since on my system I see the exact same stuttering with other editors (notepad, LibreOffice, etc.) as SPFLite exhibits, I simply can't see ripping out and replacing the keyboard methodology in some faint hope that it will be 'better' than it currently is. If the big guys products have the same 'problem', and they haven't fixed it with their resources, it's highly unlikely that I could best them.
George
|
|
The whole process is already inherently interrupt driven, after all, it's a keyboard/mouse driven process. A key comes in, you process it, you return to Windows and your thread sleeps. And for simple cursor movement keys, particularly left/right cursor movement, the processing couldn't be simpler. Just to refresh my memory, I walked a right-arrow key through from the point it gets posted by the keyboard trap, to it's return back to Windows. It's probably about 100-125 instructions (source code lines) of execution. That's hardly going to be a measurable interference with Windows. There's really not much wiggle room there for 'optimization'.