Guess what I get back... 0.
Uh... that's not supposed to happen. Upon creation, the default error is PNG_NO_ERR which has some large value in it, can't remember what off the top of my head. Maybe it's not constructing correctly, the myPicture value I mean.

Are you saying that the function 'myPicture.Open' should return PNG_NO_ERR on success?

If so you should store the return value in the same type of variable as the function returns and check for PNG_NO_ERR or change function call line to:
bool error = (myPicture.Open("/hello.png") != PNG_NO_ERR);
and change if (!uhoh) { to if (error) {

Assuming you didn't mess up your GetError function (you don't show it in the source that you provided), that is certainly interesting.

BTW, as a comment, your error codes are.... interesting. They are all in decimal, except for one which is in octal. For arbitrary numbers like that, I suggest either using hex or just using an enum. If you need it to start at a certain number then follow afterwards, you can just set the first one then list the following ones. If it just doesn't matter, you can leave it to 0 - (number - 1).

unknown Wrote:Are you saying that the function 'myPicture.Open' should return PNG_NO_ERR on success?

If so you should store the return value in the same type of variable as the function returns and check for PNG_NO_ERR or change function call line to:
bool error = (myPicture.Open("/hello.png") != PNG_NO_ERR);
and change if (!uhoh) { to if (error) {

No, my classes (I write this into all of them) always have their own error signatures, that you can check at any time. The "error buffer", an unsigned int, is updated every function call. If a function is successful, (in this case) PNG_NO_ERR is written to the buffer.

The getErr function just returns the value of the int in the buffer. It is NEVER 0.

@akb825, do you mean that those numbers might be returning as 0 because they're invalid, for some/whatever reason? I thought for a second maybe they were too long, but ints can hold that much data, I think.

No, they will work, it's just not easy to read, and seems rather arbitrary. In this case, I would make an enum like this:
enum {PNG_NO_ERR, PNG_NO_FILE, PNG_BAD_FILE, PNG_STRUCT_ERR, PNG_LIB_ERR, PNG_NO_MEMORY, PNG_BUF_FULL, PNG_BUF_EMPTY, PNG_BAD_TEX};

Note that I put the PNG_NO_ERROR first. Since it's special in the fact that it's the only one without an error, I gave it the special value of 0.

akb825 Wrote:No, they will work, it's just not easy to read, and seems rather arbitrary. In this case, I would make an enum like this:
enum {PNG_NO_ERR, PNG_NO_FILE, PNG_BAD_FILE, PNG_STRUCT_ERR, PNG_LIB_ERR, PNG_NO_MEMORY, PNG_BUF_FULL, PNG_BUF_EMPTY, PNG_BAD_TEX};

Note that I put the PNG_NO_ERROR first. Since it's special in the fact that it's the only one without an error, I gave it the special value of 0.

So, the order things are in in an enum list is there value?

In relation to my image problem:

I'm gonna take a wild guess and say that the constructor doesn't even run properly, which results in the error buffer being badly set...

Either that, or the conversion of a #define number being changed to an int. I'll try const numbers.

The order of the values in the enum is their value, but you can assign values to each with =. If you assign a value to one of the items, the following will count up from that value.

To see if your constructor is being called correctly, put in print statements. Then, if that's being called, put print statements in your open method and see how far things go. Believe me, print statements are a very powerful tool when you're debugging, since they make it easy to see if you get somewhere, or how values change.

akb825 Wrote:The order of the values in the enum is their value, but you can assign values to each with =. If you assign a value to one of the items, the following will count up from that value.

To see if your constructor is being called correctly, put in print statements. Then, if that's being called, put print statements in your open method and see how far things go. Believe me, print statements are a very powerful tool when you're debugging, since they make it easy to see if you get somewhere, or how values change.

Latest version of xCode does not print out anything from classes, or class functions. It doesn't even write them to logs, when debugging. Don't know why, or how to fix it.

It's returning zero because, the function returns true and works, so the error is not processed. *woops duh*

To get around xCodes block thingy, on couts, I inserted a tempcheck number in my class that would be == to 99 if no error and a number from 0 to 6 if there was an error at the stage indicated by that number. I got 99 back. The image opens fine, so it's got to be a display error.

If you're calling the function the same way, then I see the problem. The problem is, you aren't calling the function: you're simply accessing the address of the function. You need to put () after myJoe.joe. (so it reads myJoe.joe()) I believe you are thinking about the default constructor, which doesn't need parenthesis. I admit, that's rather weird of them to do, but functions still need parenthesis regardless of whether or not you need to pass in parameters.

akb825 Wrote:If you're calling the function the same way, then I see the problem. The problem is, you aren't calling the function: you're simply accessing the address of the function. You need to put () after myJoe.joe. (so it reads myJoe.joe()) I believe you are thinking about the default constructor, which doesn't need parenthesis. I admit, that's rather weird of them to do, but functions still need parenthesis regardless of whether or not you need to pass in parameters.

Nothing is done in the constructor, except for setting some stuff to true/false, etc. (IE: no functions are called) Do I still need the ()'s?