|
Post by Jo on Feb 14, 2021 4:27:58 GMT -5
When FF encounters an unknown file type, or when selecting a file with unknown file type, then a popup "Create new Profile INI" comes up. Here we can select another existing Profile to be USEd for this files. (That's fine and I like it!) But: the selection-list contains ALL known Profiles, even Profiles having the PROFUSING option set. I think there is no point to USE such an 'alias' profile. Therfore I suggest to shorten the selection-list by excluding those Profiles with an active PROFUSING. (To run the chain of PROFUSINGs to find the top Profile is another solution, but not worth it, I think ...)
Jo
|
|
|
Post by George on Feb 14, 2021 10:39:18 GMT -5
Jo: Robert: So now, instead of just doing a search for the Profile names, you want it to check each one in detail to see if it has a USING? Sure, lets keep adding overhead to every part of the program.
George
|
|
|
Post by George on Feb 14, 2021 11:45:52 GMT -5
Robert: It's not a major problem, I'm just surprised by how many Profiles some users seem to have. I mean DEFAULT will probably handle 90% of needs. Then add in the ones needed to get a proper AUTO and tab settings for a language, still shouldn't be a lot.
Regardless, I'll add it it, we don't need more kludges with special characters etc.
George
[UPDATE]
OK, Done for next release.
[\UPDATE]
|
|
|
Post by George on Feb 14, 2021 14:14:26 GMT -5
Remember DEFAULT is used for all those filetypes where a separate Profile is not created.
I'm not blowing up, but really, what would all this accomplish? It sounds lovely and sophisticated, but again, what can I do if we had this that I can't do today?
You have proposed this 'layering' approach for Profile elements in the past, some kind of 'hierarchy' of parameters, where values trickle down if not overridden by a more specific Profile.
I've rejected it in the past because of the complexity of loading Profile values. Handling overrides at an individual variable level is a huge change. As well as fetching all the values from a model, you then have to examine each and every one to see if it is overridden by another level. And although using * to indicate fetching from the model sounds simple, how do you do that for numeric (or ON/OFF) values? Does it mean another whole variable to specify this (use the model or not value) ?
Then there's all the Profile setting commands. When a variable is altered, would the command have to determine if the new setting is = to the model, and stick in an * (or whatever). If it was left unique and equal to the model, and the model changed later it would no longer match. Should it?
And on and on. Throw in the USING complexity and you have my answer.
|
|
|
Post by Jo on Feb 14, 2021 14:27:52 GMT -5
Jo: Robert: So now, instead of just doing a search for the Profile names, you want it to check each one in detail to see if it has a USING? Sure, lets keep adding overhead to every part of the program. George George: not to every part of the program, just when creating the new-profile-selection-list
|
|
|
Post by George on Feb 14, 2021 16:11:25 GMT -5
Sorry Robert, you just don't get the complexity of all this. I'm not trying to exaggerate this, but it really is an enormous change.
e.g. Command syntax to support * (or whatever). There are over 40 Profile commands. It means changing the code in every one of them to support this.
PROF Display (inline) Again, another 40+ changes to display all this in <> or [] or whatever. This is not simple, right now code can fetch, say, BNDS by accessing PRF.LBnd and PRF.RBnd, just as if they were normal variables. So how will the code building the BNDS display detect that it's a Profile or Model setting (let alone how to display it in a BNDS line). Hmmm, seems like more PRF.methods for each variable will be needed (times 40+).
PROF EDIT GUI. Another pile of changes to get it to display properly. Same problem above in telling Profile vs Model. Add in how do you display a CheckBox to indicate it's a Profile value or a Model value? Similarly with Pull-Downs, and Text Input boxes. This is not trivial. You know there is no GUI designer in PB (well, there is, but I don't have it) so this is all manual grunt work to make changes to the GUI
Assuming I get it displayed, how does a user indicate in a checkbox, pull-down or Text box that he wants the Model value, or a Profile value?
PROF EDIT GUI Callback Every GUI has a Callback routine that has to - guess what - validate all the above input. Each and every variable field, all would need changing.
SQL Storage Change all the values to distinguish between Profile values and Model values. This means every fetch from the CFG file for a Profile variable now has to be altered to handle this difference (and possibly read the equivalent from the Model). And of course a big release update tool is required to convert current CFG to this new CFG format.
Plus some miscellaneous changes to remove the USING support (which is no longer needed)
And my main question still remains:
What does this enormous effort buy me in usability? (Eliminating USING is just not enough)
George
|
|
|
Post by George on Feb 15, 2021 11:28:51 GMT -5
Just some quick points.
USING override. Once a Profile says USING - absolutely everything comes from the USING profile, there is no merging. Any settings changes are made to the USING profile, not the 'file extension' Profile. The only change to the original 'file-extension' Profile that can be made is to remove the USING itself.
Profile storage is already done in an Object, with Methods, Properties etc. SPFLite is not that backward, it uses over 10 different storage objects. e.g. Each Tab's data is one gigantic Object.
Hate to tell you, but the Profile GUI you now want to drop, was your idea. Just displaying and processing that thing takes 600-700+ lines of code. And yes, it is the major stumbling block to making your suggested changes.
The other major problem is the conversion tool (or whatever) needed to migrate the current CFG data.
The idea is not faulty, or ridiculous, but it's a major leap to get there, and other than knowing we'd be doing things in a more approved, standardized way, I still don't see any major benefits.
George
|
|
|
Post by George on Feb 16, 2021 11:00:54 GMT -5
I thought a bit about the migration (can't turn the brain off). The only way I could think of was: - DEFAULT is copied to create the DEFAULT MODEL, and is changes to specify DEFAULT as the MODEL. DEFAULT is still used for Profile for the "File types to use the DEFAULT" option. So initially DEFAULT Profile and DEFAULT MODEL are identical.
- Profiles with NO USING and which are not pointed to as USING by some other Profile, become new style Profiles, specifying DEFAULT as their MODEL and keeping all their old values as overrides.
- Profiles Pointed to by a USING become MODELS.
- Profiles specifying USING, become normal new style Profiles specifying the using name as the MODEL, and with all their values directly copied from the MODEL. (i.e. no real overrides.)
The only problem I'm not sure how to handle is the Profiles which have been pointed to and have become MODELS. There is now no real profile unless we create one named the same and pointing at its equal named MODEL (like DEFAULT above).
From this point on the Profiles and Models can diverge as needed.
Do you think having these MODELS and PROFILES, each nearly identical will confuse the users.
And how do we alter the values in a MODEL? The normal commands will be modifying the Profile version.
And how do we setup a new Profile before attempting an OPEN of a new file-type which NEEDS some custom settings. I think it was this need that instigated the Profile GUI.
George
|
|
|
Post by George on Feb 16, 2021 13:18:22 GMT -5
We're close, but I have a major problem in the CFG file. All tables in the CFG file have the same Schema, a simple Keyword / Value pair (Just like the old INI files used to have). You now require another column in the Profile/Model tables to hold the flag for "which value is used".
That is a REAL problem for me as all the SQL table handling routines are simplistically written with the KW/Value schema in mind. They all have two columns - DBKey and DBData. Your magic flag to indicate where the value should come from is a real stumbling block.
Any ideas for an alternative way?
George
P.S.
How about simply making the Profile value a simple 1 char ¬ sign to indicate "not here"
G.
|
|
|
Post by George on Feb 16, 2021 15:34:38 GMT -5
SQLite has no problems with NULL (unless the column is defined with a NOT NULL constraint, which I don't do for the DBData column). So NULLS are fine.
But there are a lot of variables where NULL is a perfectly valid specification. So if a Profile wanted to override a MODEL string value with NULL, using NULL as the trigger wouldn't work.
So maybe ¬ (or something else) isn't necessarily a bad idea. After all, how many 1 byte long Profile variables are there?
George
|
|
|
Post by George on Feb 17, 2021 10:14:40 GMT -5
Robert: Actually NONE is never stored, it just stores null strings. But for us poor humans, in displays it converts it to NONE.
In SPFLIte and its use of text strings NULL is just that, an empty string ( "" ) there is no separate 'thing' called a NULL.
And who says a MODEL has to have a value in every variable? A variable in a MODEL or a Profile is perfectly valid when it is a "".
George
|
|
|
Post by George on Feb 17, 2021 13:54:08 GMT -5
Whoa! I've obviously been misunderstood.
The key word in what I said was value. Who says a model has to have a value in every variable?
I fully agree that Models/Profiles must have every last variable defined. All I was stating is that the VALUE associated with a variable can be NULL, empty string, whatever you want to call it. A VALUE of NULL is not the same thing as an undefined variable.
Variables will always exist, in fact the read/write code I use for SQLite access will create a variable with the default if asked to read one and it doesn't exist.
Once created, I don't even have support for deleting a variable. Null it? Yes. Delete it? No. Variables are only removed when the whole table is deleted.
There is no need for NONE, a Null string is simply "".
I will NOT be getting into using SQL's native NULL support, it's another complication I don't need.
We're not in disagreement here at all. Whether we ever DO it is another story.
George
|
|
|
Post by George on Feb 18, 2021 11:22:41 GMT -5
It's clear, but as you say, that it's my call as to how I store things to indicate unspecified, you can bet that it will be a ¬ (not sign) instead of NONE or USE or whatever. Users will never see it anyway.
George
|
|
|
Post by George on Feb 18, 2021 14:48:05 GMT -5
My preference is to have just a DEFAULT Model. Just as currently happens with the DEFAULT Profile today, the DEFAULT model would be built on the very first SPFLite execution. It would be built from internal, hard-coded defaults.
From there on, the DEFAULT Model is fair game for the user to modify as they desire. There will be no SYSTEM Model anywhere (as a physical entity in the CFG DB.) If we decide to alter the internal hard-coded default for any variable, it can be done with no impact to any user since their DEFALT Model has already been created. The new value only affects totally new users (or someone who blows away the CFG file and starts over)
My main opposition to using SQL's NULL concept is that it just doesn't 'fit' with my current SQL toolset. Everything now is predicated on a GET function that will ALWAYS return a value, even if the Key/Data pair never existed before. (and yes, the returned value could be a null string)
The PRF Object in the program (which handles all Profiles) will handle all the ugliness of merging Profiles and Models. It's still going to be messy for those mainline functions that need to know where the value came from (like the PROF display) The PRF object will have to create a new property for each variable to indicate it's source.
This is all going to be a significant effort if we do it. Does it buy us enough real benefit? Of is it just comforting to be able to think it's 'designed better'. I'm still not seeing real benefits.
George
|
|
|
Post by davecheckley on Aug 18, 2022 22:00:58 GMT -5
Well, I read some of it, but I’m mostly interested in the Default profile. I think it should be delivered locked, so that any settings made to support a particular file don’t corrupt it. I was playing with an EBCDIC file and, because I’m stupid, ruined the Default profile.
How can I get the original values back again?
Regards, Dave
|
|