|
Post by Stefan on Jun 26, 2019 4:00:22 GMT -5
Hi Guys,
Quick digression... I have to say I totally support your 'retirement' reason a while back, but having just read the "PA1" discussion, I think you're working (and driving each other) as hard as ever. As for PA1 - I haven't seen it yet, but as another old(!) mainframer, a huge THANK YOU! I did something similar a while back by mapping CTRL-Z to (SaveCursor)(Enter)(Home)[UNDO](Enter)(RestoreCursor) A little clumsy, but it kind of does the job, except for not returning the cursor/screen position where I left it, so I'll revisit that once PA1 support is available. Now my question / request...
Some of the "settings" kept in the 'Documents\SPFLite' folder are clearly user-related. However some others are more "global". I'm thinking especially of the MACROS, AUTO and possibly THEME folders, but also files like SpfLite.KBD. It would be useful if we had a 'user' and a 'shared' implementation of those. I should like to place the 'shared' stuff on central storage (e.g. NAS) but keep the option of user-specific override. They way I envisage it is:
(1) Keep the current implementation of the 'Documents\SPFLITE Folder but consider this the 'user-specific' (default) version. (2) Provide for a second location as a 'shared' location via the OPTIONS dialog. Default value is either blank or 'Documents\SPFLITE'. (3) As now, all access to data in MACROS, AUTO, THEME, etc folders is to the 'user' version. However.... (4) ...if the required folder or file isn't found there, SPFLite searches the specified 'shared' folder as well.
It would enable standardisation across multiple machines in the same household without the need to manually copy macros, colorisation files, keyboard mapping, etc around multiple machines.
If the 'shared' (NAS) location is defined as 'always available offline', it also provides access to it when the network is unavailable. So why not just do that for the whole SPFLite.INI folder? Because Windows would 'sync' every change to all machines, potentially creating sync conflicts and no longer supporting user-specific settings.
Bit of dataset concatenation - just like in the old days. Oh wait... Windows already does it with some environment variable, such as PATH.
Talking of PATH... not a biggie, but should we consider adding the SPFLite.EXE installation folder to the PATH definition at installation? It would avoid the eternal 'are-we-running-32bit-or-64bit-Windows' debate when calling the program from elsewhere.
Brilliant piece of software, guys. Thank You. I wish you both continued good health and don't work too hard!
|
|
|
Post by nicc on Jun 26, 2019 8:45:25 GMT -5
IF SPFLite ever went this way would there be any advantage to using an SQLite database as a data store - some of those folie entries could be hidden away as tables. The obvious disadvantage is the learning curve for George - if he does not already know SQlite - and the large analysis/recoding effort.
|
|
|
Post by George on Jun 26, 2019 12:10:58 GMT -5
A hierarchical, overriding INI structure complicates things enormously. Every variable load becomes a possible multi-file search, every variable write has to be unique since every variable has to either be identified as to what hierarchy level it should be written to, or it also becomes a 'find me in the hierarchy and update me here' exercise.
Sorting all this out for 225+ variables is no small piece or work.
XML sounds good, but doesn't handle multi-instance access. Best option may be SQLite (or an equivalent), but that doesn't necessarily handle a layered, multi-location INI storage.
There aren't any simple answers.
But don't forget simply using the command line -INI to point at different INI folders.
George
|
|
|
Post by George on Jun 26, 2019 12:59:56 GMT -5
Yes, definitely there would be packaged INIGet/IINIPut style functions, I certainly didn't mean to imply code everywhere doing complicated searches.
Sure it's all possible, but sorting out what variables go where would be fun. Hmmm, does ABC=10 belong in Global, in User, in Profile, in xxxx?
Planning would be brain-busting, let alone doing it because it would be difficult to 'stage' the migration, and (as you're well aware) I'm afraid my programming style is simply not a) analyze it to death, b) do all the code changes at once and then c) test it all.
INI files seem old-school, but even MS has backed off it's initial suggestion that all INIs should be migrated to the Registry. They're simple, and they work very efficiently.
George
|
|
|
Post by George on Jun 26, 2019 17:02:11 GMT -5
I agree, but if I could find a suitable DB type thing, It would be nice if all the SPFLite INI type stuff, INi, KBD, Profiles etc. could be 'dumped' into one single Config file rather than the current scattered approach. But even that would be a major piece of work, and we ARE retired. George
|
|
|
Post by George on Jun 27, 2019 13:40:54 GMT -5
Other than crash reports (which I create a lot of during testing) I only see 7 other files, that's hardly excessive.
George
|
|
|
Post by Stefan on Jun 28, 2019 10:35:32 GMT -5
Oh dear! I feel like I walked into a bar, dropped a lit firework and ran away.
It was just the MACROS that originally got me thinking along these lines, and then I figured AUTO and thus THEMES could also be included. Each of these are pretty much 'separate' entities. I considered PROFILES, CLIP, FILELIST, RUN, STATE and VSAVE to be 'per user' concepts. And I shouldn't have mentioned the KBD file! My bad! :-)
It's up to the site SYSADMIN to decide how they want to administer it. I'm probably the only SPFLite user in my household, but I use it from several different machines. Others may decide to prevent users changing the 'shared' copy of anything by marking everything in the 'shared' version of the SPFLITE folder as "read-only". SPFLite EDIT cannot then save the data back, same as it can't save changes to files in folders under "C:\Program Files\...". If someone wishes to amend a 'shared' file, they need to obtain a copy, edit that and then copy it back, outside of SPFLite.
The 'concatenation sequence' is always DOCUMENTS/SPFLITE folder first, then the new folder, if specified. I assumed that the number of places where SPFLite internal code reads from \AUTO, \THEME and \MACROS are not that many.
|
|
|
Post by George on Jun 28, 2019 12:08:57 GMT -5
Hi Stefan, Cross THEME off, it's now dead as of version 10. Lack of interest (and pre V10, it was hard to share color stuff anyway).
Don't worry about fireworks, Robert and I can argue about anything, anytime, we're pros.
George
|
|
|
Post by Stefan on Jul 2, 2019 3:19:33 GMT -5
EXCELLENT! I think that's one thing I do miss since I retired - the daily banter and gentle ribbing between colleagues! Long may it continue. Keep up the good work.
|
|
|
Post by Stefan on Jul 3, 2019 3:04:04 GMT -5
Robert,
Hmm - doesn't the bottom of the OPTIONS - GENERAL dialog give you exactly what you want? It appears to define where the INI file is. I assume that implies that the other files are also in the same directory/folder? Apologies for asking - I was too lazy to test it via trial and error.
By the way, the question about SPFLite inclusion in the PATH variable becomes relevant when other generic programs or scripts wish to call SPFLite. To avoid failures when running in different environments (32-bit or 64-bit Windows), I add it manually to the PATH variable after installation, because otherwise, (quoting from Pirates of the Caribbean) "it can only be found by those who already know where it is". :-)
|
|
|
Post by George on Jul 4, 2019 9:48:06 GMT -5
Robert: I'm confused here. If you want your \Documents or \Pictures or whatever off your C: drive, just move them. Like you, I keep everything possible away from C: as possible.
Open Explorer, select your Documents folder, select Properties, select the Location Tab, and tell it where to go (so to speak). You don't have to live with Microsoft's "everything goes on C:" mentality.
Stefan: The INI location on the Options tab is an Info-Only field. If you set the location of the INI file via the command line -INI parameter, the whole INI folder follows it.
George
|
|
|
Post by George on Jul 5, 2019 11:30:48 GMT -5
Robert: Everyone: How about changing the -INI parameter to be a pointer to the \SPFLite folder rather than the INI fle itself? Would that satisfy everyone's need?
George
|
|
|
Post by mueh on Jul 5, 2019 13:46:22 GMT -5
Hi George !
-INIT should not be changed as we should be able to specify different INI Files which can be anywhere . See no Benefit of -BASE . Following Sample BAT File starts different SPFLItes with it's own TEMP dir and INI File on a user path
pause Synchronize the Documents\SPFLite folder to D:\xxx with all it's sub Folders before
if NOT EXIST "%TEMP%\SPFL102%1" md "%TEMP%\SPFL102%1"
set TMP=%TEMP%\SPFL102%1
if NOT EXIST D:\xxx\SPFL102%1.INI xcopy D:\xxx\SPFLite.INI D:\xxx\SPFL102%1.INI
start "SPFL102%1" "%USERPROFILE%\Desktop\SPFLite Editor.lnk" -INIT D:\xxx\SPFL102%1.INI -TITLE v%1/10_2_19129 %2 %3
set TMP=%TEMP%
Hope this helps
|
|
|
Post by George on Jul 5, 2019 15:14:50 GMT -5
I'm still a bit at a loss about all this need for different folders/INI files etc. There must be some underlying need that I'm just not seeing. I've been using the basic one \SPFLite folder and one INI file, One KBD file etc. for years and have never felt a need for some alternative. Obviously others want something more.
It seems there is some other need I'm not seeing, and because of that I don't think we're addressing it properly. If MUEH has to have batch files copying folders/INI files around etc. there is something basic needed.
What exactly is the requirement?
George
|
|
|
Post by mueh on Jul 6, 2019 11:24:54 GMT -5
Hi ! I just want that -INIT Parameter continues to work as it does today and can specify any Path and filename .. Every SPFLite Stuff like .KBD .SPS and Folder MACRO STATE PROFILES FILELIST are taken from INI Path already now . Robert: Above BAT File with Syntax SPF.BAT A filename to edit allows to start additional SPFLIte instances each having it's own INI file and and TMP Path ( UNDO works ) . Each instance is f.e for SPFLite-Source Hercules-Source Data files for different Operating Systems and other Projects . Thanks
|
|