Windows Forms - picture box. How to delete an Image - c++

I am working in an application where there is a conbobox and a picturebox. The user selects a path and the conbobox loads paths to 2000 images, and displays the first one. When the user changes the index of the conbobox the image displayed changes, but I don't know how to delete the image in the picturebox.
If I just overwrite the image it doesnt do the job, as when I do it repeatedly the program crashes because of memory. How do I delete a image Inside the picturebox?
EDIT:
I made few changes and can't seem to reproduce the error again.. so maybe it was something else. but just for checking, is this code leaking memory?
tips: config is a singleton containing where some info, in this case, where the images are.
private: System::Void comboBox_image1_SelectedIndexChanged(System::Object^ sender, System::EventArgs^ e) {
System::String^ aux;
DIC_config* config=DIC_config::Instance();
if(config->images_path!=NULL){
aux=gcnew System::String(config->images_path);
aux=aux+"\\CAM_0\\Snap_0_0"+(this->comboBox_image1->SelectedIndex+1)+".bmp";
System::IO::FileStream^ image_file=gcnew System::IO::FileStream(aux,System::IO::FileMode::Open,System::IO::FileAccess::Read);
System::Drawing::Bitmap^ img = gcnew System::Drawing::Bitmap(image_file);
this->pictureBox_image1->Image=img;
//img->~Bitmap(); this doesnt work, deletes the image of picturebox and makes the program chrash
}
}

You have to dispose the old image. Forgetting to do so makes it likely your program runs out of unmanaged memory when the garbage collector doesn't run frequently enough. Bitmap objects are quite small, you can allocate thousands of them without ever triggering a GC, but can consume a lot of unmanaged memory for the pixel data. You dispose objects in C++/CLI with the delete operator, it calls IDisposable::Dispose().
Do note that the FileStream you use is also a disposable object. Doing it this way requires you to keep the stream opened while the bitmap is in use and close it afterwards. You correctly did not dispose the stream but forgot closing it. Too hard to get right, it is much easier to use the Bitmap constructor that accepts a string for the file path so the Bitmap class manages the underlying stream itself. Fix:
aux = config->images_path;
aux += ....;
System::Drawing::Bitmap^ img = gcnew System::Drawing::Bitmap(aux);
delete this->pictureBox_image1->Image;
this->pictureBox_image1->Image = img;

This doesn't work because you are trying to call destructor of the class, not the instance. Furthermore you do not need to call it as System::Drawing::Bitmap is under control of garbage collector, so the finalizer ( !Bitmap() ) will be called automatically if it's not referenced any longer.
What you can do if you want to close it in picturebox is
delete this->pictureBox_image1->Image;
image_file->Close(); //after closing/deleting the open bitmap
btw. your code is not pure c++, but c++/cli, so I've added the tag

First set a null pointer to the Image property and refresh the pictureBox, as given below,
pictureBox_image1->Image = nullptr;
pictureBox_image1->Refresh();

Related

Convert Mat to PvBuffer (from Pleora eBUS SDK lib.)

thank you in advance for reading this.
For better readability I'll list pieces of info. necessary in point form.
building an app based on eBUS player sample provided by Pleora.
Grabbing images in 16 bit gray in 50 fps.
my app is processing image data using openCV within the OnBufferDisplay function in DisplayThread
so far, I have successfully processed images suiting my needs and am trying to convert my Mat(processed already) data back to PvImage or PvBuffer s.t. the image can be displayed in the eBUS Player using the already existing display function(this way I can still use other features in the Player app without having to make too many modifications to the original app).
The difficulty arises from the fact that display functions and other important functions are hidden in dlls. I can only make modifications to what's exposed.
The processing procedure is basically:
void Display Thread::OnBufferDisplay(PvBuffer *aBuffer){
aBuffer->Attach(imageMat.data, 614400);
//where imageMat is init'd as
//imageMat = cv::Mat(cv::Size(imgWidth, imgHeight), CV_16U);
//process.. the data....
//at this point, I Have my Mat object ready to go.
//supposed to create or have another PvImage or PvBuffer with the processed datahere for displaying.
//Display
mDisplay->Display(*aBuffer);
}
What I have tried so far is:
memcpy(aBuffer->GetDataPointer(), imageMat.data 614400);
//and
aBuffer->free();
//and/or
aBuffer->Detach();
//then
aBuffer->Alloc(614400); //since 640 * 480 in 16 bit gray
memcpy( Mat.data to buffer->datapointer);
Please help me clarify the following:
I have discovered after using Attach(), the passed aBuffer does no longer properly display image. Does that mean this function not just copies the data from aBuffer to imageMat.data but erases the data in aBuffer and then copies it to imageMat.data?
I went for Attach() because memcpy(imageMat.data, aBuffer->GetDataPinter(), size); didn't work. It didn't copy the data properly like the way Attach() does. Anybody know why?
The description for Attach() provided by Pleora is "Attach this PvBuffer to an external memory buffer. To use an internal memory buffer, use Alloc.".
In summary,
How do you properly create a PvImage or a PvBuffer object that contains the data from my Mat object in order to pass to the Display() function?
Are there any detours to make this work without having to create such objects?

QGraphicsItem is not visible after adding to scene

I'm working on a diagram visualisation tool and I ran into an issue where my QGraphicsScene does not display a shared_ptr<DiagramItem> when a raw pointer obtained via .get() is passed to scene->addItem().
Subsequent check via scene->items() shows that my DiagramItem is not a part of the scene. My guess is that it got freed as the refcounter on the shared_ptr will be zero after leaving the scope of the testing function...
But that was the testing case. In my actual code I'm using a shared_ptr that I got from elsewhere and is definitely present in memory with a non-zero refcounter. I get the raw pointer of that and pass it to scene->addItem(). It is also not displayed, but this time it is present in scene->items(). So why is it not being drawn?
If I switch from using shared_ptr<DiagramItem> to DiagramItem* then the issue disappears and everything is displayed properly. But due to limitations from the rest of the project, I cannot easily abandon smart pointers here, nor do I want to.
Did I run into some kind of memory limitation or am I doing something wrong?
I already tried calling show() and update() on the item and increasing the scene size in case the item doesn't fit (it does). I also tried breakpointing the paint() method, but that one doesn't get called at all.
I found a possibly related question here where similar behaviour occurs due to the object going out of scope and being deallocated, but that doesn't seem to be the case with my actual DiagramItem.
class DiagramItem : public QGraphicsItem
{
...
}
//Create scene
auto scene = new QGraphicsScene(nullptr);
//Item is created OR obtained from elsewhere
auto item1 = std::make_shared<DiagramItem>(nullptr, QString("aaa"), true);
auto item2 = GetDiagramItem(...);
//Raw pointers get passed to addItem
scene->addItem(item1.get());
scene->addItem(item2.get());
//Item1 is not present at all (directly created DiagramItem)
//Item2 is present but invisible (DiagramItem passed from elsewhere)
//myItem gets Item2
auto myItem = scene->items()[0];
...

Qt Parent to delete variable after child has closed

I'm writing an application in C++ using the Qt library. There is a central window (the parent) and all the children are launched when needed. Since a number of these windows can be open multiple times, but display different data, I'm declaring the objects with new. Here is an example of what I've got:
Home_Window.hpp
View_Window *SomeWindow;
Home_Window.cpp
void Home_Window::on_WindowButton_clicked()
{
SomeWindow = new View_Window();
SomeWindow->show();
}
What I want to do, is delete the object, when the window is closed to reduce the memory footprint of the application. I've already been able to delete all of the objects contained in the child window to reduce memory usage, but the core object still lingers, and if, through a single day a user opens and closes 1000's of windows, and each object holds onto 40-50KB of memory, the footprint of the application goes from a couple of MBs of memory to 100's of MBs of Memory.
I've not been able to find a guide online that would allow me to achieve this. I was considering a slot and signal pair, as I know that when a window is closed, it sends the QObject::destroyed() signal. Only issue, is I've not tried to setup a signal and slot pair like this.
Any suggestions are appreciated.
to delete the window when it is closed, you can set the WA_DeleteOnClose attribute on it. Your on_WindowButton_clicked() should look something like:
void Home_Window::on_WindowButton_clicked()
{
View_Window* w= new View_Window();
w->setAttribute(WA_DeleteOnClose);
w->show();
}
This way, you don't have to worry about destroying w yourself, it will get deleted automatically when it is closed.
You need to do two things:
The window's lifetime must be managed even if the window isn't closed.
You can give it a parent that you know will end its life at some point. Or you can use a QScopedPointer or std::unique_ptr.
The window must delete itself when it's closed.
void Home_Window::on_WindowButton_clicked()
{
// parent window flags
// vvvv vvvvvvvvvv
auto window = new View_Window(this, Qt::Dialog); /* 1. */
window->setAttribute(Qt::WA_DeleteOnClose); /* 2. */
window->show();
}
At the very least, you should set the Qt::Window flag. The Qt::Dialog includes the Qt::Window flag, and also declares the window to be a dialog box - that fact has platform-specific interpretation; read more about window flags here.
If your View_Window's API is broken, and it doesn't take the window flags as the 2nd argument to the constructor, you need to set them separately:
window->setWindowFlags(Qt::Dialog);
Every widget should be taking Qt::WindowFlags as the optional, 2nd argument to the constructor, with a default value reflecting the usual use of the window. That's the expectation set by all of Qt's widgets.
You can try to delete the pointer to ViewWindow by using: delete SomeWindow;

SDL2 Memory Leaks C++

So when I run the app, at the biginning every thing runs smooth, but the more it goes, the slower it is. I looked at the memory it was using and when it reaches 400 mb it completely stops for 30 secs and then drop back to 200.
I am pretty new to SDL2, and I assume it is because each frame I call:
optionsTS = TTF_RenderText_Blended(font, "Options.", blanc);
optionsT = SDL_CreateTextureFromSurface(renderer, optionsTS);
for example and I have plenty of them.
The problem is that I don't know how to delete properly the object each frame, because if I do a SDL_FreeSurface I get an error.
I won't publish my whole code because it's a mess, but if you want it, feel free to ask.
Do you know how to fix that?
Just thought I would turn my comment into an answer.
In your code you call
optionsTS = TTF_RenderText_Blended(font, "Options.", blanc);
optionsT = SDL_CreateTextureFromSurface(renderer, optionsTS);
every frame, I suspect that if you remove them from there, initialise them outwith of the render loop and simply pass them in as arguments, you should lose the memory leak: the reason being that you will create only one in-memory instance of each and then you can repeatedly use them as needed. On looking at it again, I suspect that you could destroy optionTS once you have made optionT, that way you will save even more memory. (not tested yet as my main machine just crashed this weekend, and I am still re-installing drivers and VS2010)
As a general rule, try and not create/destroy any objects in the render loop, tends to get big and messy fast.
Consider taking advantage of RAII in C++ if possible.
For example, create a class that wraps an SDL_Surface and calls SDL_FreeSurface in the destructor.
class MySurface
{
public:
MySurface(SDL_Surface & surface) : m_surface(surface) {}
~MySurface() {SDL_FreeSurface(m_surface);}
SDL_Surface & GetSDLSurface() {return m_surface;}
private:
SDL_Surface & m_surface;
};
You would then create an instance of MySurface every time you grabbed an SDL_Surface from the SDL API, and you won't have to worry about when or whether to free that surface. The surface will be freed as soon as your instance of MySurface goes out of scope.
I'm certain better implementations can be written and tailored to your needs, but at a minimum something similar to this may prevent you from having leaks in the future.

what happen if i call "delele" a CCLayer object with reference count greater than 0

I used one scene and many layers for my game.
when user go to another game screen I remove current layer from scene , delete current layer, set current layer = NULL, then create a new layer, add it to the scene
void UIManager::openScreen(int screenId){
m_currentScreen = screenId;
CCLayer *newLayer;
if(screenId == MENU_SCREEN){
newLayer = new MenuLayer();
}else{
...
}
if(m_currentLayer != NULL){
m_scene->removeChild(m_currentLayer, true);
delete m_currentLayer;
m_currentLayer = NULL;
}
m_scene->addChild(newLayer);
m_currentLayer = newLayer;
}
On some layers, i call some CCHttpRequest with callback:
setResponseCallback(CCObject* pTarget, SEL_CallFuncND pSelector)
And i use "this" to pass to "pTarget", it means first parameter for this callback is my layer which defined a SEL_CallFuncND selector.
The problem is when user switch between screens(layers) to quick, but some slow CCHttpRequest still not completed, and the response callback will be called after UIManager delete the layer then my game crash :(. I don't want to lock the screen and force use wait the http request complete. User should can abort loading a screen and switch to the next screen they want.
So should i call "delete m_currentLayer" instead of m_currentLayer->release()?
As i know, release will decrease the reference count, i just want to make sure "noone" use the m_currentLayer rather than m_scene so i used "delete". But i'm not sure it is correct way.
If i use release function in this case, i worry some places in code use the layer and increase the retain count of the layer, is this can make a leak memory issue?
if m_currentLayer->retainCount() = 4 and i call "delete m_currentLayer", then what will happen with m_currentLayer?
I'm confusing with these issues, please someone give me an advide.
Thank you very much!
You should not delete your nodes manually. It can cause a bunch of errors. Reference
counting convention is to call retain when you need to be sure that object still exists and call release when you do not need this object.
Use retain and release only inside object, that really needs other object to exist. In any other case you can use assign property(do not retain object and check it is not NULL) before doing something with it. If some object(let's call it a), that is not yours(CCNode, for example) retains the other object(let's call it b), deleting b manually can cause bad access error, because a will be sure that b still exists. And can call something like b->doSmth()
Your m_currentLayer will be deleted, but it can cause errors because retain count 4 means that 4 objects can cause bad access error described above.