>>Hi,
>>>>
>>I've seen, in some cases, the object being there but actually null - for instance, when the grid class was defined with .columncount=9, and then I set it to 3. In the debugger you still see column4...column9, but they're null.
>>
>>Could be this is one of such things, when an object member can't be properly removed under certain circumstances. My guess is that it matters whether it existed when the parent's .init() completed. I know I don't see it if I've removed it on time.
>>>>
>>
>>Sorry, do you mean the problem seems to occur when changes are made to the grid *before* or *after* it's .Init? FWIW, I tried removing the text object at every Init (before it's own, in the column's, in the grid and in the form's) without problems. Also changed the columncount at each stage without getting .NULL. :-(
>
>This thread began with "Thisform.grdTest.Column1.RemoveObject('text1')". Which releases all the methods and properties of the object 'text1', but not the object itself. - IOW, the text1 is still an object, but null. I have observed that if the text1 is removed during the column's .init(), then it doesn't show up in the debugger, provided there's another control to take over as .currentcontrol of the grid. If it's removed later, it goes null but remains as a member of the column. Though, I haven't used this for months, and my memory was proven to have weird refresh cycles, so I'd recommend not to trust me on this. It's simple to check, though.
>
>>Couple of oddities with this in the .Text1.Init() tho:
>>

>>WITH THISFORM
>>  .oT1 = .GRID.column1.text1
>>  .GRID.column1.REMOVEOBJECT('text1')  && oT1 = .NULL. Text1 not removed
>>   * RETURN .F.		&& Leaves form in limbo
>>ENDWITH
>>

>
>What happens with text1 when you exit its init? I figure it gets recreated if there's no other currentcontrol, which would be simple to test - just paint its background yellow before removing it, and you'd still get a white one.
>
>Assuming you do have another currentcontrol, I'm not sure that you can effectively remove text1 during its init. But I've tried just returning .f. from it (without the rest) and... while the form isn't really in a limbo, text1 is. It's still there, but when you look at it in the debugger (VFP8 SP1) its properties all have some weird four-character values, mostly unprintable. These look like four-byte integers interpreted as strings, IMO, which is indeed a symptom of a serious la-la land.
>
>However, if I added the new control in column.init:
>

this.NewObject("txttitle","txttitle","framework.vcx")
>this.CurrentControl="txttitle"
>this.txttitle.backcolor=0xffff
>this.txttitle.visible=.t.
>this.RemoveObject("text1")
>this.sparse=.f.
>dodefault()
>

>I got the yellow textbox alright, and text1 wasn't there in the debugger. When I set sparse=.t., I got the phantom text1 with no properties - and it still showed instead of txttitle, in white. The yellow textbox showed up only when you click on a cell in that column. Go figure.
>
>Seems to me that the proper meaning of sparse=.t. is "use default text1 whenever the cell doesn't have focus, and if text1 is not there, create it".

Hi,

Firstly I just noticed this is VFP9. I was using VFP8SP1. There, it seems, returning .F. from the .Text1.Init() *always* causes the form to fail to instantiate.

So, switching to VFP9, I see most of what you say - essentially a .Text1 control is created anytime there is not .CurrentControl on the column (and the behaviour when .Sparse=.T. is just an extension of this). I don't think there's any real difference whether .Text1 is removed in it's own Init() or later (just that it's still visible in the debugger in it's own Init). But the combination of .Remove("text1") and 'Return .F.' in it's init() will still stop the form instantiating...

Regards,
Viv