Firstly, you ignore my reply that subclassing is possible. Secondly, there is nothing difficult in 'non-visual' experimenting. Toolbar is simple, because it tends to 'autosize' itself, and objects will appear in exactly the same order as you Add(Object) them to a toolbar. Ultimately, it's always an opportunity to have container class which will host supposedly toolbared objects (if you really have enormous mix of them), you cannot argue against this approach having initially empty toolbar class (with some non-visual generic methods) and Add(Object) container object. Can you subclass container?

>Edward,
>
>I think that is where the difference lies. I need many toolbars
>in our applications, not just a main one.
>
>Secondly, adding/removing objects in code is a non-starter because
>of the visual need to know exactly what the toolbar will look like
>right down to the positions of icons, of buttons, etc...., without
>going through endless non-visual experimentation.
>
>Michel.
>
>=============== Your original message follows ================
>
>>So far, I didn't have necessity to subclass toolbar, but I cannot understand why you cannot do it the same way as for any other class, i.e. you can create your 'MyToolbar' class and then base next 'MyToolbar1' class on this class. I don't think that there is something crucial in this, I do it right now in my test environment, so it's doable. That's another story, that toolbar used to be something generic itself, i.e. you usually have just one for an application, but it's possible to have exceptions from this rule. In my current project (one of them) I have main application toolbar class and one more module toolbar class. This module toolbar can be instancited unlimited number of times, and it's based on one class, but this class itself Add/Remove objects from other classes, i.e. it's 'subclassed' enough.
>>So, again it's doable, simple and efficient :).
>>
>>>Edward,
>>>
>>>Exactly what I thought from your last message. A different class for every toolbar that you might need. It is the first time I am playing with toolbars but that does strike me as inconsistent with all the other VISUAL objects one can create !
>>>
>>>I wanted a standard toolbar class from which all my toolbars would be
>>>derived and which would give me a standard functionality across all
>>>my toolbars. You can do that with forms, buttons, almost everything
>>>visual, but, somehow, with toolbars, we have the inconsistence of having
>>>to have first a master toolbar class, and then a toolbar class based
>>>on the master toolbar class, for every toolbar that one ever wants to use.
>>>
>>>Doesn't that feel inconsistent to you ?
>>>
>>>Interesting.
>>>
>>>Michel.
>>>
>>>================ Your original message follows ===================
>>>
>>>>I create 'New' class based on 'Toolbar', and add buttons, etc. and code behind them in Class Designer.
>>>>
>>>>>Edward,
>>>>>
>>>>>How do you design the toolbar then ? You are not inferring designing
>>>>>it the long way round in code when one could do it visually, are you ?
>>>>>
>>>>>Give me another way to design a toolbar visually, with all the buttons that you
>>>>>want, interactions, method code, etc..., and I'll gladly jump at it.
>>>>>
>>>>>Michel.
>>>>>
>>>>>================= Your original message follows ====================
>>>>>
>>>>>>Michel, this is philosophical problem :). The truth is that in design time you create and edit classes, you may base these classes either on VFP base classes or subclass your own 'parent-level' classes. In run-time you instaciate objects from this classes, i.e. never create object visually. Yes, Form Designer is accomodation which allow you to combine objects of different classes together, but actual instanciatiuon will happen in run-time anyway. Toolbar is completely independent object (not incorporated into a form), so there is no any necessity to include it into Form Designer.
>>>>>>
>>>>>>>OK,
>>>>>>>
>>>>>>>Here is what I did :
>>>>>>>
>>>>>>>1) Create my toolbar class using CREATE \ CLASS \ TOOLBAR.
>>>>>>>
>>>>>>>2) Saved MYTOOLBAR class.
>>>>>>>
>>>>>>>3) Created a toolbar based on MYTOOLBAR class. The problem with
>>>>>>> that is that to be able to visually create the toolbar based on
>>>>>>> MYTOOLBAR class, I need to have a form open, and the form designer
>>>>>>> then tells you that you need to have a formset if you want to add the
>>>>>>> toolbar.
>>>>>>>
>>>>>>> To get around that I temporarily make my default FORM CLASS in
>>>>>>> TOOLS \ OPTIONS \ FORMS, the MYTOOLBAR class, and then click on
>>>>>>> NEW \ FORM and that gives me a toolbar ON ITS OWN that I can edit
>>>>>>> to my heart's content without needing to have it as part of a
>>>>>>> formset.
>>>>>>>
>>>>>>>4) The problem arises when I use the toolbar in code. Even after releasing it
>>>>>>> through all the available methods, including CLEAR ALL, etc...,
>>>>>>> when I try to MODIFY FORM on it to go and add code to it, say,
>>>>>>> I get FILE IN USE error.
>>>>>>>
>>>>>>>Now, it could be that I am doing it the wrong way as regards being able to
>>>>>>>visually create a toolbar and design it, without having it as part
>>>>>>>of a formset. If so, then I would love to know the way I should really do it.
>>>>>>>
>>>>>>>Regards,
>>>>>>>Michel.
>>>>>>>================== Your original message follows ===================
>>>>>>>
>>>>>>>>>Bruce,
>>>>>>>>>
>>>>>>>>>I can do that too. However, I have a different requirement. See below the response I gave someone else. I would be interested if when you try to do
>>>>>>>>>the same, you too get the same FILE IN USE error.
>>>>>>>>>
>>>>>>>>>Michel.
>>>>>>>>>
>>>>>>>>Michel, I would be interested in what you are trying to chnage that you need to have it in a form. But I think the .NULL. principle applies anyway. In your Destroy or app exit set the form.name to .NULL. and see what happens.