>>>In changing a regular textbox on a form to one that was based on a class I created, I had to carry over some code that was in the LostFocus and the Refresh methods that was form specific. The LostFocus just had a THISFORM.REFRESH call in it. I was amazed how fast you can crash VFP if you accidentally put that code in the Refresh method of the textbox! <g>
>>
>>I tried this with two stock textboxes and a stock commandbutton on the form -- it did not crash... I tried putting a thisform.Refresh() in the Refresh method of the textbox -- it errored out with Nesting Level (recursive calling). But no crash...
>
>Well, then I was right. I can crash it faster than you! <g> I might not have explained that very well. The Refresh had been in the LostFocus. When I changed out the textbox I accidentally switched the LostFocus and Refresh code, so the Refresh called THISFORM.REFRESH and that sent VFP into - effectively - an endless loop. Not sure why it crashed for me and not for you.

Maybe your refresh code is doing time consuming task + stacksize is increased and you didn't wait long enough to get the error.
PS: An endless loop is not crash. It's working anyway:) When you say crash I think of things like C..5 where you don't have chance to do anything and kicked out. With endless loops 'set escape on' for example provides a way to break the loop.
Cetin