|
|
Post by Stefan on Aug 26, 2023 6:44:00 GMT -5
Am I imagining this, or is/was there a way of associating the "Standard/Alternate" FM view with a particular FM quick launch 'tab'?
I note that the Help document states...
The current (latest) layout in use will be saved by SPFLite and will be used again the next time this folder or FLIST is displayed. ...but after selecting ALTERNATE (via click on Status line) and closing SPFLite, SPFLite will restart with FM in STANDARD layout.
So this could be a minor bug, OR...
...ideally, an enhancement suggestion that the FM "Standard/Alternate" view be remembered individually for each FM Quick Launch 'tab' (possibly not trivial).
|
|
|
|
Post by Robert on Aug 26, 2023 10:21:16 GMT -5
Was there an existing way to do that? Not that I know of.
Given the current state of the system, I believe the most likely way to shoe-horn this in might be to use EFT to add a keyword like STD vs. ALT to an entry. Since EFT is intended to describe files, and not folders, it would likely require an entry with a NONEDIT operand, plus the STD or ALT.
If a specific EFT entry for folders were supported, then FOLDER or DIR would be used. Like this:
"C:\USER\WORK\COBOL" = FOLDER,ALT
The EFT system was never really intended to describe folders, but to connect files to profiles. Adding attributes to folders, like STD vs ALT, is something ideally was done in Windows itself, but Windows offers very few folder attributes, just things like Compress and Encrypt, so if there was anything else you needed, SPFLite would have to provide it.
If using EFT for something that is clearly NOT a file was just a bridge too far, something similar might be devised, like Extended Directory Types, or EDT. Perhaps much of the EFT code could be borrowed/adapted for EDT.
This is just an idea for further discussion, of course.
R
|
|
|
|
Post by Stefan on Aug 26, 2023 11:08:49 GMT -5
Thanks Robert. My first thought was WFT but it wint work for what i intended to happen.
I'm looking to map the Standard or Alternate view to the FM Quick Launch tabs, not to individual file types.
So, for example, FM display Recent and Favorites with Alternate and the other tabs as Standard. The files in tbose two tabs are typically of different types and from different directories. Hence I'd like to also see the filepath for those on the FM display.
|
|
|
|
Post by Robert on Aug 26, 2023 12:10:50 GMT -5
For me, the file type I need an alternative FM display is MP3, since it has things like Duration, Author, etc. which have nothing to do with text. I use such displays to conveniently start up a song, not edit it of course.
Now, suppose a folder had ONLY one file type. For me, that would mean a folder with only MP3 files. We *might* be able to do something then. But even that could pose problems. In my MP3 folder, I have "index" files that are just text, to help me sort through all the songs, so my "MP3" folder is not ALL mp3.
I don't see a foolproof way to associate a directory to a STD/ALT format.
Here is a crazy idea that *might* not break everything and not be too hard.
Suppose there were a zero-length file in a directory, that had a name of either FM-FORMAT.STD or FM-FORMAT.ALT. Then, SPFLite would say, "hmm ... are there either of these special file names in the folder?" If so, it would format the FM display accordingly. If the user "cheated" and put in both, it would be treated like there was neither one - that is, it would run according to default rules. When SPFLite went to display an FM list, the first thing it would do it look for these special names. So, every folder would have its own FM display option.
The literal names used could be something else, these are just a "for instance" example.
This doesn't require any new user-interface software, no new parameters, and NO new functionality for EFT. In addition, these files would have to be zero-length. If there was actual data in them, they would be actual data (with 'odd' file names) and would NOT be treated as "FM display-format flags".
R
|
|
|
|
Post by George on Aug 26, 2023 14:11:52 GMT -5
Guys: I had a look, and it's obvious senility is in full force.
There is code in there to associate the layout mode to the quick launch selections. But it's never been completed, and I have no recollection of even starting it. (Surprise!)
So just leave all the suggestions for now till I have time to explore this and see what it will take to complete what was started, no sense in throwing that effort away.
I think this is a sure sign that after this release I should hang up enhancements and just fix bugs.
George
|
|
|
|
Post by Robert on Aug 26, 2023 15:50:23 GMT -5
Senility is hitting me too, the term "quick launch" wasn't registering. It's when you have an FLIST that starts with an underscore. So the question actually is to associate am FM list format with an FLIST file - rather than with a folder, as I was assuming you meant.
To make that happen, (your way) you'd need an FLIST for every file-grouping you wanted controlled in that way. My way, you'd need an empty file in every folder you wanted to affect.
The issue with FLIST is that it could encompass more than one folder and more than one file type. That could complicate things. Suppose one FLIST had two different file types, like mp3 and txt. How is it supposed to be displayed?
I sincerely recommend some actual systems analysis before jumping into this. Otherwise, writing the code first and figuring it out later could turn into a big mess.
|
|
|
|
Post by Robert on Aug 26, 2023 19:21:42 GMT -5
After a couple more hours of cogitating, this is what I came up with:
1. I almost never need alternate FM layouts, so I am not one to talk. My only application is for MP3 files, and then only rarely. So, keep that in mind for anything else I say next.
2. This seems to have all the makings of a rat's nest if we are not careful. There's all kinds of possibilities, based on FLIST or quick launch, based on folder, (somehow) based on EFT, etc. etc. etc. Each time I thought I had all the possibilities accounted for, I thought of more. I fear George would jump in front of a fast-moving truck if he tried to handle them all.
3. Stefan wanted to associate standard/alternate FM layouts with a quick launch (AKA an FLIST with a name that starts with _ underscore), but he didn't say why. I think the "why" part is important. Stefan?
4. I think it's also important to ask if anyone else needs this. George, do YOU need this? It's a very cute, clever idea, but if it never saw the light of day, I personally wouldn't lose a moment's sleep.
Now, suppose a bunch of people DID say they wanted this, or something like it. How could we possibly accomplish it in the least intrusive way, and still provide the most possible benefits and flexibility?
Using a macro.
I don't want to start off by trying to write specs for a "macro interface" or "macro API" to do this. I will just give the bare minimum and let others take it from there. Keep in mind that these are "ideas" and subject to change, and that I have NOT considered every last possible detail and the ideas could have mistakes in them. It's an IDEA. OK?
Let's suppose that at the point SPFLite wants to show us an FM list, it would call a user-written macro. For laughs, let's say the name of that macro was FM_FORMAT.MACRO. What would the characteristics of this macro be? I think something like this:
1. There would be one and only one macro with one name; whether it's the one I showed above or something else. Only one macro.
2. SPFLite would supply to this macro one or more parameters that define the "context" of the FM display in question. The "context" would be stuff like:
- Type of FM display (DIR, Recent, Open, FLIST, Quick Launch, etc.) whatever is needed to clearly identify what is involved
- Current directory, assuming there is only one of them (there would be more than one for some kinds of FLISTS)
- contents of current "standard" and "alternate" FM format strings
- anything else of importance
3. The macro would examine the provided information, and pass back a return code that would convey one of the following statuses:
- use standard FM format string
- use alternate FM format string
- use macro-provided format string; this may have to be validated
- report an error of some kind
When the return is "apply the user-provided format" it would, of course, require the macro to be able to pass back a string value. This might require a new macro built-in function, or maybe the string could be stored in a global value. The important thing is somehow or other, there has to be a way to get a string back to SPFLite.
By off-loading the decisions about FM formatting to the macro, a user could control the format to be anything they wish, without further burdening George about this.
The only other thing that probably is needed is an Option checkbox to enable or disable this feature, so that if the macro is broken it wouldn't break the whole SPFLite operation.
I have to repeat that I have no vested interest in this; I am not sure if I would ever use it myself. But if you wanted such a feature, I believe this is a way to get it done without enduring horrible trauma and gnashing of teeth.
R
|
|
|
|
Post by George on Aug 27, 2023 8:52:56 GMT -5
Robert: I asked you to hold off on suggestions, so because of what I found, I haven't even read your full note.
The 'incomplete code' I spotted is not incomplete, it's fully complete and works fine -> once I corrected for some downlevel code in the SQL interface.
'Quick-launch' refers to ALL items in the FM launch bar, NOT just the user created ones (with a leading _ ). This incudes Recent, FLISTS, etc.
For each one, the STANDARD/ALTERNATE setting is remembered. So ... no analysis needed, no coding needed. I just have to tweak the CFGMaint tool a bit. I'll put out a new Beta when the CFGMaint changes are complete.
George
|
|
|
|
Post by Stefan on Aug 28, 2023 9:11:12 GMT -5
Great stuff! For two reasons (1) I'm not as far gone as I thought - there is/was a facility that allowed setting of the STADARD/ALTERNATE 'view' for each 'quick launch' tab. (2) It is (hopefully) only a minor bug. By the way - apologies for the many spelling mistakes. I entered the responses on my Phone and the size of the keyboard is not designed for my sausage fingers. Combined with Android's appalling self-correction logic for English (oddly whilst being very, very much better at German), this leads to a lot of garbage typing. |
|
|
|
Post by Robert on Aug 28, 2023 10:30:45 GMT -5
Didn't notice your typos. I have an android phone too, and English auto-correct for English can be just as "inventive" as English correction of German and vice versa.
Most people these days "read past" the typos, and just "assume" the most likely correct spelling and keep going, unless they are really confused. Since I happen to be non-stop confused anyway, that only works some times :-))
I can see now that my over-active imagination was conjuring up a whole bunch of scenarios that would have been a lot of work for George when he already did most of it anyway. My only defense is that I didn't have a stake in it, so I wouldn't be heartbroken if my ideas weren't taken up.
Truth is, there are so many clever, interesting things that COULD be added to SPFLite if one had the time and ambition, but they'd be just SO much work. George can tell you ...
R
|
|
|
|
Post by George on Aug 28, 2023 16:49:07 GMT -5
And I can tell you, I have NO recollection of ever coding that support. I was looking at code and saying "I wonder what THAT function does . . never heard of it". Like I said, time to retreat to bug fixes or very simple things that won't overtax the old brain cells.
“I remembered that I forgot ... something.”
George
|
|
