> Do you suggest to use an object reference as a property of container? Honestly, I never did it before, but I saw several discussions here, how to do it, so I can try, if it's necessary.
>
No, drop the name of the control class to use in as a text string in the property sheet of the container. You may want to put an object reference in a property in the container - a property doesn't particularly care if what type of value it holds unless you or VFP do something to restrict it.
> Right, I also thought about size and type of field in the cursor as properties. If we would have object reference, we don't need to specify all these properties, they would be specified through embedded object properties, right?
>
The control (textbox) has a width; you need to adjust the Grid or listbox or whatever to be the right size. You might want to inherit the font and pitch from the control so that when you calculate the size it's based on the font you plan to use.
>
>>As far as the control (textbox), yes, I feel that the control should provide the details for verifying that the content of the textbox is well-formed (right number of characters, only valid characters) but that if there's context checking (ie only allow if it doesn't duplicate another line) it should be in
>
> Here is a good point, which is not obviously for me, how to solve. It should be some sort of Validate (custom) method for container, but how we'd fire it? What do you think? Since textbox doesn't need to know about this container class and could be used separately, we can not place call of parent Validate method in the textbox.valid(). Do we need to do it 'on the fly', e.g. then we'd add this control into container, like AddMethod()... It's not simple, and I've never done this before. So, what's your vision here?
>
If you only navigate in the list, ie a listbox, then the textbox is being given focus when it is being used to edit; you know already if it's an add or edit action when you switched controls. The Grid is a bit trickier, since you need to do this in two places - the AfterRowColumnChange gets fired whenever you move to a different record in the Grid, and the Valid fires when you have a LostFocus. If you like, the same approach of editing in the textbox and only displaying in the Grid is available to you.
> Yes, I saw Jim's approach. I think, his requires lots of work, because we don't know how many values our users would type. I said, that there would be no more than 5-6, but it was my assumption and it's not completely true. At least, I don't want to restrict my users. So, the task becomes very untrivial - how to add new controls in run-time. You mentioned dynamic arrays, but it's hard to implement, I beleive.
>
Jim's mechanism works well for 'Enter a list of known size' becuase it looks like an EditBox, which was a targeted behavior of yours at one point. Stripping out empty lines from an array of values isn't hard at all. Neither is adding more textboxes on the fly; The Grid or ListBox mechanism is easier because of availability of scrolling, the ability to confine the list display to an area of known size and the ability to determine if you're working on a 'new' thing are advantages from my POV.
