|
Post by George on Aug 24, 2019 14:44:23 GMT -5
Robert: Again you have said that I am creating some significant changes or additional GUI interfaces. I have said before that I am not - Still true. There is 1 additional field on the Options => General dialog, and 1 additional Config tab, which users who wish to stay with the current config storage methods, can completely ignore.
Your point 12. Validating changes to PARM files. This tosses this off as a simple test for PARM file formatting. Really? where does the test for valid parameters occur? Where do I catch ScrlAmnt=FRED. or FMLayout="Tom, Dick, Harry"
Using this storage format now introduces file inter-dependencies between the SQL repository and all the various PARM files. This to me is far scarier than my suggestion of using an SQL database. Handling the Sync required by your point 13 is, for me, enough to signal that this file dependency is real, and complex. I would certainly not want to chase any reported bugs that might have been triggered by so miss-sync of these files.
But mostly this would require very significant changes to all the code for all the parameter files (Main INI, Profiles, KBD, etc. etc.), and associated changes to the Editor to handle links and dynamically switch files mid-Edit, to File Manager for the FLISTS, frankly this is way beyond any size project I would consider tackling.
George
|
|
|
Post by George on Aug 24, 2019 16:22:03 GMT -5
Robert: I can see where , if this were achieved, users could 'piggy-back' and possibly use the shared support for their own purposes. Do I think that likely? No. I think users want an editor and maybe some macro support. But to build something more extensive based on their editor? I doubt it very much. Maybe at most a small number of users, but no more. And I don't think that justifies the investment in time to do this.
I had thought that this change to using SQL at least addressed the need for handling the shared, multi-instance requirement without some major re-write. And I think it does that.
No, it doesn't handle signalling other instances of changes to parameters, but really, I can't see that as a priority with anyone. I think most of us are quite aware of the problems in doing that and really just want to be able to use a common set of stored parameters amongst their various settings, on possible various systems.
Basically, I'm trying to get the biggest 'bang-for-the-buck' from changes that don't require 'upsetting the apple-cart' to achieve. (Is that enough simile's?)
George
|
|