Hi,
I’m trying to understand the demo + my own code.
One thing that seems strange is line 551 of MainDemoWindow.cpp
MainDemoWindow::MainDemoWindow()
...
...
...
ContentComp* contentComp = new ContentComp (this);
Surely contentComp goes out of scope at the end of the function? Are constructors different? Mind you if you
delete contentComp; your program stops working :shock: .
Also, does the warning in ApplicationStartup.cpp
extend all the way down to the bottom (ie in derived classes and member variables)? I see you use pointers a lot. I always try and get away from them personally, but in the interests of a capable, cross platform and reasonably lightweight windowing framework…
If you check the documentation above ResizableWindow::setContentComponent() you should see:
The ResizableWindow keeps a SafePointer to the component you set with setContentComponent() and will delete it upon destruction so you don’t have t worry about it. If the pointer you mention originally goes out of scope the pointer just goes out of scope, delete is never called on the object it points to.
[quote]delete is never called on the object it points to.[/quote] Shirley delete is only ever called on pointers? Isn’t it the opposite of new, which returns a pointer?
Not sure I understand the references to content components. They don’t seem to be a class, but they are mentioned a /lot/. Is there any documentation for them?
I’m probably not the best person to explain this but will have a go with my understanding of it. This is more from a practical point of view rather than what the compiler actually does with the memory you ask it to create.
The new operator creates an object on the heap and you’re right, returns a pointer to that object. However pointers are really just a number, a reference to some block of memory so you can copy them around etc. without altering the memory. You have to de-reference the pointer to act on the object it points to (using *pointer or pointer->). Therefore you can call the new operator, store the pointer in a local variable and have it go out of scope. The object still exists in memory but you no longer have any reference to it, this is a typical way of leaking memory.
In the ResizableWindow when you call setContentComponent(pointer) you pass a pointer to your created object to the instance of that ResizableWindow, this is then held as a member variable in a special class called SafePointer. This class acts just like a normal pointer except you can check to see if it is zero before using it to avoid dereferencing a null pointer (which will cause a crash).
If you look in the destructor of ResizableWindow you’ll see that this SafePointer is used to delete the object that you set with setContentComponent(). It just means you don’t have to worry about deleting it yourself. You simply create the component and tell the window to use that as its content, it then effectively takes ownership of that object.
I think Jules uses ‘content component’ to indicate that there will be only one component held by the parent eg. windows, tabbed components, pop-ups etc. The idea is that you create a main component that creates all of its sub components (which could be many sliders, text boxes etc.) as children and then use the main component as the content of the window.
Sorry if that’s made it more confusing for you, there are definitely too many references to component in that explanation but that’s kind of unavoidable.
Ok, I just looked at the Demo a bit more and can see where you’re getting confused. Jules uses a class called ContentComp which manages all the menus and the selected demo. This takes the main window as an argument to its constructor as it needs add keyboard shortcuts to the window’s ApplicationCommandManager and check what type of title bar it is using.
In a simple app you don’t need to worry about this. have a look at the HelloWorld project for a simpler example. Its in extras/example projects.
Hi,
yes, take your point about copying pointers and the pointed-to-object still being there.
I’ve managed to get something up and running with fewer pointers and less polymorphism, will post at a later date.
I need to look into the content component thing more as well.
Not trying to knock JUCE, it’s an achievement to be proud of; but it has a different ethos to the furrow I’ve been ploughing for the last few years. :o
As I said before, I’m willing to put up with some intellectual suffering to get a capable, cross platform and reasonably lightweight windowing framework.
- more at