>>>>Back when I was young and foolish, I entered the type of control (TextBox, Spinner, etc.) that I wanted to display for many of the fields in my tables rather than leaving them as . These are known as the "Display Class" and can be seen in the bottom left corner of the MODI STRU screen.
>>>>
>>>>Since then I learned about subclassing (TextBox -> MyTextBox) and how to get VFP to point to them through tools/options/field mapping. Life is good except I now realize that the "Display Class" version is overriding my field mapping, and I want to get rid of the Display Class version.
>>>>
>>>>It seems that they are stored in the DBC in the "Property" field in a Memo. OK so far, but the Memo structure seems to be undocumented, and it holds the field comment and other things as well as some unprintable characters. I can make all the changes manually (returning TextBox to ) through MODI STRU but I really don’t want to even think about that.
>>>>
>>>>Any thoughts on how to set all the "Display Class" information back to would be welcome.
>>>>
>>>>Bob
>>>
>>>Bob, after making a backup (or 2) of your DBC files, open the DBC as a table (USE MyDBC.DBC) and then use the STRTRAN() function to do a mass change.
>>>
>>>HTH
>>>Barbara
>>
>>
>>Thanks for responding Barbara.
>>
>>That was my original plan, and may yet work, but I'm blocked with the replacement part. To put in a instruction, we won't be using the word "Default" itself. What's needed is either some unprintable characters representing Default, or nothing at all (I don't yet know which). I tried to figure out what was being used, but as there are more of those little boxes (the unprintable characters) immediately following where the Display Class is stored, I wasn't sure that reverse engineering this one was possible.
>>
>>Without documentation on the structure of the Memo field in MyDBC.Property we may be blocked from traditional data manipulation approaches such as STRTRAN(). I'm still working on it, but would welcome any more thoughts.
>>
>>Bob
>
>I'd make a sample DBC with 1 table and do some experimenting. You MAY find that you can just remove the control name (Best case). At worst, you scramble the DBC and you can then delete the sample.
>
>Barbara

As soon as I had writen that we may be blocked from traditional data manipulation approaches in my reply to you, I knew that I had to try it.

The Display Classes that I was working with in my DBG are Checkbox, Editbox, Spinner, and Textbox and appear in the DBC's property Memo field as shown here ... that is, Capitalized but otherwise lowercase.

Each instance is preceded by the following group of six characters (which I will show in their decimal representation, separated by commas) 0, 0, 0, 1, 0, 50

Each instance is followed by the following group of nine characters (again in decimal form) 0, 8, 0, 0, 0, 1, 0, 51, 0

Each package of 6 characters + a Display Class + 9 characters is preceded by either a 15, or a 16.

When VFP's MODI STRU is used to change an entry from a Display Class name to on the MODI STRU screen, the DBC gets changed so that the Display Class name is removed (the 6 char part is immediately followed by the 9 char part) and the leading 15 or 16 is changed to an 8.

I wrote some code to do this for the whole DBC. After running it, the DBC looked good, I could browse my tables, but if I tried a MODI STRU, the system ceased up with a VFP system fault that locked things up. Apparently there's some other table playing the game too that didn't like what I did ... perhaps my StoneField Database Toolkit tables.

I do have a fix though that works good enough. If I replace all 7 letter long Display Class entries in the DBC's property field (Editbox, Listbox, and Spinner) with a 7 character dummy string (7 x's) and Checkbox, the 8 character long name with 8 x's, leaving the 15's and 16's alone then everything works that I need to work.

If however, I go back to MODI STRU and change one of my field's Display Class to Spinner (as an example) from the status that I've just worked so hard to get, then ALL FIELDS in that table are be changed to Spinner. Not just the one that I changed manually.

Although there is still clearly something wrong, it doesn't look like it will hurt me. My plan now is to solve my screen building problem with this fix, and keep backups.

The code itself is simple, now that we know the rules. I refrain from publishing it here as I wouldn't want anyone to run it that didn't understand what it was doing. There is a potential for great mischief here. Send me a private note if you would like a copy Barbara.

Thanks for your thoughts and inspiration

Bob