|
Post by Stefan on Apr 5, 2021 15:00:16 GMT -5
George, Revisiting FLISTs form earlier, I have a list named _SPF.FLIST. I read the FLIST 'chapter' in the latest v2.4beta Help DOC to determine the naming standard for _ABC.FLIST files, but found no mention of that type of list.
My _SPF.FLIST works just fine. It appears on the FM Tool bar as _SPF and can be accessed by clicking on its name or via RECALL. When I renamed it to _SPF Folders.FLIST, it appeared as _SPF Folders on the FM Tool Bar, but RECALL doesn't like it ("Excessive operands for RC command")
I had a vague recollection that the toolbar would only show the first word of the list name anyway. I'm happy it shows both words, but either users should be prevented from using spaces in the name, or RECALL should tolerate it.
I also have a related question...
All path-name entries in the "Recent Paths.FLIST" end with just a single '\'. This is contrary to the description in the HELP doc and I think you must have deployed extra code specific to that list name. Given that the '\\\' ending is now supported to (I think) do exactly what 'Recent Paths' needs, is there an opportunity for code simplification and avoidance of user confusion if they peek within 'Recent Paths.FLIST'?
|
|
|
Post by George on Apr 5, 2021 15:09:07 GMT -5
Stefan: Yes cabling is a nightmare, and with my mobility disappearing, getting down on the floor, flashlight in hand, and poking and prodding at power cables, ethernet cables, USB cables, power bars etc. and trying to thread all these cables in, out and around the cramped access within the armoire is no fun. Let alone getting back up again.
But the armoire has served me well, it's about 25 years old, and as long as I keep everything within it, the wife is happy. If need be, the doors can be closed and all my clutter is out of site.
Before we moved into this condo, I had an L-shaped desk like you, both sides were full size desktops, in a separate room as well. But downsizing from a 4 bedroom house to a 1 bedroom + den condo means giving up a lot of space.
Can't complain, this place has no stairs, the house was a 4 level side-split, stairs everywhere, my legs couldn't take it anymore.
George
|
|
|
Post by George on Apr 5, 2021 15:15:25 GMT -5
Stefan: I'll check the Doc. but paths in FLISTS were always supposed to end in \ to indicate a path, vs no \ to indicate a full filename.
That was extended to \\ to indicate a full recursive path search.
And further extended to \\\ to indicate a path selection entry (like Paths).
If that's not what the Doc says, I'll correct it. But that's the intention.
George
|
|
|
Post by Stefan on Apr 6, 2021 2:34:56 GMT -5
Sorry, I was being stupid about the 'Recent Paths.FLIST' Don't go on a wild goose chase, everything is fine. I mistakenly thought that 'Recent Paths' only included the paths which I had visited recently. I did see the lower level names, but I also did access those, so thought nothing of it.
I now realise that 'Recent Paths' does in fact include '...the path name plus any lower level path names' by design.
So the fact that the entries in that file-list all finish with a single '\' is perfectly correct.
Some days, I hate getting old, but most days I much prefer it to the alternative!
===> I live with the alternative. Trust me, you wouldn't like it - R
|
|
|
Post by George on Apr 6, 2021 9:44:47 GMT -5
Stefan: OK, I'll drop this (hadn't got to it anyway).
George
|
|
|
Post by George on Apr 6, 2021 9:47:41 GMT -5
All: I think it's time to roll out 2.4. There have been some suggestions lately, but nothing significant as far as bugs.
I haven't posted a new Beta with the last couple enhancements, I'd rather do an actual roll-out.
So if you still have problems that I haven't said are corrected, now's the time.
Oh, all the cleanup, removing old aliases etc. is NOT included.
George
|
|
|
Post by Stefan on Apr 8, 2021 9:31:04 GMT -5
George,
Two aspects with FM display and FLISTS, which I think need tweaking before general release.
(1) The SORT sequence for the FM Path column
With PATH showing as PATH+... ...why does does C:\ONE\TWO\ sort ahead of C:\ONE\ ?
Usually an ascending sort (as in PATH+) would sort the shorter string BEFORE the longer string. The only way I can achieve that sequence is to sort PATH- But then in an FLIST containing more than one Path, the other Path entries are also reversed. I think you need to look at why the sort sequence is different to any other, anywhere else.
(2) The FM display for FLISTS containing path entries that finish in a single '\'
In this case, any sub-folders below the named paths are displayed in the DIR/NAME column simply as 'foldername\' So you cannot tell in which path those sub-folders are to be found. It is even more confusing if separate path entries in the FLIST happen to contain sub-folders with the same name.
I figured this is easy to fix by adding the PATH column to the FM display, but this column is currently only populated for FM rows that have a filename in the DIR/NAME column.
If there's a folder\ name in the DIR/NAME column, the PATH column is blank. You need to populate the PATH column for all rows on the FM display, not just for those that contain filenames in the DIR/NAME column.
The display is better for FLIST entries that finish with '\\' because, by definition, all FM rows will contain file names.
If you add the PATH column to the FM display, it is easy to see in which path each filename is located. (This lead me to spot the odd PATH sorting sequence). FLIST entries finishing with '\\\' are unaffected, by design.
|
|
|
Post by George on Apr 8, 2021 10:14:33 GMT -5
Stefan: Re: SORT paths. I set up your config, it sorts just fine. See the last 2 lines in the attached image. I'll have a look at populating PATH consistently. George
|
|
|
Post by George on Apr 8, 2021 11:20:33 GMT -5
OK, at least one more Beta is obviously needed, so check the 1st post in this thread for the download link.
George
|
|
|
Post by Stefan on Apr 8, 2021 16:50:01 GMT -5
George,
Re SORTING - Sorry, I messed up the verbal description before.
When I said
"why does does C:\ONE\TWO\ sort ahead of C:\ONE\ ? "
I actually meant to ask
"why does C:\$USER\ONE\TWO\Common* sort ahead of C:\$USER\ONE\TWO\
This was generated on the earlier beta (v2.4.21090) but the same applies to latest one, v2.4.21098.
To test, I have just one line in my _SPF-Folders.FLIST C:\$User\ONE\\
The result for the PATH+ sort is as displayed below.
Note the bottom line, C:\$USER\ONE\TWO\ appears after the two C:\$USER\ONE\TWO\Common* entries. If I sort PATH- this is corrected, but if the FLIST contains more than one entry, all would be sorted in descending order as well.
|
|
|
Post by davecheckley on Apr 9, 2021 2:54:43 GMT -5
George, AVG reports your zip file (21098Beta) and CFGMaint.exe as infected with Win32:Evo-gen [Susp]
I can report it as a false positive if you're sure it is clean.
Regards, Dave
|
|
|
Post by George on Apr 9, 2021 10:40:27 GMT -5
Dave: Yes, it's clean. False positives are a royal PITA.
George
|
|
|
Post by George on Apr 9, 2021 10:53:05 GMT -5
Stefan: Boy was that sort bug a weird one. Most of the column sort routines do the same thing. In building the sort key, they append the filename so that within equal primary sort keys, the entries will at least be in filename order.
So in your case, there are both files and folders within a folder. Examine the names in your sample, and consider appending filenames to pathnames.
C:\$User\TWO\ contains a file named Filein 1-2.txt along with folders \Common11 and \Common 12
So, building the sort keys:
C:\$User\TWO\Filein 1-2.txt is greater than C:\$User\TWO\Common11 and C:\$User\TWO\Common12
Easily fixed however, I just insert a single blank before the appended filename.
George
|
|
|
Post by Stefan on Apr 9, 2021 13:00:49 GMT -5
I think I understand what you mean. I think you're saying that the string C:\$User\TWO\Filein 1-2.txt sorts AFTER the string C:\$User\TWO\Common11.
That's fair enough, BUT... what I don't understand is why a FILEname should be part of the PATHname sort sequence.
If I want to sort the display by Filename, I'd click on the "Name" heading until it showed what I want. If I click on the "Path" heading, I expect the display to be sorted according to that columns content, and that column doesn't include the filenames.
Are you doing some kind of 'two sort keys' implementation? If so, what would I expect to see is the display sorted by Filename WITHIN Path.
I'm looking forward to the result from your fix.
PS: Yes, there are files AND Folders at each level - done deliberately so I can see which bits are listed by the various \, \\ and \\\ scenarios.
|
|
|
Post by George on Apr 9, 2021 13:13:47 GMT -5
Stefan: Like I said, the filename is internally added so that when a list has a whole bunch of files from the same path (i.e. equal sort keys) that the filenames within each equal path key are not just random, but are themselves 'in sequence' by filename. I seriously doubt anyone would want items within an equal major sort key to just appear randomly.
So yes, nearly every column sort is, in reality a multi-key sort. e.g. that's how Dir+ Dir- and Dir* positioning is handled, the Dir entry types are actually the major sort key (or ignored in the Dir* case).
George
|
|