|
Post by George on May 25, 2015 14:36:54 GMT -5
Hi, As I've mentioned before, trying to fix this without a repeatable scenario is an impossible task. I'm making guesses as to what it might be, and experimenting with things in the hope that it will make a difference. One thing is obvious, it simply HAS to be timing related and some pieces of code are falling all over each other because of some subtle interaction. I have just finished combining two major Windows callback routines into one. It's another of those "shouldn't make a difference" things, but I have to admit to still being a novice at Windows programming. So there's another new trial version located at www.spflite.com/Files/SPFLite825145.ex_ As usual, rename it to SPFLite.EXE and move to the normal Install folder. I'd really appreciate this being tried out by people who have experienced the problem regularly. All feedback is welcome. George
|
|
|
Post by drbob54 on May 26, 2015 11:33:51 GMT -5
Tested a 5145 a little today. No problems so far. Expect to do more with Spflite over the coming days.
|
|
|
Post by George on May 26, 2015 12:23:41 GMT -5
drbob54: I almost dread your follow-up. -))
George
|
|
|
Post by drbob54 on May 26, 2015 21:34:09 GMT -5
George/Robert Having been in the same position several times over the past thirty years or so I do understand the level of frustration that builds after hours and hours of staring at code that should work.
If you use hex 28 instead of decimal 28, all a sudden February has 40 days instead of 28. I once wrote a mainframe exit that did exactly that :-)
|
|
|
Post by Jo on May 27, 2015 10:16:49 GMT -5
Robert, ha, reading thru the SPFLite code would take us some days, I think. But do you think, George wants us to look at his code ??
;-) Jo
|
|
|
Post by George on May 27, 2015 11:15:13 GMT -5
Everyone: Yes, the code is well past 50K lines. I have no problem sharing the code, I don't embarrass easily. ;-)) But really, where would one start, the code is in about 16-18 separate include files and the big ones can be > 10K lines. But if anyone truly wants to tackle this, fine, I'd wish them luck.
Robert: I gather then that you're still a no-no for GDrive sharing?
George
|
|
|
Post by Jo on May 28, 2015 4:07:54 GMT -5
Had another occurence involving just F5 (rfind) und Cursor movement (down). As this was easy ro remember, I retried the scenario, but - not reproducable. So I think, the problem is not solely within SPFLite, but depends on some other external (Windows) events that might occur. I think, there were at least 2 reports of this problem with doing nothing (came back after coffe break / left overnight and in the morning was dead). So, what about a small internal tracetable where external events (and whatever would help) are recorded. And a special command to write it to external storage.
Jo
|
|
|
Post by George on May 28, 2015 10:01:35 GMT -5
Robert: Ooh! please don't suggest that somehow I'm packaging virus type stuff, we don't need that rumor going round. As you know, when I rebuilt the system, I was super careful, paranoid almost, to ensure I kept it clean. And the virus I got caught with was a browser adware/popup generator only, it didn't affect any other aspects of the system. But none of the AV 'solutions' could get rid of it (amazing to me) and I really couldn't live with an almost totally crippled browser, so I bit the bullet and re-built.
As to the symptoms, the usual one was simply that SPFLite almost totally stopped refreshing the screen. It appeared keyboard traffic was being handled, but no responses. This seemed to occur randomly, I had it once while just typing, sometimes it's after returning after a long 'sleep', no real common trigger at all.
I had high hopes for the last version I put out (825145), and I hope these latest reports are from THAT version and not some older attempt. Well, actually I hope they ARE from an earlier version. ;-))
Trace log, possible, but could get very large, very fast. Windows just loves to post messages to a program for everything under the sun. Maybe I'll try and create a version like that and see what it looks like. Can't be internal, once it goes dead, how would we trigger a write of it?
George
|
|
|
Post by Jo on May 28, 2015 17:39:44 GMT -5
We know, that even when SPFlite has stopped to write on the screen, it reacts on commands: SAVEALL COND still writes all changed files, EXIT writes SPFLite.INI and SPFLite.SPS. Therefore writing the tracelog could be done with a command - mapped to a nice key.
But when Windows continues to send a lot of messages, how do we know when and where in the trace the problem started ?? So maybe we need 2 commands, one means "Stop tracing, problem is there!" and the other "WriteTrace"
Jo
|
|
|
Post by Jo on May 29, 2015 3:01:21 GMT -5
Robert, yes, I remember the days when we used GTF EXT-trace, this gives lots auf I/O. But there were another trace table which was internal, in a memory buffer keeping the last hundrets trace entries. In case of ABEND,DUMP it was written out. The problem here ist a bit different, because SPFLite does not crash or ABEND and is not aware of the 'going dead'-occurence. SPFLite continues to work as usual, except we don't see the screen updates. Therefore the internal trace table, when written round robin, would soon get overlayed with later trace records. And even when we would use the EXT method and doing i/O for each event, there is no point where we can say "here it is, this is the time it occured!". Not easy.
Jo
|
|
|
Post by drbob54 on May 29, 2015 8:34:04 GMT -5
The problem has occurred a couple of times 5145. The only consistent symptom is the change in the tabs and the status lines I would say occurs almost every time. This symptom has been there from the very first time I reported the problem.
If you look carefully at the screen shots I posted it would appear that the size of the font has been reduced slightly in the tabs and in the status line (like from 10 point to 9 point).
|
|
|
Post by George on May 29, 2015 12:20:16 GMT -5
I don't know how useful it will be, but we have to try something here. I've added some trace output showing the Windows callbacks. If nothing else, maybe I can see some unusual sequence of calls occurring when the 'going dead' happens. The log is written to SPFLite82.Trace.log in the \Documents\SPFLite folder. Every execution uses the same file name, so there will never be more that 1 file present. All I can ask is that when running this version, and the problem occurs, perform the SAVEALL etc and shutdown using the minimum input (i.e. KB only, not via the mouse). Then immediately copy the .LOG file away so it doesn't get clobbered by the next SPFLite run. Attach it to a note here, and I'll see what I can find. There's another trial version located at www.spflite.com/Files/SPFLite825149.ex_ As usual, rename it to SPFLite.EXE and move to the normal Install folder. Robert: This should also have in it the fixes for the last couple things you spotted in FM NOTE handling. George
|
|
|
Post by George on May 30, 2015 12:42:05 GMT -5
Just grabbed it, will start testing. FYI, when "Note" is disabled on FM, you are not showing "Note" as a heading, and are not showing the note fields as underscores, but you are still allowing room for them. So, in my case there are 20 blank columns I can't get rid of on directory lists, unless I go change the Note field width. Any way you can stop displaying a "null" Note column? That would be a better use of screen space.
You asked for suppression of Note columns when they were not valid entry areas for the current FM Display, that's what you got. I tried it with removal of the column space, but that made the columns to the right of the Note column jump left and right as you select different FM displays. I found that very jarring. As to screen space, I'm sure you run with the screen wide enough to display all the FM columns (when Note is present) so all you would 'gain' is white space at the end of the line. If other users even understand what we're talking about, and have some opinions to offer, then let's hear them.
Update 1: Downloaded the code, starting poking around, found this: In FM, put the cursor somewhere on the middle of the command line, using LMB. Press Enter. Now, the cursor is in the home position, but in the location in the middle of the line, there is a reverse-video blank. There seems to be some kind of screen refresh bug here.
Corrected. All wrapped up in the kludgy code to handle clicks in the command line.
Update 2: I was entering Note files in my File List, when I got an "illegal command" error message. The message showed up because the characters "-//-" suddenly showed up on the command line (no quotes). Intrigued by this, I took a look at the log file. I had only run the 4149 build a few minutes, and there was already 7069 lines; I know log files can get long. What I found interesting is that "WM_DRAWITEM StatusBar" appears 4,676 times, and 'WM_MOUSEMOVE' appears 1,985 times, leaving 'other' actions 408 times. Of the remaining actions, there was 243 WM_USER, 25 WM_ACTIVATEAPP, 32 WM_DRAWITEM TabHilight, and 7 WM_ContextMenu in addition to a few mouse wheels, sizing and so on.
Log files are hard to understand at best, and it's even worse when I don't know the code, but these numbers seem odd. The biggest question is why do you redraw the status line so many times? I only had one screen up. Why so may tab highlights going on for one tab? I don't know what WM_USER is, maybe that's innocent. Could it be that you are redrawing the status bar too often, and maybe that is interfering with something else?
OK, the -//- is weird, there's no literal in the program containing that value.
As to the trace, welcome to Windows callback routines. The traced entries are just the calls that windows makes THAT I DO SOMETHING WITH, you're not seeing any trace of the entries that Windows calls the program with, that I simply ignore. And the Statusbar draw is called for every BOX in the status bar individually. I have had to debug single step through this junk, it is absolutely amazing that it works. You get the feeling that Windows should be using 100% of the machine all the time just to stand still. It shows how incredibly fast our current computers are.
As to it interfering with something else, I doubt it. I stress again SPFLIte is a single thread program, no matter how hard Windows might like to hammer on the Callback routine, only one message at a time can be removed from the queue and processed. And processing is single thread - always. This is how you get the "xxxxx program is not responding" message from Windows; it's passed a message to a Callback routine and it has not returned in 'nn' seconds (whatever interval windows uses.)
BTW, when I was entering notes, I would put the cursor on the beginning of one note, then issue a cursor up. Instead of going to the note on the prior line, the cursor jumped to the leftmost position of the line-cmd field on the prior line. But, when I tried it again, the cursor up worked properly.
I can't get it to fail, up/down/left/right/tab/Backtab all work just fine
George
|
|
|
Post by George on Jun 1, 2015 10:47:53 GMT -5
Robert: Sorry, but my understanding from the others was that SPFLite DID respond to commands (They mentioned using SAVEALL COND etc) so I've been assuming it was only that the screen was not being redrawn.
I've sent you (on GDrive) an updated one which will display what I wanted on every termination, no command needed.
As to the flashing taskbar Icon, that is interesting, the only thing that could trigger that is a filewatch notification for the active file tab. e.g. if you had also updated the file in the IDE. I'll check into trying to duplicate that.
George
[Edit] No the flashing is not filewatch. The notification popup does not occur till SPFLite gains focus AND the appropriate tab is the selected one.
So I've no idea why the tab would be flashing. Is it a clue? Probably. But nothing comes to mind, SPFLite has nothing running in the background other than the FileWatch monitoring for outside file changes.
George
|
|
|
Post by Jo on Jun 1, 2015 13:21:23 GMT -5
The Trace.Log is about 1,2MB, so I attach it as .zip file SPFLite82.Trace.zip (12.11 KB) Had 3 Tabs: 1. Browse "Recent Files.FLIST", 2. Browse "Resent Path.FLIST", 3. Edit "DSINF.REX". After some editing I started my Macro "RunA" (copy all data to .../RUN/ folder und starts RunA.bat). NOTIFY ALL was active, therefore I got the popup "Recent Files.FLIST" was changed. I pressed "Yes". And after some F9 (swap) I realized the "dead condition". Pressed Ctrl-S (SAVEALL COND) and F4 (EXIT). Both commands succeeded: my .rex was saved and SPFLite ended. This same sequence (changing my .rex, starting my macro, answering "YES", swapping around with F9) I did at least 10 times before in the same SPFLite session without any problem. Jo
|
|