Ok, Jason. Thereâs a number of shennanigans in your code. Iâll point you the ones that jump out at me, but I suspect you should take a good look at some more C++ books and try to really get your head around object oriented programming. Please excuse me amusing myself as I write this.
OK, so, from the top.
test is a pointer to a drawable. I hope this is there just to test compilation? In your code, that pointer doesnât get initialized. Consider using a stack object, like:
Drawable test();
That will be safer - even for tests - especially for tests, since pointer problems donât help track things down.
Then youâre declaring a class DemoToolbarItemFactory, subclassed from ToolbarItemFactory. ToolbarItemFactory doesnât inherit anything, as far as I can tell. So, your new class will be able to call methods:
it declares,
that ToolbarItemFactory declares.
Youâve declared a âbuttonClickedâ method. That is not a method of ToolbarItemFactory, so it exists only in DemoToolbarItemFactory. Only other code that knows about (has included the header for) your class will ever be able to call that. In essence, that means your code only.
Youâve overriden getAllToolbarItemIds, getDefaultItemSet and createItem. Any code that knows about ToolbarItemFactoryâs (most of juce) will able to call them.
But the code in createItem gets a bit wiggy.
Hereâs the usual structure of a switch"
switch (int blahBlah)
{
case 1:
dostuff
break;
case 2:
{
do stuff in a sub-section so you can use local variables
}
break;
case 3:
do more stuff
// Caution - fall-through. Mark well, since we drop down and also do the case 4 stuff
case 4:
do even more stuff
break;
case 5:
case 6:
apparently, thereâs stuff left to do
break;
default:
stuff
break;
}
Note - every case has a break. In the one case I chose to not to break right after, I understand it will fall through. In your code, you chose to return right from the case. Thatâs OK, I suppose. I tend not to do that - I would put a toolbarbutton into a pointer and return it at the end - then I can also check if it worked/caught any cases and do something if it didnât.
Returning early isnât wrong, but not putting a break could well screw up the compiler and is bad juju.
But that case is also where it goes off the other rail.
return new ToolbarButton (itemId, T(âinfoâ), test, 0);
This creates a Toolbar button with an unitialized pointer for a drawable. Thatâs not a blank pointer, thatâs some random bits, left over from whatever else youâve been doing on your computer. It might be (worst case) a memory address in your programâs legal space, but more likely itâs be cruft. Your commented out alternative:
return new ToolbarButton (itemId, T(âinfoâ), Drawable::createFromImageData (BinaryData::letterI_png, BinaryData::letterI_pngSize), 0);
Is more likely to be happy. In that line, you have returned a button from the function. The function is now gone, kaput, shuffled off this mortal coil etc.
That means your coup-de-grace never even takes the stage. Most compilers would probably optimize is out, if they were willing to compile it.
test->addButtonListener (this);
OK, so this says:
using the instance pointed to be the pointer âtestâ, which is an object of type âDrawableâ, execute the method addButtonListener, with the parameter of âthisâ, to whit a pointer to an instance of DemoToolbarItemFactory.
C++ is silly isnât it? Iâm not dim, but C++ was the hardest thing I ever had to learn.
So, putting aside the fact that test may well be an unitialized pointer, and the worst thing it could do then would be to try to actually do it:
- Drawable is not a button, so doesnât have an addButtonListener method.
- DemoToolbarItemFactory is not a buttonlistener, so a pointer to one canât be used as a parameter to addButtonListener anyway.
This is all the C++ compiler protecting you.
So, deep breath. Let me try to guess at what you actually need.
Pick a class to be your âcontrollerâ. That class should be able to access your data, or send a command to a class about the button press. Make that class - it could be one you already have, like the window, or your app inherit from buttonlistener.
When you make the factory, make sure it can access the controller class. Do, maybe, something like this:
[code]ToolbarItemComponent* createItem (const int itemId)
{
ToolbarItemComponent* newItem = NULL;
switch (itemID)
{
case 1:
newItem = new ToolbarButton (itemId, T(âinfoâ), Drawable::createFromImageData (BinaryData::letterI_png, BinaryData::letterI_pngSize), 0);
break;
etc
}
if (newItem)
{
newItem-> addButtonListener (jController);
}
return newItem;
}[/code]
Now in your controller class, implement a buttonClicked method. In fact, if you donât, since it inherits from buttonListener, the compiler will throw an error.
C++, believe it or not, is your friend.
Hope that helps,
Bruce
