Hi, everyone.

Note: I couldn't save the message from the first place because of XML tags. I've replaced all tags with apostrophes. I hope you'll understand the message, though.

I am checking the new features of VFP9, as they are implemented. I've ran into a problem with _MemberData property - it is limited to 8k.

Well.... let's see if we agree here:

Fact: 1. MemberData data is stored in the same memo field as the property names.
Fact: 2. It is stored as XML and a typical line looks like this: 'memberdata name="sqlbuffering" type="property" display="SQLBuffering'
Fact: 3. Even so, the XML is preceeded by a line that looks like this: _memberdata = [lots of chr(1)] 7768'VFPData'.


Guys, I don't get it. It is bad design or what? I would really appreciate your oppinion on these conclusions:

1. The property name is already stored in the same memo field. Why is need to repeat it in XML?
2. If a property has MemberData and it is renamed, the old XML line is kept, and a new one is added. Orphaned XML. What it is good for?
3. As you can see above, the XML line has 72 chars. The only useful data is the properly capitalized name, which has only 12 chars. 60 chars waste. According to my math, that's 500% waste. All lines have a similar percent. That means those 8k are, in fact, 8k/6 = 1365 bytes. Note: 6 means: 5 is waste factor and 1 is the actual data. More than that: ff you have 100 properties, you have 100 chr(1). So this should be substracted from those 8k, too.
4. The cherry on the cake is the number at the beginning of 'VFPData'. Change it, and you're doomed - MemberData Editor won't load anymore, because it says "Invalid XML". Come on, let's get real. The end of the XML is '/VFPData'. Why it doesn't simply check where '/VFPData' appears??? Doesn't this defeat the whole purpose of XML?
5. Properties are stored in a memo field, for God's sake! Why limit it to 8k? the only real limit is 2 GB!
6. Another thing I don't really understand is 'type="property"'. Well... properties are stored in different field that methods. If it isn't here, then it's a method. If it's not there neither, it must be deleted, being obsolete. Why is need to mention the type?
7. Wouldn't have been MUCH easier just to store the properties as in previous versions, but to keep the capitalization AS ENTERED BY THE PROGRAMMER?



If you consider my point of view is not correct, can you give then an alternative solution to this problem:

1. I need to have a custom object that stores in it's properties the environment settings, in order to restore them at app's exit.
2. I also need to have the properties proper capitalized.
3. I also need to have some coherent names, such as: cOldSetSQLBuffering, or cOldSetPrinterName.
4. At the time being, I already have 116 SET commands to save. I expect some more settings, but not too many (i.e. ON ERROR() and stuff like that).


Any idea? Any oppinion?

Thank you.