Barbara (and all other readers),

Ok, I admit it. I'm one of those people who come up with the snappy reply five seconds too late. And, yeah, what follows is a little off the subject of this thread. But do you realize that, to put it in the local vernacular, they "done Forrest Gumped" us on this? You know, "Stupid is as stupid does."

Consider this: Dear old (beloved) MS wants us to use the registry to store application settings. But do they store the toolbar settings (including customization) there? Nope! Then surely they use an INI file. Wrong again. The resource file? Yep! And on top of it, there is, apparently, no way to make sense of the data there (it's binary data) and be able to manipulate it without going through some unnecessary steps. Jeez, thanks MS.

I can understand (for backward compatibility) why they just didn't do away with it (the resource file). My ancient (early '90s) FPD/FPW apps store data there. But the concept of toolbars is new (at least within VFP), and there's nothing to be lost in storing customized settings for them in the registry. Plus they gave us an NVC to access it with.

It seems to me that here's another thing that we should speak up about. And this ties back into the thread. If they won't make the report form an object, then at least give us access to the methods, events and properties of toolbar that appear when we PREVIEW a report. Is that too much to ask?

Of course, this is just IMHO, I could be wrong.

George