Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 2, 2017 9:26:57 GMT -5
I've upgraded to 8.5.7027 and discovered the new option to highlight recent/active dates. I haven't decided if I want it on or off. I would like to see two new enhancements. An option to turn on/off horizontal hairs in that screen. It would be easier to read a many lined directory. An option to turn on/off vertical hairs is ok but not a requested enhancement. My second request is to be able to see how many lines are in that member. The current number of bytes is ok but I think the number of lines is more like what I remember in my ISPF days. I love your product and use it daily.
|
|
|
|
Post by George on Feb 2, 2017 12:04:25 GMT -5
iprefer432:
Adding the number of lines is not likely as it would be a very significant performance hit as it would mean reading the contents of every file being displayed. That's fine if you're looking at a short list of simple text files. Picture pointing FM at a large folder of thousands of files with mixed formats etc.
The crosshairs on FM would be a bit hairier to implement since FM and the edit screen do not share the same display code. I'll have a look at doing so. Maybe you could try using the banding support for the screen background? I use it and find it quite helpful for tracking the horizontal alignment.
George
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 2, 2017 12:36:43 GMT -5
George,
Thx for your answers. I'll look into banding support.
iprefer432
|
|
|
|
Post by George on Feb 3, 2017 15:50:33 GMT -5
Had a look at this, and it appears more straightforward than I thought. It should be available in the next release.
George
|
|
|
|
Post by George on Feb 4, 2017 12:17:02 GMT -5
If we were satisfied with STATE based values this could be possible, I'd still have to benchmark some timings for the additional overhead. For each item FM would have to: - Determine if the filetype has STATE ON - this is a file open/read/close activity for the Profile, but this could be alleviated by building some filetype cache table so the I/O activity only happens once. And I don't see it being responsive to having STATE ON/OFF being dynamically flipped back and forth.
- FM always refreshes the display contents, this is to maintain up-to-date time stamps etc. I don't see any caching going on here, so there would always be some I/O to the STATE file for the relevant files.
- There is no additional work to collect the line count, this is already maintained in the STATE file header record.
Biggest effort is making changes to the FM display routines to handle a new data column type. This is definitely non-trivial; remember, unlike ISPF, it is not just some editing of a Panel Library member.
If people really want this, speak up. No interest, no development.
George
|
|
|
|
Post by George on Feb 10, 2017 13:05:59 GMT -5
Robert: This was always the problem when we were actively into adding bells and whistles; we were doing it in a vacuum hoping the feature we were adding really were useful. I'm afraid you are quite right, people just fall into a pattern of becoming very proficient in using a small subset of the available tools, and never explore to see if perhaps there's a better way.
I can remember back in the mainframe days, our group (Software Support) was expected to spend 1 shift a month down in operations in an attempt to pass on tips and tricks etc. to make their jobs easier. Basically, we all came back appalled at how they worked. I can remember senior operators with their little black book full of painful, step by step instructions on how to do something, most of it now superseded by more efficient methods, but who stubbornly clung on to their old methods. "It works! Leave me alone. I don't care if there's a better way."
Apathy? Inertia? Stubbornness? I don't know, but it's impossible to overcome.
George
|
|
|
|
Post by George on Feb 11, 2017 11:55:18 GMT -5
Robert: If I get bored enough, maybe. As I indicated, it's mostly work in the FM display routines to add another optional data column. It's only messy because of the flexible, user specified column selection and placement, column sorting etc.
Right now I'm looking for an obscure bug I spotted while doing that small change for the FM horizontal/vertical cursors. It's in the cursor handling for the Cmd line, but so far nobody has spotted and reported it - quite amazing actually. Of course it's being maddeningly obscure.
George
[Update] Wow! This bug has been around since - well - forever! If typing into the Command line, and the KB is in Insert mode, and the cursor is past the end of the existing line contents, the entered character is simply appended to the end of the existing text. Hard to believe it's gone unnoticed for so long.
George
|
|
|
|
Post by George on Feb 13, 2017 12:30:04 GMT -5
I have run into two bugs myself, one is trivial and one is a bad one. Trivial bug: when SORT MARKUNIQ was added, the subsequent command to do X ALL U works fine, but if you try X ALL V, it ought to exclude all lines that are not U lines. It doesn't. Instead, it seems to randomly exclude lines, without regard to the U/V status. Workaround is to do X ALL U and then FLIP ALL. -- I'm not sure what you think X ALL V should do, but V is NOT an operand of EXCLUDE, so the V would be treated as the simple literal V and the lines excluded would be those containing a V/v (depending on your CASE default)(p.s. some day if you're *really* bored, FLIP with no other parameters whatsoever ought to work like FLIP ALL. no big deal, but it would make it ISPF compliant. I know it messes with your cmd handler, so I won't whine if you can't/won't do it.) -- Shouldn't be difficult, I didn't know it wasn't ISPF compliant, I remember you pushing com-pliancy a lot, the parser doesn't affect this. I'll have a look.Bad bug: You remember that bug where temp UNDO files were getting created with wild/corrupted names and were gigantic sizes like exactly 800,000 bytes? It still happens. Seems to happen a lot with pasting large clipboards. The corrupted names usually do not have any file extensions, but the names will have garbage in them, like unprintable characters, and text data from the file itself. For instance, if I have a program file, and a line of text had A = LEFT$(B,3), after saving it or maybe after pasting a bunch of data into it, there might end up a temp file called "EFT$(" with a file size of 800,000 bytes. Since I rarely create files without a file extension, I just have to periodically look for these weirdo files and delete them. My larger concern is that if I happened to have a file with no file name, it might get plastered by this, and then I'd lose data. I can usually tell when this happens, because some action that *should* happen quickly all of a sudden takes a very long time, and SPFLite appears to go dead/hang up for a few moments. As I often say, ... hmm ... -- THIS I remember and I did put a lot of effort into tracing EVERY file open in the program in an effort to catch this. Had this code running in my test versions for months and the logs never showed anything unusual. The file names and the allocation for the UNDO data files are all handled by Windows, all SPFLite ever knows about them is the filename assigned. I've no ideas as to how to further chase this. Here's how they're allocated:
FUNCTION sGetNewTempFile(pfx AS STRING) AS STRING
'---------- Get a Temp file allocated
LOCAL lpTempFileName AS ASCIIZ * %MAX_PATH
LOCAL lpShortPathName AS ASCIIZ * %MAX_PATH
LOCAL lpszPrefix AS ASCIIZ * 20
LOCAL r AS LONG, fn AS STRING
MEntry
lpszPrefix = pfx '
r = GetTempFileName(sGetWindowsTempDir, lpszPrefix, 0, lpTempFileName)
IF ISFALSE ISFILE(lpTempFileName) THEN '
'WinAPI indicates if "." is present then use current applications directory
r = GetTempFileName(".", lpszPrefix, 0, lpTempFileName) '
END IF '
fn = sGetShortName(lpTempFileName) ' Shorten the name
FUNCTION = fn '
MExit
END FUNCTION
Not a bug, but an annoyance: If you have an existing file (say, several thousand lines) then you put an A on line 1 and paste a large clipboard into the edit file (say, 500-1000 lines), it works but *brother* is it slow. It is acting like you are "pushing" down the entire existing file to make room for one line, then you do the same thing again, over and over again. I think the only way to fix this is when you do a PASTE, you'd have to do a pre-scan to see how many lines you'd dealing with, then allocate space in the edit file for all of them at the same time. I suspect the effort required to implement something like that would be pretty steep.
-- You're correct in your assumption. PASTE is one of those command that "just grew" as we added options, and a lot of old inefficient code got cloned and massaged. It all works, ... but yeah, it's not too swift. The simple case A/B should be readily fixable, the others AA/BB/HH etc. get a lot trickier. Still, I'll see what I can do.R |
|
|
|
Post by George on Feb 13, 2017 16:55:00 GMT -5
Robert: Well if we're going to start second guessing that the temp file Windows API's might have screwed up (due to memory corruption or whatever), then really, we should put in validation code after EVERY Windows API call because now we don't trust them to have worked correctly. And since most of the PowerBasic intrinsic I/O functions are simply wrappers for Windows API calls, we should add validation code to all them as well.
Ludicrous of course. I'm not disputing that you're seeing a problem, but we basically tried this approach when you first reported the problem. True we just logged stuff, and didn't do pop-ups etc. but with several months of logging, nothing showed up. I'm not exactly chomping at the bit to re-invent that wheel again.
George
|
|
|
|
Post by George on Feb 14, 2017 16:35:28 GMT -5
Looking at your code above, I see that when you retry GetTempFileName, you don't recheck the RC. If the function failed but you used the string anyway, it could be garbage. Since all of the file name strings are LOCAL, they would have any leftover junk still on the stack. That would explain why the weird file names get created. I suspect this is the problem. What I can't quite figure out is why the function is failing. But, I believe you should at least add the RC check after the second call.
-- I don't check the rc for the simple reason that most programmers don't check the RC after every single API call, it's not needed. Go browse sample MSDN code examples for many API's and you'll find MS examples don't check rc's after the calls; why? Because trivial API's just don't fail, and don't need to be checked.
As to it having potential stack garbage remaining in the variable, it's not possible as all LOCAL variables in PowerBasic are initialized to zero or null, based on their type.
FYI, I got the Visual Studio help for GetTempFileName, and they mention that the "prefix" thing is used to help create a unique file name. If applying the prefix doesn't result in a unique name, Windows will increment some kind of serial number and retry creating a name until it succeeds in making the name unique. They say that if there are a lot of existing temp files, and you are creating a bunch more, it can be very time consuming. This leads me to believe that (a) you ought to be sure to delete old temp files when you sure you don't need them, and (b) you should aggressively modify the prefix string to help in the file-name uniqueness test.
-- Yes, all the names I see for UNDO files are UNDxxxx.tmp format. As to cleanup, SPFLite has been cleaning up any residual unwanted UNDO files for a very long time, so there should be, under any normal circumstance, very few, if any, such files.
I also believe I read something that suggested that Windows only uses the first 3 characters of the prefix. If so, your temp prefix string ought to be more like DIM TEMP_PFX ASCIIZ * 4 rather than 20. (+1 because of the NUL)
-- Well, the routine has been called with "UNDO" as a parameter for many years now, and the files all come out as UNDxxxx as you indicate, so the API obviously doesn't care about getting extra characters. MSDN says it will use up to 3 characters of the string, and the string is defined as a normal _In_ LPCTSTR lpPrefixString, not a fixed (4) string, so the length shouldn't matter. Changing something, even so trivial a change, when it obviously works just fine, and follows the API specs, just because you have some hunch that it might not have worked isn't going to happen.
I think going down the path of "maybe the API isn't working, we should somehow validate that it has indeed done it's job" is not the way. I don't know what way it should be, but it is certainly not by adding validation code such as this.
So --- for any and all other users reading this, has anyone else experienced what Robert is describing? At this point he is the only one. I myself have never seen it, but if this is truly a bug, then some of the rest of you should be seeing this. And if I get responses saying it IS common, I will back down and somehow find it.
George |
|
|
|
Post by George on Feb 15, 2017 11:52:29 GMT -5
Robert: Yes, obviously a new TEMP folder would work, but that overrides and ignores the user's own specification of where TEMP files should go. I seriously doubt a DIY piece of code would be any faster then the API, why should it?
The only reason to go DIY is if there is serious doubt that the API is working properly. Considering the number of temp files created by apps in Windows every day, I can't believe that API is suspect. Whatever possible bug is causing your problem, is elsewhere.
George
|
|
|
|
Post by George on Feb 17, 2017 12:56:30 GMT -5
Forgive me for pointing this out, but I never really said the *API* is at fault. It's not. You have a bug in your code. I don't say that to be disrespectful, it's just a fact. I understand your motivation in not checking every RC, but you need to consider that a bad RC usually is the result of invalid user-supplied parameters. I never said the Windows API itself "failed". There really should be an RC check where you omitted it. That is how the API is documented. If it ever returned a failure status, that would be how you'd know if something was wrong, and at least we would have something to go on. -- I already stated that if this is reported by others, and is indeed a more generalized bug, that I would somehow chase it till found. As to invalid user supplied parameters, in all cases the routine is called with a literal constant. And if that is mucked up, it would almost certainly mean some kind of memory corruption, and that means that every routine in the program could be a potential suspect. And trying to scan over 60K lines of code looking for some piece of code to wave a flag and say "Me, I'm guilty" is just not going to happen.
If it does turn out to be a more common bug, how would I chase it? I haven't a clue right now. It can't be done by adding some RC checks and "let's see how it goes" -- add a few more and "let's see how it goes" etc. There has to be some trigger activity, and until I can make it fail, I can't fix it - a fact of which you're certainly well aware. On a related topic, it seems if this is a real situation, some other users must have seen it happen. I wonder if anyone else has seen this? Did anyone else report weird temp file behavior? I'd like to ask all the users to respond, but as we know, they aren't very responsive these days ... All we can do is hold our breath. |
|
|
|
Post by George on Feb 19, 2017 12:43:23 GMT -5
Robert: OK, I can only get beat up so many times. I've altered the code as below to try twice, check the RC and then to fall back to an alternative routine to create the file. I'll post this version in DropBox for you.
George
MEntry
lpszPrefix = pfx ' Get Prefix to ASCIIZ
r = GetTempFileName(sGetWindowsTempDir, lpszPrefix, 0, lpTempFileName)
IF r = 0 THEN ' If Failed, then try current folder
r = GetTempFileName(".", lpszPrefix, 0, lpTempFileName) '
IF r = 0 OR ISFALSE ISFILE(lpTempFileName) THEN ' If failed again or can't find the file '
sMakeNullFile(pfx + FORMAT$(TIMER) + ".tmp") ' Try one last time
lpTempFileName = pfx + FORMAT$(TIMER) + ".tmp" ' Adjust filename passed back
MSGBOX "GetTempFileName failed twice, allocated manually"' Tell user
END IF '
END IF '
fn = sGetShortName(lpTempFileName) ' Shorten the name
FUNCTION = fn '
MExit
|
|
|
|
Post by George on Feb 20, 2017 12:08:28 GMT -5
Robert: Pick it up again, I corrected a small coding error. I used TIMER twice in building the name, a no-no. It now reads:
lpTempFileName = pfx + FORMAT$(TIMER) + ".tmp" ' Adjust filename ourselves
fn = lpTempFileName ' Make normal string for sMakeNullFile
sMakeNullFile(fn) ' Try one last time
MSGBOX "GetTempFileName failed twice, allocated manually"' Tell user
|
|
|
|
Post by Jo on Mar 7, 2017 22:51:54 GMT -5
Some late answers to your questions: Yes, I would like a "Nr.of Lines" in FM, if easy to implement. And - if you really dive into FM-code - there is an old point on my wishlist: Sometimes it would be nice to see the full path in FM, not only the names. And not only to see the path, but also be able to sort by path&filename. TempFiles: Files are in %temp% and they are named UND?  .tmp. But there are about 30 of this UND*-files just after starting SPFLITE. There is only one Browse-Tab because of "Re-Open last file(s) at start". One of the UND*-files contains data from the Browse-Tab, another UND*-file is about 10KB and contains 5000 "0"s and 5000 "1"s, and one UND*-file has 800080 Bytes. The other 27 UND*-files are empty (0 Bytes). I don't see any bad filenames. PC runs Win10 Pro, 32-Bit Jo |
|
.tmp. But there are about 30 of this UND*-files just after starting SPFLITE. There is only one Browse-Tab because of "Re-Open last file(s) at start". One of the UND*-files contains data from the Browse-Tab, another UND*-file is about 10KB and contains 5000 "0"s and 5000 "1"s, and one UND*-file has 800080 Bytes. The other 27 UND*-files are empty (0 Bytes). I don't see any bad filenames. PC runs Win10 Pro, 32-Bit