|
Post by George on Jun 1, 2015 14:03:01 GMT -5
Jo: Many thanks for the log. REALLY interesting. Robert has been questioning the number of Windows calls to do StatusBar updating. And your trace demonstrates the problem even more so. All throughout the 'normal' part of the log, there are sequences of SB draw requests, usually in strings of 7/14/etc. Which, since I think there are 14 boxes, makes sort of sense.
But near the end, when things go crazy there are strings of SB draw requests than number in the HUNDREDS (there are two lumps of 700 straight SB draw requests) which is just nuts. There is no logical way the program will ever do that. There must be some oddball way to create a loop where it's doing nothing but SB updates. Since they all need Windows calls to draw them, the message queue is not blocked, and some other messages get through (like your SAVEALL) and an [X] shutdown.
So this is good news, at least I can zero in and review everything in the SB update process.
Everyone's patience and co-operation in tracking this bug is really appreciated, it's been invaluable.
George
|
|
|
Post by drbob54 on Jun 2, 2015 4:03:47 GMT -5
George I would have a look at the drawing of the status bar. I compared the current drawing of the status bar with 6.2.3061 that I had kept. 6.2.3061 always draws the status bar the same way. I will refer to this style as a complete status bar. The current version of Spflite only draws a 6.2.3061 status bar after it has been minimized/maximised. When you first open Spflite the status bar is ~90% drawn (aka a partial status bar). If minimize and then maximise Spflite the status bar is different and a complete status bar is drawn. Change tabs or open a new file and Spflite draws a partial status bar. I get the same behaviour on 3 machines I have tested. On the machine where I see most of the 'going dead' there is another variation in that the portion of status bar with text can drawn larger than the portion of the status bar without text. I will add some screens shots to show what I mean. This happens on Windows 7 (professional and home) and windows 8 Attachments:
|
|
|
Post by George on Jun 2, 2015 14:02:20 GMT -5
drbob54: Thanks for the snapshots, Yes, the current focus is on the whole status bar and it's updating. The traces Robert and Jo have provided definitely show an enormous spike in statusbar update calls at the time is 'goes dead', far in excess of anything logical. I think somehow SPFLite gets itself into a SB drawing loop, right now it seems logically impossible looking at the code, but impossible or not, it IS happening. I just have to wrap my foggy brain around the logic flow.
I may have to put out another tracing version to clarify things if I can't see my way through this.
Right now, all I can say is we're closer, and I keep saying to myself "What have you done? This is going to turn out to be so stupid."
George
|
|
|
Post by George on Jun 4, 2015 16:00:50 GMT -5
OK everyone. I have not pinned it down properly yet, but you have all suffered long enough. Although not a proper fix, I'm going to make available a slightly crippled version of SPFLite. Robert has been testing this and reports no incidents of the 'going dead' problem. So how is it crippled? It simply has the StatusBar effectively turned off. It doesn't affect the basic usability of the program, and I'm continuing on restoring it without bringing back the 'going dead' problem. So here it is: www.spflite.com/Files/SPFLite825154.NSB.ex_Please let me know immediately if you still experience 'going dead' problems. I have my fingers crossed here! George
|
|
|
Post by drbob54 on Jun 5, 2015 8:13:44 GMT -5
Have started testing. The status bar that is displayed is not being fully drawn as per my previous update.
|
|
|
Post by George on Jun 5, 2015 14:14:52 GMT -5
drbob54: The inconsistent drawing I have seen in the past, long before this current problem. What I do not understand about it is that I have basically no control over any of that.
The basic SB and the boxes are all drawn totally by Windows. Even though I have the SB boxes defined as OwnerDraw (so I can control colors etc.), all that means is that I can draw what's in the boxes, I do not draw, nor have any control over the frames.
So that aspect of the problem is really odd. It's one of those "I'd love to fix it, but ....". I'm sure there an explanation for it, but I've got none.
George
|
|
|
Post by drbob54 on Jun 8, 2015 0:42:54 GMT -5
George 5154 has been stable so far. The caveat being that I have not used it a great deal. However today I noticed some 'garbage' characters in the second pane of the status bar. This has only happened once that I am aware of. This could indicate the status area is being overwritten. Attachments:
|
|
|
Post by George on Jun 8, 2015 11:01:45 GMT -5
drbob54: Thanks for the report. I'm not too concerned about those garbage chars right now. I 'turned off' the SB very quick and dirty, so I'm not surprised that I might have missed something.
I have done a re-build of all the SB support, and Robert is currently testing a version which has the SB re-instated. So far it is looking OK. So I expect shortly to put out that version for a further shakedown. Then hopefully if it looks stable, I'll actually wrap it up properly and put out a new official version. Keeping my fingers crossed.
George
|
|
|
Post by George on Jun 8, 2015 14:54:02 GMT -5
Robert: Status? Has the latest been stable enough to allow others to try it out?
George
--> It seems to be OK in the time I have had to play, no problems so far
==> OK, I'm going to let others have a go at it.
|
|
|
Post by George on Jun 9, 2015 11:53:15 GMT -5
Everyone: I need your help again to test the fix for 'dropping dead'. I wish it was repeatable enough that I didn't need to call on you, but this whole problem has simply never cooperated at all.
I've posted another trial version to the website: www.spflite.com/Files/SPFLite825160.ex_ This version has some completely re-written StatusBar code and initial testing by Robert and myself seems to show our 'drop dead' problem is gone. (fingers crossed)
This is hopefully a release candidate level, with the following exception. It still has some tracing activated so that if it does exhibit another 'going dead' problem, we will have a trace available. The trace is written to \Documents\SPFLite\SPFLite82.Trace.log. If while using this version and a problem occurs, please copy this file somewhere safe before restarting SPFLite. Then send me the trace file.
If this seems to function properly for you, then I will remove the trace code and properly wrap this up and issue it as a new official release.
Your help and assistance is really appreciated.
George
[Robert] -> Hey, George, my version was 5159, is that the same thing as yours here or should I grab this one? [George] => 5160 has the file/folder open fix as well, your call.
|
|
|
Post by Jo on Jun 9, 2015 15:32:47 GMT -5
No "going dead" so far, but after a SAVE on the 1st Edit-Tab, the Notify-popup "The Current File: / (2nd Edit.Tab) / Has been modified elsewhere / Do you want to load the modified version?" appeared for an untouched file. Since I had not changed anything in this file, I decided to press "Yes". A subsequent F5 (rfind) correctly found the next occurence of findstring2, but the message "CHARS ... found" was for findstring1, previously used on Tab1.
Jo (using v5160)
... occurred just once, could not reproduce it.
|
|
|
Post by Jo on Jun 9, 2015 16:41:30 GMT -5
|
|
|
Post by drbob54 on Jun 9, 2015 23:09:48 GMT -5
George No problems yet with 5160. I did notice on Jo's screen shot the status bar was being drawn correctly. The only difference was that Jo using a different font. I am using FixedSys If I change the font to Lucidia Consol, Consolas or Liberation Mono the status bar is drawn correctly. What I noticed is the problem is not actually with the drawing of the status bar. With the FixedSys font active the black edit area is actually too large and overlays the status bar area. The end of the black edit area plus the bounding box is behind the the status bar. With Lucidia Consol font the gap between the bottom of the black area varies between overlay and wide depending on the size of the window. Attachments:
|
|
|
Post by Jo on Jun 10, 2015 2:50:39 GMT -5
I am using Raster. (I need € Euros ;-)) Jo
|
|
|
Post by Jo on Jun 10, 2015 4:26:43 GMT -5
Robert, no, no size changes or overlays in the statusline.
|
|