How do you instantiate a Toolbar in code?

I want to be able to enable/disable toolbar buttons from within the ContentsChanged event of myWindow (subclass of Window) but to do that, my understanding is that I must instantiate the toolbar in code rather than drag it into the layout (since myWindow doesn’t have a layout editor).

I can’t seem to figure this out so I started with an empty project and Window1 to test it but I’m still stuck.

Here are the steps (starting with an empty Xojo Desktop project):

  1. Add a Toolbar to the project… “Toolbar1”
  2. Add a ToolButton to Toolbar1… “ToolItem1”
  3. Add a property to Window1… myToolbar As Toolbar1
  4. Instantiate the toolbar in the Open event handler of Window1… myToolbar = New Toolbar1

Run the program… no Toolbar… why?

Learning myself
https://docs.xojo.com/UserGuide:Desktop_Toolbars

You got an example at http://docs.xojo.com/Toolbar

because you instanciate the toolbar as a property of myWindow, and not as a toolbar of myWindow
there should be a property toolbar, or a method SetWindowToolbar, but there isn’t.
you should add the toolbar in the window, with the IDE , and with all needed buttons, as non-visible
then set each visible button you need with code.

@Philip Cumpston
Your link isn’t working.
The link shown is correct, but when you hover/click the link you can see there is an extra letter (m) at the end of the url.
This is the correct link without the extra m.
https://docs.xojo.com/UserGuide:Desktop_Toolbars

It would be good for new comers (or those who never use the feature [Desktop Toolbars for example]) to put a link to a sample project at the page bottom there: Desktop Toolbars .

[quote=440780:@Philip Cumpston]Learning myself
https://docs.xojo.com/UserGuide:Desktop_Toolbars[/quote]

I’ve read over the documentation thoroughly before submitting my question here and neither of these doc pages talk about how to instantiate a Toolbar in code. They provide an example of setting up the ToolButtons in code but the example clearly states that the Toolbar was added to the Window in the IDE… not in code.

[quote=440794:@Jean-Yves Pochez]because you instanciate the toolbar as a property of myWindow, and not as a toolbar of myWindow
there should be a property toolbar, or a method SetWindowToolbar, but there isn’t.
you should add the toolbar in the window, with the IDE , and with all needed buttons, as non-visible
then set each visible button you need with code.[/quote]

The whole point is to NOT add the toolbar with the IDE.

I followed the instructions on this page… AddHandler … only I attempted to create a Toolbar instead of a Timer.

Here is a little background to the issue that I’m having…

Almost 50% of the windows in my project will be ‘edit’ windows… meaning that they will present an object as a form for editing. If the user changes the contents of any of the fields in the form, certain items in the toolbar need to be enabled… such as a ‘Save’ button (or a ‘Reset’ button that reverts all fields back to their original state).

Using the ContentsChanged event of the window, I can easily enable/disable buttons in the toolbar. I simply reference the Toolbar object that was dragged into it in the IDE. No problem. As per the instructions in the docs, I can even set up all the buttons in the Open event of the toolbar.

However, I’ll need this functionality in 50% of my windows.

So, it would seem to be a good idea to abstract this functionality into a subclass of Window. I can create a subclass of Window and call it, “myWindow”. I can handle the ContentsChanged event in myWindow but when I attempt to make reference to the toolbar… there is no toolbar! Because it’s a subclass, I have no layout into which I can drag a toolbar. I must instantiate the toolbar in code so that I can reference it in my events and methods.

This brings me to my present dilemma… how do you instantiate a toolbar in code?

What you did not understand is that a toolbar dragged to the window can have it’s buttons enabled and disabled.

You then went chasing an untamed ornithoid, ad Start Trek’s Data would say.

Follow exactly the example I pointed to at http://docs.xojo.com/Toolbar, and add a button to the window with this code inside:

OpenButton.enabled = not OpenButton.enabled

That should help you achieve what you want to do.

[quote=440819:@Michel Bujardet]What you did not understand is that a toolbar dragged to the window can have it’s buttons enabled and disabled.

Follow exactly the example I pointed to at http://docs.xojo.com/Toolbar, and add a button to the window with this code inside:

OpenButton.enabled = not OpenButton.enabled

That should help you achieve what you want to do.[/quote]

It does not. Perhaps a screenshot of my project would help…

Kristin, you are still trying what did not work before.

  1. Drag a toolbar to the project, on the left hand side (Toolbar1)
  2. Drag that toolbar to the window (Toolbar11)

You can then interact with that control as with any other one. See link to the sample project I made below.

toolbar.xojo_binary_project

Dragging a Toolbar to the project and then dragging the resulting Toolbar1 to Window1 works perfectly… as expected… However, how do I do that if I subclass Window to myWindow? There is no layout into which I can drag a Toolbar.

again, you can’t !
I have the same problem as you, want an class editingWindow, with an optionnal toolbar.
the way I did it is, check in myWindowClass is there is a toolbar with this :

Public Function HasToolbar(extends w as Window) as Boolean Return (w.GetToolbar <> nil) End Function
and this

[code]Public Function GetToolbar(extends w as Window) as Toolbar
dim res as Toolbar = Nil
dim c as Control

for i as Integer = 0 to w.ControlCount-1
c = w.Control(i)
if c isa Toolbar then
res = Toolbar©
exit For
end if
next

Return res
End Function
[/code]

then I drag a toolbar in every window instance that needs a toolbar, no toolbar in window that don’t need it
in the abstract myWindow class I check if there is a toolbar then I deal with it enabling, masking what needed.

you can’t create a toolbar by code, as you would do with a timer, it’s not permitted by xojo
(althought it would be nice …)

[quote=440794:@Jean-Yves Pochez]because you instanciate the toolbar as a property of myWindow, and not as a toolbar of myWindow
there should be a property toolbar, or a method SetWindowToolbar, but there isn’t.
you should add the toolbar in the window, with the IDE , and with all needed buttons, as non-visible
then set each visible button you need with code.[/quote]

Ah… thank you! Sorry, I didn’t understand your reply when I first read it. The answer is that it can’t be done.

Although I’m disappointed by this, I am relieved to find out that I’m not going crazy. :wink:

As I said, you were chasing a wild goose.

But if I understood right your first post, you wanted to do that only to be able to enable/disable ToolButtons.

As my little example project shows, it is possible without a whimsical code instantiation :smiley:

[quote=440826:@Michel Bujardet]As I said, you were chasing a wild goose.

But if I understood right your first post, you wanted to do that only to be able to enable/disable ToolButtons.

As my little example project shows, it is possible without a whimsical code instantiation :D[/quote]

I presented a basic example in an attempt to not over-complicate the question. The idea was that what worked on Window1 should also work on myWindow. Of course, if you’re only doing it for one window then it wouldn’t make sense but now imagine that you have 250 tables in your database… for which you must create both a ListWindow and an EditWindow.

Toolbars in Xojo are strange. You must first add the Toolbar to the project… but you can’t call it “Toolbar”… so, what do you call it? “myToolbar”? “MainToolBar”? “EditToolbar” vs. “ListToolbar”?

Then, you must drag that into your window… which creates a new thing that you must also name… what do you call it? “ThisWindowsToolbar”? Rename every toolbar to match the content of the window: “UserEditToolbar”?

“Toolbar1” and “Toolbar11” just seems so amateur.

I agree with @Jean-Yves Pochez , a toolbar should be built into every Window and simply made visible when needed. It seems like such a really basic thing to do. (see what I did there?) :wink:

I did it the way in my previous post https://forum.xojo.com/conversation/post/440824
and it works fine. I made an “edittoolbar” I add at each instance of an edit window, and an “listtoolbar” I instance for each list window. I have a global list window, and a global edit window with no toolbar (but I could add one if needed)
works fine for some times now.

First off I would not create 250 windows to edit tables
I’d have one windows which could edit any table and one that could lost any table - 2 windows in total
And be able to open multiple instances of these windows so if I need to edit or list more than one table at a time I can

There are a lot of controls you cannot add on the fly like you’re trying to do
You cant just run

   dim pb as new PushButton
   // .. other code here to somehow get the pushbutton added to the windows control list (which is not a property)

Toolbars re not alone in this regard

Some of this is forced on Xojo by the various OS level frameworks
Some imposed on us because of how the Xojo frameworks work

Basically you cant get them initialized and set up so that events are handled properly etc,

The other thing is that with Windows you cannot inherit the user interface.
So if you create a Window that has a toolbar on it you cant use that Window as the base class for other windows an inherit the existing layout.

Writing the same code to edit and listtables over & over in multiple copies of the same window would seem to violate your own previous post

At most make 2 windows that you can configure to edit / list ANY table instead of creating multiple copies

[quote=440835:@Norman Palardy]First off I would not create 250 windows to edit tables
I’d have one windows which could edit any table and one that could lost any table - 2 windows in total
And be able to open multiple instances of these windows so if I need to edit or list more than one table at a time I can[/quote]

I agree… and perhaps my 250 number was a bit of an exaggeration but even if I only have 2 resources to edit, it feels strange to have to write the same code in the ContentsChanged event handler for both of them.

I also considered the same strategy as you propose here… and I think it would work fine for the ListWindow as columns can easily be added in code… but how would you create a window that could edit any table? How would you handle an EditWindow in which the presentation of fields needs to be tailored to each object? For example, a simple UserEditWindow might only have four or five fields but a more complex object might have 20 or more fields… organized in tabs… and related lists. For basic edit windows, we might get away with using a generic EditWindow but I’m not sure how it could work for all of them.

Personally, I think that there is a time and a place for abstraction but the crafting of the user interface is not one of them.

Building each window individually seems like the best way but even the best of us resort to writing a program to write our programs. (ie: ARGen, StormORM) To me, the entire idea of Active Record goes against the very philosophy of Xojo… but that’s a topic for a different thread.

Nope. Sorry. I hold Xojo to a higher standard than this. The original promise of Real Basic was programming ‘for the rest of us’. It promised native, built-in controls that you could arrange in the IDE and then ‘wire up’ with basic code. Instead, I’m having to subclass everything and ‘roll my own’ with complex code (if anyone even mentions a ‘declare’… I swear… ) in order to build even the most basic of business applications. Where is the DateControl? How about an EmailField that validates format… or an IntegerField or CurrencyField? These are low hanging fruit and yet there is a PasswordField?!

The DataControl was poorly implemented but genius in it’s original conception. Why deprecate it? Why not modernize it? The binding of layout controls to database columns was a great idea but no one has ‘flipped’ through records with ‘next’ and ‘previous’ buttons since HyperCard.

It’s no wonder to me why new Xojo users give up. I’ve tried and failed with Xojo more times over the past 20 years than I care to admit. I’ve bought the books, I’ve watched videos… I even subscribed to the magazine… and yet each time I get a little beyond Eddie’s Electronics, I get tripped up with what seem to be obvious omissions in the IDE. API 2.0 sounds like a great start but it’s going take a lot more than renaming some functions.