|
Post by Stefan on May 23, 2019 4:32:18 GMT -5
Hi guys,
Thank you for release 19129.
I'm sorry, but I've only just noticed this using version 10.2.19109 (and 10.2.19129).
WINDOW RESIZE/MOVE In many situations, I can only resize the SPFlite window once. I say "many" because occasionally it works correctly. It appears to depend on how "smoothly" I carry out the dragging movement and it may be related to screen resolution. On a 1440x900 display, I may need to drag the window edges a few times before the effect sets in. Using a 1600x900 display on the same machine, or on another, faster laptop altogether, the example below always provokes the error.
Example: Open SPFLite. Resize the SPFlite window to make it narrower (i.e. drag the right window "edge" towards the left "edge").
The window cannot subsequently be resized or moved around the screen unless you stop & restart SPFlite first.
The following probably really simple-to-fix-hiccup doesn't even deserve it's own buglet thread.
"COPY-AFTER" LINE COMMAND
If the "A" is placed on an Excluded line(s) marker, it behaves like "B", i.e. line is copied before the excluded line(s), not after. It does not matter if the source line is above or below the destination (excluded) line. All works correctly for the "Move - After" line command.
Sorry to be a pain so quickly after a new release.
HUGE thanks to all of you for your continued efforts and support.
|
|
|
Post by George on May 24, 2019 12:50:23 GMT -5
Stefan: Fixed the COPY/AFTER, is was simply missing the adjustment to 'step over' the X'd lines. The MOVE version was obviously done correctly.
As to the screen resize hanging later, I tried a variety of resize activities and of course everything was fine. Not doubting your report, just frustrating to not be able to re-create it. If you can see any particular pattern happening, please report it.
Robert: There is no multi-thread activity going on with regard to screen drawing/resizing, SPFLite main task is single thread with a single Windows message pump, there is one and one only activity going on at a time. And any pending Windows messages are simply held in the queue till the current activity returns back to Windows with the result of the previous message.
George
|
|
|
Post by George on May 24, 2019 14:08:30 GMT -5
Robert: I know you strongly feel that there's a problem in SPFLite's use of threads, but they are used in a very limited fashion. Yes, FileWatch runs as a separate thread (it basically HAS to). And when it has something to 'tell' the mainline it does it just like everything else - it sends a message to the same message queue used by Windows, by the keyboard trap and by mouse activity.
And they all wait their turn for the main task to process the messages - one at a time, in a single thread.
And that flashing is entirely up to Windows, I don't trigger it (and don't even know how to). Not sure what Windows bases it on, but as you've said, it flashes when there's no identifiable reason.
George
|
|