Hi Ken.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>I'm starting to look at VB as a long time VFP developer
>>>and have some basic (no pun intended) questions.
>>>I hope expereinced VB developers won't get
>>>irritated at me, but here goes:

>>>1 - VB property sheet seems to list a lot fewer properties
>>>than analagous control in VFP - what's up with that?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Well, mainly, there *are* fewer. This is a big advantage that VFP has over VB -- in one way of thinking - VFP gives you a much finer level of control with its properties, events, and methods. For instance, in VB you have a Change() event, while in VFP you have InteractiveChange() and ProgrammaticChange(). And so on for other properties, etc. etc. (On the other hand, I have heard it argued that this is what makes VB less intimidating to novices. Hmmm. Maybe. Then again, why not move to Access, where there are even fewer PEMs? Hell, let's just return to FP2.x days where you had a Form.Activate and a few Click()'s? ;-) Also, this argument for simplicity is made less potent every time a new VB event is added -- like Validate() -- and the simple-is-better partisans go all ga-ga over it -- just my two cents!).

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>2 - The VB property sheet seems to be a pure property
>>sheets as opposed to the PEM property sheet in VFP - is this correct?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Yes, you are right. To get at VB methods and events you need to use the code window method pulldown. Drives me crazy, gotta admit, but once you are used to it....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
3 - Is it my imagination or are only some of the methods-props avaialable to an object actually displayed in the editor or prop sheet?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I believe that only those properties that can be changed at design time are listed. But that doesn't narrow down *too* much (and besides, how useful is it really to have items like Z-Order listed on a PEM sheet?). Anyway, my guess is that mainly this perception is due to the fact that ther are so many fewer properties to start with.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>4 - How does one drill down into a data grid to put code
>>>into the various columns or textboxes within columns?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Depends which grid you are using. Mainly, you can't do it. In most grids, events are captured at the control (grid) level instead, and you need to react there, referencing the index or identifier of the cell that generated the event. This doesn't bother me so much because even in VFP I like this approach better (just my own preference though).

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>5 - Do I have no way to create my own visual class? I
>>>mean - I know VB doesn't subclass - but I can't create
>>>my own textbox for example to use everyehere?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Simple answer: Nope. That's subclassing. More complicated answer # 1: you can create active-X controls that you can use, and which will work fine. I maintain in fact that 80% of the "inheritance" I see VFP programmers use could either be accomplished with Active-X or is overkill anyway, so this probably isn't as bad as it seems for most apps (it's a killer for the other 20% though!). Still, using ActiveX rather than subclassing hasn't stopped me from fairly rapid development of fairly complex apps using VB. More complicated answer #2: check out the Template concept in VB for some form and menu reusability. The menu stuff in particular is helpful.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Vin