|
Post by Stefan on Apr 1, 2021 10:01:59 GMT -5
George, Sorry to report stuff in drips and drabs, especially just after you revised the code...
This comes from v2.4.21088 so a couple of days back.
First odd thing.... My FM PATHS display looks like this... spot the oddity, (the red ring helps). I hasten to add that the The "RECENT PATHS.FLIST" has not been manually modified, only by what SPFLite does to keep it 'recent'. I do have an entry in a _SPF.FLIST which has three '\' at the end of the MACRO folder's name.
I suspect the effect may be due to you adding support for 3 '\' at the end of the entry names.
Second odd thing... happens with the RUN command in Edit.
It is not consistent, but as you recently tweaked RUN, a gremlin may have crept in.
I'm EDITing a file called TRY.REX which I use to quickly try out code, or maybe time alternatives to see which runs faster. So typically, I enter a chunk of code and use RUN to test it without saving it.
Recently, I get occasions when RUN doesn't work at all. Today I had a clue in that RUN did work, but executed a version of TRY.REX which was older and different to the one I was looking at. Examining the S:\DOCUMENTS\SPFLITE\RUN\ folder, I see two files therein, one call TRY.REX (older) and one called just TRY (dated today)
So under some circumstances, which did not used to arise prior to the recent RUN changes, the temp RUN file doesn't inherit the correct filetype for the file being edited. (e.g. .REX) in my case.
|
|
|
Post by George on Apr 1, 2021 12:20:34 GMT -5
Stefan: It does sound like the recent \\ and \\\ support is confusing the RECENT updating, should be easy to track down.
Same with the RUN thing. I'm getting sloppy.
George
===> Just remember, George, you WANTED to update FM :-)) be careful what you wish for - R
|
|
|
Post by George on Apr 1, 2021 14:19:39 GMT -5
Robert:
? ? ?
I'm sorry, but the only reason that column exists is - YOU. I never would have added it on my own.
From your email - Jan 29th - a comment by you about the Recent lists
So I revised the Recent handling to provide better dates, and some kind of context. Now you say it is 'clutter' and taking up valuable space.
As to making the NAME field bigger - go ahead, it will push the MODE field off the right and you won't see it anymore.
And if you feel the MODE is useless, I'll remove it, nobody else asked for it, and if you don't want it, then it really is useless.
George
|
|
|
Post by George on Apr 1, 2021 14:44:30 GMT -5
Stefan: OK, both the Recent and RUN things have been resolved.
George
|
|
|
Post by Jo on Apr 1, 2021 16:48:23 GMT -5
ad "Mode" and "LRDate": I dont't need them. There is no useful information for me, because I see "LWDate" - this is the last date I changed something. That's the date I need. The old "aging logic" of "Recent File" & "Recent Path" was totally sufficient and straightforward.
Jo
|
|
|
Post by Stefan on Apr 2, 2021 3:08:31 GMT -5
Guys,
I wondered about the MODE column and had it on a list to ask about later. At first I thought it showed me which files/paths had sessions OPEN, but realised after a few days that didn't make sense. I reckon you can remove the MODE column if Robert is OK with that. Also on FM, I'm confused by the LINES line command. What SHOULD happen? I figured it would display the Line count in the file for files without STATE ON, but it just gives an error message that STATE isn't ON. I know that! That's why I requested a Line count! If STATE were ON already, the LINES column would tell me the count without me having to ask. With LINES now being a 'selectable column', I wonder if the LINES line command is either superfluous or should actually run through the file counting the lines on request.
|
|
|
Post by Stefan on Apr 2, 2021 6:03:38 GMT -5
George, Robert, et al
I have taken the liberty of posting some suggestions for enhancements to v2.4beta in the Suggestions thread. I'm fully aware that I may be stepping on some toes, so let me say in advance that I mean no disrespect to anyone responsible for how things work currently.
Version 2.4 introduces an number of really useful FM enhancements, so I felt this may be an opportune moment to step back and review the existing structure and appearance. To me (perhaps only me) FM "feels" like a distant cousin rather than a close member of the family. It exhibits lots of the same commands and line commands as Edit, but they operate subtly differently.
Anyway, have a look in Suggestions and feel free to agree, disagree, support, reject, or even further develop the suggestions.
I shan't be offended and hope nobody else is either. That wasn't my intention.
|
|
|
Post by George on Apr 2, 2021 8:47:18 GMT -5
Stefan: The LINES column simply displays the line count from the files STATE file (if that file exists). This means minimal IO to retrieve the value (open, read 1 line, close).
The Line command will basically do a STATE SAVE for the file, creating/updating the STATE file, then the count is added to the file's display. But if STATE is OFF (user doesn't want STATE, then nothing is done. I certainly don't want the line count to require an actual file scan, way too much overhead.
Now perhaps, the Lines command could, for files with STATE OFF do a specific scan, but the result would be temporary as there is no place to save it.
George
|
|
|
Post by George on Apr 2, 2021 8:56:22 GMT -5
Robert: OK then, Mode will be removed, no problem.
Jo: LRDate was added specifically for Recent Paths and Recent Files because it really IS the last reference. For normal files being displayed, LRDATE is meaningless because MS has totally mucked up how it is saved.
Previous FM Recent displays showed the LWDATE because that's all that was available. If you repeatedly Browsed a file, it continued to show the LWDATE, you couldn't tell when it was last used.
I could just internally shove the LRDate for Recent into the LWDate field, but then we'd have the Recent lists saying LWDate but displaying LRDate, -- don't like that.
George
===> Right, George. It's OK to confuse users but not to lie to them - R
|
|
|
Post by Stefan on Apr 3, 2021 12:00:39 GMT -5
George, Re: LINES line command With STATE OFF, a temporary display of the lines would probably be good enough, but I think you're right to question how useful it would be to scan the file and count the lines.
I can't help thinking that users for whom the line count is important would be running with a LINES column in FM and STATE ON. I can't really see why anyone who doesn't care about line counts would need a LINES command. They could just Edit/View/Browse the file and read STATUS line. So I guess I'm really questioning if LINES is needed. I take your point that it effectively 'refreshes' the STATE info, but as you know, I'm new to 'STATE ON' and thus far cannot see why a refresh would be a good thing to do. Even if an external app has changes the file, refreshing State info via Lines won't guarantee that my line labels, excluded lines, etc will be in the right place the next time I open the file in SPFLite. Maybe I'm missing something.
|
|
|
Post by Stefan on Apr 5, 2021 5:52:27 GMT -5
George, While looking at commands in FM, I've been playing with some that I haven't used before. OPEN - initiates a new SPFLite Window. I note that the new window EXACTLY overlays the old window.
That's resonable if the original SPFLite window was 'maximised', but it also happens when SPFLite is not running maximised.
That isn't actually very convenient, because the old window is inaccessible unless I move or minimise the new window first. Maybe the new window should overlap the old one with a slight offset.
For example, Windows Explorer opens duplicate windows, offset, down and to the right, by about the width of the windows' Title Bar.
Just a thought.
|
|
|
Post by George on Apr 5, 2021 11:59:55 GMT -5
Stefan: The problem is the new window has no idea it was created via an Open command from a running session, it's just as if you dropped the file on the SPFLite Icon. So it does as usual, opens up in what it believes to be the last position at close time.
Have to think about this one a bit.
George
|
|
|
Post by Stefan on Apr 5, 2021 12:44:58 GMT -5
Hmm... interesting... How about... If SPFLITE finds that another instance is already running, add 'n' to each of the 'last-used-at' screen co-ordinates and open new window there. If nothing is running, the window opens where it was before, if something is running, it opens offset by 'n'. If you can determine how many instances are already running, multiply 'n' by the count and offset the latest window by that amount. I doubt it would matter hugely if you overshoot a little. The user will just move it back manually. I note that even Explorer overlays its windows eventually if you open enough of them.
Sometimes it handy (especially with the luxury of two monitors) to open stuff side by side without having to swap between two tabs all the time.
|
|
|
Post by George on Apr 5, 2021 13:47:45 GMT -5
Stefan: That could work.
I'd like two monitors as well, but my setup just won't accommodate another screen. Everything is inside one computer armoire (it sits in one corner of the den) and with desktop box, monitor, two printers, speakers, woofer, modem, routers, external drives, fan and shelving there's just nothing left.
George
|
|
|
Post by Stefan on Apr 5, 2021 14:14:28 GMT -5
WOW. Sounds just like my "den-come-man-cave", except you have an extra printer. Alas, I switched the processor Tower and monitor for a couple of laptops and a 22" flat screen. Pretty much all fits on one L-shaped desk, except the amp & speakers.
The cabling and Ethernet switches for the Gbit backbone are a bit of a 'mare' underneath the table though.
So glad I have an understanding Wife!
|
|