>>>Crud. CLEAR ALL still destroys it even if the object ref is a _screen property.
>>
>>Which is the reason I posted here :). Even with nodefault and return .f. in the release.
>>
>>I'll resort to some way of having the user restart the toolbar manually, until this gets solved.
>
>Hi Dragan,
>
>I think the cleanest solution would probably be to settle for a custom command for launching this toolbar via the main menu. Main menu changes will persist through a CLEAR ALL, as I recall. I generally would not encourage the routine use of CLEAR ALL, because it's so heavy handed, so my preference is to create custom cleanup logic that is appropriate to each application.
>
>The only trick I can think of offhand that might keep the toolbar alive through a CLEAR ALL would be to create a circular reference of the sort that causes those pesky failures to release an object, but this might be tricky to do, and it could result in some sort of flakiness. You know how it is, things never go wrong the way you'd like them to. That would be a violation of Murphy's Law. I haven't tried it, but you might see what happens if the toolbar stores a reference to itself in a custom property.

Nope, dies just the same. I even added a _screen.newobject("mycustom"...), and had this in toolbar.show:

this.oRef=_screen.mycustom
this.oref.obackref=this

trying to create a circular reference which would make this indestructible. It would probably work if any one of the two tried to .release, but nothing survives Clear All. I could maybe try with a session object which would contain uncommitted changes (those were always hard to kill), but I figure that would be too complicated and way overboard.