|
Post by Stefan on Mar 23, 2021 6:39:45 GMT -5
A question/suggestion about FLISTs ....
Apart from the 'Recent Paths' FLIST, all FLISTs are focused on FILE names. I had hoped that the v2.4 enhanced FM would also introduce support for PATH-name FLISTs. If it does, I have thus far failed miserably to find out how to create one.
What I need, is the ability to create one or more.. user-named FLISTs,
ideally accessible directly from the FM ribbon (next to Recent, Found, Open, Favourite... etc) which provide a user-specified list of PATH-names optionally(!) the list content may be dynamic (ie. via a wildcard filter) but fixed is acceptable.
I think we should remove the constraint that files related to each other MUST always be stored under the same PATH-name.
Examples of usage:
(1) I have 'project' files in my personal (i.e. local on my C: drive) DOCUMENTS folder and files stored in the shared (i.e. on my NAS) DOCUMENTS folder related to the same 'project'.
(2) I have the SPFLite "Home" folder and the SPFLite "Data" folder in separate places (sorry Robert). CFGMAINT also populates files in the "Home" folder, some of which I view/edit/save/compare with SPFLite when maintaining the application. Other SPFLite data files (Auto, Macro, Clip, Flist... ) are in the "Data" folder elsewhere. I would like to build an "SPF" FLIST functionally similar to "Recent Paths" that references the "Home" directory PATH-name plus each of the ...\AUTO, ...\MACRO, ...\FLIST, \etc PATH-names from the "Data" directory
I can see that some of the required capability is now in v2.4beta FM.
What is missing, I think(!), is the ability to make a new FLIST containing PATH-names as opposed to FILE-names. e.g: I tried using the PATHS display, filered to show only SPFLITE path-names, but MAKELIST did not accept the contents as there were no File-Names.
If the capability already exists, I'd appreciate a pointer to a description of how to implement this.
(Note to Robert)
Please do not tell me that "Recent Paths" covers this. In my view, it doesn't for several reasons: - it is dynamic and therefore contents changes over time, in fact, the very path-name I seek may have "rolled off" when the entry limit is reached - over time it becomes larger, thus harder to peruse and slower to find the entry I want - depending on the path names and sort sequence, 'project' related file paths do not display together - Being the only 'path-supporting' list, it would have to cater for every 'project' the user has.
|
|
|
Post by George on Mar 23, 2021 9:18:16 GMT -5
Stefan: I think what you want is what I do with my _SPF.FLIST.
D:\Documents\SPFLite2\|*.BAS;*.INC D:\Documents\SPFLite2\Docs\|*.HND
Which displays the "working" files for SPFLite. It shows the code files from the main folder, and the HelpNDoc files from the Doc folder.
After the 1st use, I set the sort control to Dir- to push the folders to the bottom, out of the way. (This is remembered for _SPF)
You can put as many entries in the FLIST as needed to 'gather' the files from all the various locations. If additional filtering is needed, it can be added to the Filter Mask line and it will also be 'remembered' for the _YourName.FLIST.
Try it out. It does mean you have to EDIT the FLIST, just put an "E" next to it on the FLISTS display. You don't need to use folder names, you can also enter specific filenames (full path required)
There's a reasonable explanation in the Help file Working With section - File Lists (FLISTS). Make sure to use the Beta version of CHM.
George
|
|
|
Post by Stefan on Mar 23, 2021 13:58:31 GMT -5
George, Hmm, close, but no cigar...
I created a _SPF.FLIST file.
It appears in the FM Ribbon.
AFter some trial and error, it has four entries... S:\Documents\SPFLite\AUTO S:\Documents\SPFLite\CLIP S:\Documents\SPFLite\MACROS C:\$User\SPFLiteCFG
This gives my 60% of what I wanted - namely a list of PATH-names without FILE-names
I tried it with a trailing '\' at the end of the folder-names, but then I get a list of all files in each of the paths - not what I wanted. Adding a filter doesn't help as it only works on file-names, and I don't want any files.
I say 60% because ...
(1) BAD: It doesn't list the PATH-names which I entered in the _SPF.FLIST.
It only displays the very last 'section' of the PATH-name, e.g. AUTO\ instead of S:\Documents\SPFLite\AUTO I tried adding a PATH column to the FM Options settings. The column appears but it's all blank. (2) GOOD: If I click on one of the shortened path-names, FM shows me that folder's file content and sub-directories, if any. (3) BAD: If I press PF3 (END) I have the same issue as with "Recent Paths". I don't get back where I came from, ie the initial AUTO\ display.
Instead, FM navigates back via the actual folders' hierarchy.
i.e. I click on the AUTO\ entry and get to a list of all my .AUTO file. I press PF3 and instead or returning to the AUTO\ entry, I end up navigating back through the named path, S:\Documents\SPFLite\
So there is still an implied assumption that the 'project' files are within a given path (however long that path may be)
And I still can't use the _SPF.FLIST to 'operate' on files within a defined project 'domain' e.g. "select something, step back and select something else related".
Apologies if this reads convoluted, but I guess what I mean to say is that
- the display should show me the full path where I am - and PF3 (END) should step me back to where I came from.
It is almost as if FM lets me 'scroll' forward a page, but if I 'scroll' back it 'scrolls' LEFT instead and the only way I can go back is to start again from the top.
|
|
|
Post by George on Mar 23, 2021 14:59:59 GMT -5
Stefan: OK, so you want a menu list of Paths (i.e. a custom PATHS display), not a file list. That's a problem, not in that it can't be done, but how is an entry in an FLIST supposed to indicate that? And what if an FLIST contains a mixture of old 'normal' entries and this 'new' entry (assuming we can devise a syntax to support it). Remember FLIST stands for File list.
Isn't a file list ultimately what you want? After all, all you can do with a path is to click on it to get a - guess what - file list. Why not just figure out what file list you ultimately want and build the FLIST to provide it? Skip the middle-man.
And for going back and forth, END has always been a 'go up one' function. I think what you want is (FMFwd) and (FMBack).
George
|
|
|
Post by George on Mar 24, 2021 10:13:04 GMT -5
Stefan: OK, got it. Like requesting a full FileTree listing by ending the path with a double \\, you can now end a path with a triple \\\ and it will appear and act just like the PATHS list.
Note: you can mix and match, that is these \\\ entries can be mixed in with other types like normal paths, specific files etc.
I'll update the Beta ZIP file next, look for .21083
George
|
|
|
Post by George on Mar 25, 2021 15:08:52 GMT -5
Robert: Stefan had a crash, and there was no real info to try and debug it's cause. So it ended up as one of those "who knows" things. No knocking Stefan, he always provides way more info than others when it comes to problems.
Is there a "lurking problem"? Well, yes, there's always a lurking problem, that's the nature of programming.
But should we stop and not put out any more releases till we've found and fixed the lurking problem?
Hardly, that would mean no new releases - ever! We'll never find and fix every crash that occurs, we have to accept that. How long do I sit here with 2.4 'on the shelf', waiting for more info on the lurking problems.
Is 2.4 stable? Well, I've been using it as my 'production' release for the last several weeks. Crashes? Only when I'm actually in development mode, adding some new feature/option, etc. Otherwise it appears to me as stable as any release has been.
I know we only have a very few Beta testers, but it would be nice to hear from them. Is it, as Stefan asked, "ready for prime time"?
George
|
|
|
Post by Stefan on Mar 26, 2021 7:22:31 GMT -5
Stefan: OK, got it. Like requesting a full FileTree listing by ending the path with a double \\, you can now end a path with a triple \\\ and it will appear and act just like the PATHS list. Note: you can mix and match, that is these \\\ entries can be mixed in with other types like normal paths, specific files etc. I'll update the Beta ZIP file next, look for .21083 George Hi George,
Thank you hugely for continuing to indulge my flights of fancy.
[UPDATE] Apologies! I used the 'table' button of this forum and that darn thing doesn't draw any lines around the table fields! D'UH!!! The column headings are 'FLIST ENTRY' 'Appears on FM as ' 'Click on Entry Effect' and 'PFK3/END Effect'
Sorry this is so hard to read now - I was looking to make it easier! [\UPDATE]
I have a _named.FLIST containing an entry in format as per col 1 below. I observe the following FM behaviour:
v2.4.21081:
FLIST ENTRY | Appears on FM as
| Click-on-entry Effect | PFK3/END Effect
| <pathname> | only the <last-element-of-pathname>\ (*1)
| opens entry to show all files/subfolders | 'walks' back up the <path> | <pathname>\ | List of all files & <sub-folders>\ names(*1) in <path>
| opens entry to show file/subfolder | 'walks' back up the <path> | <pathname>\\ | Merged list of all files from <path> AND <subfolders>
| opens entry (file) for editing
| Returns to '_Named' Flist display
|
|
|
|
|
Note: (1) If the FLIST contains <pathname> entries with AND without trailing-\ , you can't tell which <pathname> contains the sub-directories.
This is avoidable if ... - the FM 'PATH' column were to display the path for sub-directories as well as for files AND/OR - the FM Dir/Name column always showed the full <pathname> from the FLIST entry.
By the way, I found it useful to sort _NAMED FLISTs by the PATH column and specify an order of PATH,NAME(20),LWDATETIME,SIZELONG
Now for the new triple-\ version
v2.4.21083 (latest beta): FLIST ENTRY | Appears on FM as | Click-on-entry Effect | PFK3/END Effect | <pathname> | only the <last-element-of-pathname>\ (*1)
| opens entry to show all files/subfolders | 'walks' back up the <path> | <pathname>\ | List of all files & <sub-folders>\ names(*1) in <path> | opens entry to show that file/subfolder | 'walks' back up the <path> | <pathname>\\ | Merged list of all files from <path> AND <subfolders> | opens entry (file) for editing | Returns to '_Named' Flist display | <pathname>\\\ | <pathname>\ | opens entry to show all files/subfolders | 'walks' back up the <path> |
The only difference I can see between specifying <pathname> (without a trailing-\) and <pathname>\\\ (triple-\) is that the FM displays "<only-last-part-of-the-pathname>\" for the former and the whole "<pathname>\" for the latter.
In that respect, it avoids the issue outlined in Note (1) above, but you may be able to 'fit' that behaviour to the plain (no \) scenario and avoid messing around with '\\\'.
Note that the PFK3/END command returns to the 'previous view' (the _Named "FLIST" display) for <pathname>\\ scenario only. In all other cases, pressing PFK/END will 'walk' back up (i.e remain within) the folder-structure of the most recently accessed <pathname>.
In effect, FM makes the current <pathname> the 'FilePath', switches from the '_Named' display/view to the 'FilePath' display/view and then stays there. Consequently, the relationship to the FLIST is lost.
In the case of <pathname>\\, FM appears not to do so and behaves (from my perspective) better. If this is deliberate or just a curious glitch in the code, I don't know, but I should welcome an FM OPTION to force that behaviour if it is trivial to implement.
For me personally, 'walking back up' the directory structure is almost NEVER what I want it to do, but I appreciate that perhaps other users may find this really useful or intuitive. I'll research some more and perhaps post a separate discussion about the effects of PFK3/END in FM.
|
|
|
Post by George on Mar 26, 2021 10:38:20 GMT -5
Robert: The dialog string is not multiple lines, it is one string displayed in a multi-line enabled text box. But you're right, paste is odd. I checked, somehow, although I enlarged the box, I negleted to flag it as a multiline box. Should be fixed now.
Re: Adding to the Default dialog. Sheesh, don't want much, change all the settings AND open the file. I doubt I could open the file as we're half-way through the open logic at that point.
George
|
|
|
Post by George on Mar 26, 2021 12:43:29 GMT -5
Stefan:
First off, basic path entries in an FLIST are NOT supposed to be entered without the trailing \ (or now \\ or \\\) It's in the FLIST section of Help, for reference
It seems that they sort-of work, but in some hybrid cross between how a path entry and a specific file entry work. I will NOT be correcting this, it's a quirk of how Windows directory searches work.
Also, most of your complaints about how END works can be simply avoided by using the (FMBack) and (FMFwd) keys. END is doing exactly what it is supposed to do (Except for \\ where the 'tree' has basically been collapsed, there is no "up"). What you are asking for is exactly what those two keys were designed to provide.
George
|
|
|
Post by George on Mar 26, 2021 12:45:02 GMT -5
Robert: Sure, that works. Bailing back out from a lower level of a command structure and starting over at the top is not simple, especially if you've already opened a new tab for the edit.
George
[UPDATE]
OK, The new option for Default is in the next version.
[\UPDATE]
|
|
|
Post by Stefan on Mar 26, 2021 18:32:41 GMT -5
GEorge,
Fair enough - I'll give FMBAck and FMFWD a go. When you first mentioned them, I kinda read it as if you were suggesting you could create something like them. I didn't realise they already existed. I'll have a play with them. Thanks
|
|
|
Post by George on Mar 27, 2021 10:26:32 GMT -5
Robert: You want a playlist created. Now how you get from a series of FM line commands into making one of these is probably a sure pointer to creating some kind of FM Macro to accumulate the selected lines, build the .WPL file and invoke WMP. George Or the more common M3U playlist format, which WMP supports as well. en.wikipedia.org/wiki/M3U<?wpl version="1.0"?> <smil> <head> <meta name="Generator" content="Microsoft Windows Media Player -- 11.0.5721.5145"/> <meta name="AverageRating" content="33"/> <meta name="TotalDuration" content="1102"/> <meta name="ItemCount" content="3"/> <author/> <title>Bach Organ Works</title> </head> <body> <seq> <media src="\\server\vol\music\Classical\Bach\OrganWorks\cd03\track01.mp3"/> <media src="\\server\vol\music\Classical\Bach\OrganWorks\cd03\track02.mp3"/> <media src="SR15.mp3" tid="{35B39D45-94D8-40E1-8FC2-9F6714191E47}"/> </seq> </body> </smil>
|
|
|
Post by Stefan on Mar 28, 2021 7:18:05 GMT -5
George, Re: "END" primary command in FMIn keeping with established naming convention (e.g. CRETRIEV), I created a simple macro called CEND (Conditional END) with the following code: ' CEND.MACRO '----------------------------------------------------------------------------------------- ' This is Edit Macro CEND Stef 28/03/21 ' ' It operates as a 'conditional END' command to enhance FM display navigation. ' For ease of use, Keymap PFK3 key as "!CEND" instead of the usual "!END" entry '----------------------------------------------------------------------------------------- IF Is_FM THEN ' If File Manager SPF_Post_DO("(FMBack)") ' .. issue (FMBACK) keystroke ELSE ' Else SPF_Post_DO("!END") ' .. issue !END keystrokes
END IF
Halt
It's a bit 'clunky' because it needs to inject the required keystrokes via SPF_Post_DO(...) but it seems to work pretty well in early(!) trials.
Would you be amenable to creating a bonafide CEND primary command to streamline the function in due course? Or, if not separate command, an FM option to act as a swictch to enable END to work in same way.
|
|
|
Post by Stefan on Mar 28, 2021 8:17:07 GMT -5
Robert.... Re: your 'build clipboard from selected entries in FM' selection,
I wonder if there is a more intuitive way to do this without inventing ever more and complex line commands and COPY ADD/COPY REPLACE, etc. primary commands (to be honest, my head cannot retain all the line commands available on FM, and the help section at the bottom of the screen is getting too small!)
What do you think of reusing the same approach as used in EDIT tabs, but slightly adapted for FM?
In EDIT, we can issue primary commands like CUT, CREATE, COPY, etc which work together with some lines as identified by line commands like C/CC, etc. To buuild the clipboard... ...What if you could issue primary command CUT (with relevant usual operands available) on FM to do what it normally does - populate a clipboard? You would 'tag' the FM lines to be selected with, say, 'T/TT' or 'C/CC' line commands.
(Both options clash, as T=Touch and C=Clone). We could introduce other letters, but...
...a better approach might be force users to enter the primary command (e.g. CUT) BEFORE they selecting the lines.
The presence of a primary command sets the FM 'operating mode'.
With the FMmode=CUT established, the conventional and intuitive C/CC usage can be deployed without risk of clashes and the file entry selection can also be enhanced -see below)
To make it even more flexible and quicker, let's allow multiple groups of 'T' or 'TT...TT' blocks so that the line entries to be 'cut' need not be contiguous/adjacent in the list. Would that not make the process more intuitive for users and thus easier to remember?
They'd be using the same command and selection nomenclature they already know, to do the same job but on a slightly different object.
|
|
|
Post by George on Mar 28, 2021 10:10:43 GMT -5
Stefan: You don't have two keys you can set to (FMBack / FMFwd)? Seems simpler. I use F11/F12, but then I have a 104 key KB and use the Keypad heavily as function keys, since it's located where God intended the function keys to be, like on the original 3270s.
Robert: Stefan: I think opening the Primary CUT in FM is best, and using C/CC for the line command. It provides APPEND already. That would mean switching Clone to Klone to free up the preferred C for copy. I don't think Clone is used much, I know I have NEVER used it. Then open RUN up in Clip mode with the assumption the data is a BAT file.
George
|
|