>>>I think the class.init code runs when it's instantiated, even in design mode (i.e. we're not moving just cardboard cutouts, it's live frogs and eels). All you have to do is to know when you're in design mode (maybe by checking aSelObj() function?) and then run this from within the .init - the only obstacle is that this code is always there, even if you're not in design mode.
>>
>>I don't think so Dragan, at least it doesn't run the Init code when I drop a control on a form. :(
>
>I remember I had problems with VPM forms which would do wierd things in some cases, but after running a simple test now (watch on prog() in debugger and instantiating one of its forms from pure Fox, no path, no usual environment), I saw that no code fires at all. I now seem to recall that it actually happened when I classed any of those forms and createobject()ed them - the beast was bitching about its miserable life without dataenvironment, can't breathe without it etc.

We ran into a similar circumstance. We have a function call to set the .Icon property for a form (class). This code fires when you bring up the class in the designer, similar to the function in the tag.

Still only useful for a form class, not any other type of class. Maybe there's some other property on Custom class? I don't know.

>
>So, this was a dead end. Too bad. You'll need a builder lock then. I know about bricks, concrete etc, just find a locksmith.
>
>>Having ANY code that I could reliably fire off at design time automatically wouldn't be a problem if it was always there, as long as I could determine design vs runtime.
>
>"So would daddy, son"

LOL!