|
Post by George on Oct 15, 2022 20:25:11 GMT -5
FM needs to get the Profile STATE value to know if it is possible to get the file's LINE count from the STATE file. This is done as it collects the file's data.
Yes, there is a collision between the DEFAULT list and EFT, the doc will have to point that out.
Yes, EFT entries are memory resident.
When we added file properties to FM (Title, Resolution, Size etc.) it was a big performance hit for FM, that's why I'm leery of every extra bit of processing.
The DEFAULT list only gets checked the same as EFT will, there's no need to list everywhere it's used. George
|
|
|
Post by George on Oct 15, 2022 15:23:31 GMT -5
Robert: My main concern with multiple EFT entries in the EFT list is still performance(and we don't know the impact yet). The EFT search for a Profile means scanning the EFT list for a match. The FM Refresh function means calling the EFT search for every item in the folder being displayed, and a refresh is done frequently. Maybe systems now are fast enough for it not to matter, we don't know that yet. The caching of 'does a Profile have STATE ON' can only be done AFTER the EFT search, not before.
The DEFAULT search itself is a nit, it's a single, simple INSTR test, it can remain.
I don't like the idea of adding another layer of complexity to the EFT list, the management and searching of the list would be getting to the ridiculous stage.
Remember, I have to modify all that code that handles when a 'profile' doesn't exist, it's messy as it is, I don't need it to get worse. You have an isolated "does 'A' = 'B'" to handle, I wish my side were as easily defined as that.
George
|
|
|
Post by George on Oct 15, 2022 12:46:05 GMT -5
Robert:
Your thoughts on the current "Use DEFAULT for these file-types". (Options => General)
As it sits with EFT, the EFT creates the Profilename, and THAT name is matched against the DEFAULT list.
e.g. If the DEFAULT list contained BILL and EFT contained .FRED = BILL then the .FRED file will be opened with the DEFAULT profile, not the BILL profile.
If we get rid of the DEFAULT list, it means users will need many more entries in the EFT list that say .AAA = DEFAULT .BBB = DEFAULT etc. etc.
George
|
|
|
Post by George on Oct 15, 2022 12:35:42 GMT -5
True, but it is hard to overcome a lifetime of usage.
George
|
|
|
Post by George on Oct 15, 2022 12:30:55 GMT -5
Stefan: I strongly doubt it. That whole process of getting macros to work as line commands (when they actually get invoked internally as primary commands) is pretty ugly. And as we found in trying to debug the B& thing, my knowledge of how I got it all to work is getting weaker.
I realize maintaining two similar code blocks is a pain, but sometimes it's still best.
George
|
|
|
Post by George on Oct 15, 2022 12:10:56 GMT -5
Stefan: Thanks for the proposed additions, I've slotted them into the Doc for the next publication.
George
|
|
|
Post by George on Oct 15, 2022 11:56:01 GMT -5
OK, next Beta will have working:
Get_WordChar$ Set_Word Get_MaskLine$ Set_Mask Get_TabsLine$ Set_Tabs -> This can return RC=8 and Null the Tabs if the string is invalid Get_MarkLine$ Set_Mark
Now for the Doc - Ughh!
George
|
|
|
Post by George on Oct 15, 2022 9:45:18 GMT -5
Actually Get_Maskline$ is totally AWOL, not sure how it slipped through. I'll check out all these and see how best to correct it.
George
|
|
|
Post by George on Oct 14, 2022 14:06:02 GMT -5
Hey Robert! No jettisoning at all. Without your ideas SPFLite would be a pale shadow of what it is. But yes, it's probably time for DROP/KEEP to retire.
George
|
|
|
Post by George on Oct 14, 2022 12:11:27 GMT -5
Stefan: Great job. Been asked for K type support in SPFLite, but I could never plot out a strategy of adding it without breaking current line command processing.
They are so useful, I'll put them in the sample macros folder for install.
George
|
|
|
Post by George on Oct 14, 2022 12:00:43 GMT -5
OK, way back when the universal search routine criteria data was re-organized, this error crept in. It was one of those boolean compound tests that worked before the change, but became illogical after the change.
DROP and KEEP have been corrected now.
But it does show that they have lain unused for years. I can see their usefulness, but 'unused for years' is worrisome. Should they be retired? They will now work (again), so it costs nothing to keep them.
George
|
|
|
Post by George on Oct 13, 2022 14:27:41 GMT -5
Stefan: Impressive, you have certainly become the resident macro Guru. I'm happy to see the macro language can actually accommodate what's needed to make it work.
Kudos!
George
|
|
|
Post by George on Oct 13, 2022 12:10:28 GMT -5
Stefan: Sort of. The command still has to do a reset of line commands to prevent them being 'carried over' to the reloaded file.
It's little things like this that complicate the internals so much.
|
|
|
Post by George on Oct 13, 2022 11:59:51 GMT -5
Didn't forget - WARN is removed as well. There's no way around it I'm afraid. The RC is used for a lot more internally than just being a relative measure of severity.
George
|
|
|
Post by George on Oct 13, 2022 9:25:58 GMT -5
Stefan: As it turns out, an RC=2 has other meanings internally. Looking closer, it appears using anything other than 0 and 8 (OK / FAIL) in a macro can cause weirdness. I'm going to close that off, there's no simple way to just 'allow anything through' without interfering with the internal usage of error codes (there are 7 in use)
I'll change the doc and the code to allow only 0 and 8.
George
|
|