Hey guys,
I'm using getOpenFileName to have someone open the directory window and choose a file.
When I use getOpenFileName and the window pops up, if I close the window or cancel, it'll close normally.
But when I press Open on a file I've selected in the window, all of my Images disappear and out prints a bunch of "Could not open file of texture: filename.png" (even though it's the correct image path, just disappears).
The c_str() function returns a pointer to the underlying data in your std::string. Since fileNameStr is local to the function, as soon as you return from the function, it gets deleted because it falls out of scope, and thus, the pointer returned by c_str() is no longer valid.
By the way, you shouldn't cast out the const qualifier, as the data pointed by a std::string should never be modified directly.
I've found that after selecting a file in OpenFileName, it's as if my program loses rights to opening any file.
If I read a file before OpenFileName select, the read is successful. After OpenFileName select, it says the same file couldn't be read
Now you return a global variable which is only initialized with "" but never changed.
The problem above (previously posted code, not the one directly above this post) is - you set your pointer to a string (called filename) which is only on the stack. That memory is invalid as soon as your function returns. So the pointer (fileNameStr) is now basically pointing to whatever is now written in memory (which can be anything - sometimes you get lucky and the old content is still there, otherwise you might get anything else). Be lazy instead and work with something like std::string or irr::stringc ... those classes care about memory handling internally so you can return them from a local function (and with modern c++11 compilers that's even done very effective internally). You can't do that with pointers when the stuff they point to is only memory on the stack. With pointers you have to allocate that memory yourself and then copy the string to it. And ensure that memory stays valid. For example by passing the already allocated memory to the function (and yes that is tricky because you don't know which size it will need - so you either allocate so much outside that it will be guaranteed enough or you have to call a function first which tells you how much memory will be needed and then allocated that). Alternatively (but this is mostly bad design) by allocating it inside the function with new and then returning it (and you have to make sure to clean it up then somewhere or you get a memory leak). Reason that's bad design is that it's usually easier if the allocation and destruction is happening on the same level in your code (so if a function allocates it but can't release it because it has to return the memory you will have to start documenting this and make people who use the function aware that they have to clean up some memory later on).
I guess what I'm not understanding is how this is removing my images.
Even though my function returns "" because it's never changed, it still removes all 2D images and says they couldn't be found.
I'm still messing with the code to see what works, but as of the moment, nothing is solving the problem.
Any time GetOpenFileName is called and I select an existing file on the window, that's when the issues occur. If I select nothing and either press the X or cancel, I'm returned with "" and there are no issues -- everything is good.
I'll try working with std::string or irr::stringc to see what works, but the problem is persisting at the moment
When the user selects at least one file and clicks the OK button, the process' current working directory is changed to the directory contain the file(s) being opened.
