Edward,

Let me word it in a different way. If Visual FoxPro provides a
VISUAL "anything", in this case a TOOLBAR, then in addition to being
able to visually manipulate that "anything" through the Class Designer,
Visual FoxPro should provide the ability to VISUALLY instance that
"anything" and manipulate/design it.

That is what you and I do when we VISUALLY create a form class,
VISUALLY instance it, and then we use the Form Designer to VISUALLY
manipulate and design the instance.

I only used the Forms Designer because, actually, Visual FoxPro
treats toolbars as forms, so I am not wrong to have done that in
the first place, as you infer ! And that is the reason why
there is "seemingly" no "Visual Designer Tool" to allow you and
me, once we have created a Toolbar class, to then be able to go
and VISUALLY design an "instance" of that class.

Therefore, since we both know that formsets are not necessary
for toolbars, the Forms Designer, Visual FoxPro's current primary
tool for VISUALLY designing an "instance" of a toolbar class,
should not force the designer to include that instance into a
formset.

Alternatively, we should have a Toolbar Designer tool like we
have a Menu Designer and a Form Designer tool !

Michel.

================ Your message follows =======================

>Michel,
>
>Unfortunately, I have to make a conclusion that you don't understand me. I just can repeat that there is no any necessity to include toolbar to Form Designer. VFP complains against it, and it's absolutely right, because toolbar is not part of form container, and buttons, textboxes, etc. are part (might be) of this container. So, VFP reaction is natural and your approach is not. Again, there are no compelling reasons (but it doesn't mean that programmatic way is totally wrong) to use Add/Removeobject only. You can always make any visual manipulations opening toolbar class in Class Designer. If you want more, you can subclass either whole toolbar or its parts. If for some reason, you don't like it, well, I cannot help here.
>
>>Edward,
>>
>>I think you got me wrong there. What the problem is and has been all along
>>is that the form designer insists, when you try to add a toolbar, on
>>adding it as part of a formset. That is what the problem is.
>>
>>Yet there is nothing special about toolbars. Through your method,
>>and through my method, we have both shown that you do not need to
>>have a formset to use a toolbar.
>>
>>This constraint has forced both you and me into "workarounds". If
>>I design a form, and want one of my own buttons, I just select my
>>class library from the Forms Control toolbar and select my button
>>class. The same with textboxes, editboxes, etc.... Yet, if I select
>>a toolbar, the Forms Designer wants me to include it as part of a formset that
>>includes the current form I am using and the toolbar I am trying to
>>include.
>>
>>Because of that, you instantiate your toolbars in code, and I create
>>VISUAL toolbars based on my toolbar class, by conning FoxPro into temporarily
>>using my toolbar class as its default form class.
>>
>>So, while we have different approaches, we both understand what is going on
>>and we both understand the principles of classes. Far from me to infer
>>that you do not understand some of those principles !
>>
>>The reason for my approach is that we have spaces between buttons on
>>the toolbar, and they vary in sizes and positioning depending on what
>>the toolbar is showing, hence the need to really be doing it visually
>>rather than in code through ADDOBJECT/REMOVEOBJECT. While my method
>>works, it gives me the problem that when I properly release the toolbar,
>>FoxPro does not really do it properly and I then cannot do a MODIFY FORM
>>on the toolbar without first restarting FoxPro. That, I believe, is a
>>bug. Having read your, Nancy, and Bruce's answers, however, I shall
>>now have effectively a class for every toolbar we ever need, which is
>>crazy from a "purity" point of view, and then instantiate them in code
>>without ever needing ADDOBJECT/REMOVEOBJECT since each class will have
>>the entire toolbar designed exactly as I want it.
>>
>>From a purity point of view, however, FoxPro should allow the programmer
>>to add a toolbar without the formset constraints and both you and I could
>>then simply "pick them up" from the Forms Control toolbar, at will, just
>>like we do for command buttons, textboxes, etc...
>>
>>Michel.
>>================== Your original message follows ================
>>
>>>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.