The MemberData Editor, the replacement New Property/Method dialog, and the fantastic new PEM Editor all make it easy to get VFP to display the desired case for your custom properties and methods in IntelliSense and the Properties window rather than the lame lower-case it normally uses. The secret is _MemberData, a custom property added to a form or class that contains XML providing additional information about members, such as display case, whether they appear in the Favorites tab of the Properties window, and scripts to execute when you double-click properties in the Properties window.
One of the problems with _MemberData, though, is that it's limited to 8K. If you've ever worked with XML, you know it's very wordy and it doesn't take long to blow through the 8K limit. This is especially a problem with subclasses: not only do they contain the _MemberData XML for their own custom members, they also contain the XML for all parent class members. The deeper you go in a class hierarchy, the longer the XML gets and the closer you get to the 8K limit.
However, a little known fact about _MemberData is that it's cumulative: VFP internally combines the XML from the current class and all parent classes. Even if you blank _MemberData in a subclass, your members still display in the proper case. So, one way to keep that 8K limit at bay is to strip everything but the XML for the members added in the current class from _MemberData.
That would be a tedious chore to do manually. Fortunately, a couple of new features in version 4.0 of PEM Editor (currently in development) make this a breeze. The Cleanse MemberData function in the shortcut menu does this explicitly, but PEM Editor also does this automatically when you add a new member to a class.
If you can't wait for PEM Editor 4.0, I've uploaded a small PRG that does the same thing (in fact, it's the same code as in PEM Editor 4.0) to the Technical Papers page of the Stonefield Web site. To use it, open a class or form, then DO MDCleaner.PRG. Just to be safe, please back up your form or class first.
Posts
2 comments:
Hi Doug,
In FoxCHarts I'm using Memberdata a lot, for Property scripts and also to control the captions of the properties and methods.
I reached very quickly the 8K limit, so I had to create a subclass and add more _Memberdata info to it.
I ran your solution, and the memberdata is indeed much easier to understand, but strangely, it became bigger (in bytes) than the original.
For my sample, the _Memberdata had 8160 characters and after the "transformation" they became 10307.
Note that the size of 10307 chars is not supported, and my class could not be saved.
Opening the modified _MemberData, I noticed that some characters were added:
ORIGINAL XML:
memberdata name="ogfx" type="property" display="oGfx"/
MODIFIED XML:
memberdata name="ogfx" type="property" display="oGfx" favorites="false"/
The difference is that the new XML brings the info [favorites="false"]
Saving space is fundamental too, do I'd eliminate the [TAB] at the beginning of the lines.
One single character per property may be valuable, and allow a new property to receive a MemberData script.
Anyway, the 8K limit is very frustrating, and the way that it was designed is very space consuming too.
eg:
memberdata name="ogfx" type="property" display="oGfx" favorites="false"/
could be:
md nam="ogfx" typ="prop" disp="oGfx" fav="F"/
Regards
Cesar
Hi Cesar.
I have rewritten MDCleaner.PRG to use the MS XML DOM object rather than XMLTOCURSOR() so only those nodes that previously had "favorites" now do. Rather than posting it as a new PRG, it's part of the next release of PEM Editor.
Doug
Post a Comment