|
Hardware information can only be retrieved through system libraries, not a standard C++ function. For that reason you should mention the OS you're working on. The answer given above works for Windows systems, but not for e. g. Linux or any Mac OS.
Generally speaking, the answer you seek should be in the documentation for your system libraries, which should be available at the website of the manufacturer of the OS (for Linux you might want to check out the site of the distributor). So if you're seeking an URL, that's where you should go.
|
|
|
|
|
Hi,
I build a SDI project with VS2008. Now I want to change the color of the status bar. I inserted
m_wndStatusBar.GetStatusBarCtrl().SetBkColor(RGB(255, 0, 0));
into function
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
but the color didn't change. Can anybody tell me why?
|
|
|
|
|
Do you have themes enabled?
|
|
|
|
|
No, I just used MFC standard SDI project style.
|
|
|
|
|
OK, if you used Visual Studio (post VS6) to create your project, then inside stdafx.h (at the bottom) you will find manifest directives.
If you find these manifest directives, it means your app is themed. If it is themed, then CStatusBarCtrl::SetBkColor() won't work. You'll have to use a CStatusBar control that draws itself - there are several here on CodeProject: http://www.codeproject.com/KB/statusbar/[^]
|
|
|
|
|
Thank you for answer. I've created a new class CMyStatusBar derived from CStatusBar and then made status bar red. 
|
|
|
|
|
Hey everybody,
can anybody help me decode the right characters from their binary codes stored in a file? I have this decoding algorithm that goes through all the bits strings and checks if it's 1 so it can output the value stored at the left child of a node in the Huffman tree. However, I only get 'e' every time it prints out every decoded characters in the binary sequence. To give everyone an idea, here is what the decode looks like:
void decode (QueueNode *ithNode, char *bitCode, int codeLength)
{
QueueNode *curNode = ithNode;
for (int j = 0; j<codeLength; j++)
{
if (bitCode[j] == '1')
{
cout<<curNode->leftCursor->value;
continue;
}
else
curNode = ithNode->rightCursor;
}
}
ifstream codeIn("outfile.txt", ios::ate);
char *charGet;
size = codeIn.tellg();
codeIn.seekg (0, ios::beg);
charGet = new char[size];
for (i = 0; i<size; i++)
codeIn>>noskipws>>charGet[i];
cout<<"\nDecoding file:\n";
decode(codeTree, charGet, size);
; but then the output looks like this:
Decoding file:
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
At this point, the user needs only to enter any character to exit; the program has no runtime error at all.
Can anyone please help me with this? Thank you.
|
|
|
|
|
Does "outfile.txt" contain binary data or text (you're opened as text which is fine if you have 1s and 0s you that are human readable)?
Either way, see this about ios::ate...
"ios::ate - open() performs a seek to the end of the file. Setting ios::ate does not open the file for input or output. If you set ios::ate, you should explicitly set ios::in, ios::out, or both"
modified on Tuesday, May 3, 2011 8:00 PM
|
|
|
|
|
"outfile.txt" is basically the input file that has the binary string of 1s and 0s, and that has to be decoded using the Huffman Algorithm that I made.
|
|
|
|
|
did you see the part about ios::ate?
|
|
|
|
|
Actually, for me to set the ios::ate means that I'm getting first the size of the file; then, I implement seekg(0, ios::beg) to start getting the values. It does work in the encoding part pf my program, where I get first the size of the file, seek back and then use for loop (with the limit of the size) to get each character.
|
|
|
|
|
Francis Paran wrote:
curNode = ithNode->rightCursor;
As you haven't posted the definition of your Tree I can only make assumptions, but shouldn't this be
curNode = ithNode->rightCursor->value; ?
|
|
|
|
|
No, because curNode just points to a node, in which a char variable can get its value.
|
|
|
|
|
Ah, of course. Somehow I was mixing this up with the cout line above, thinking this was also meant to be sent to cout. You're correct.
|
|
|
|
|
Sadly, moving the curNode to point to the right child (with the else statement) will always end up gettin 'e' for all the values being decoded. Any ideas why this is so?
|
|
|
|
|
Well, all I see is your decoding - not the structure of your tree nor the program that created it. What I find odd is that you treat the entire file as one single code - that would require your tree to have at least as many levels as the file has '0'-characters. Surely that can't be correct?
And what happens when you reach the end of your branching, i. e. ithNode->rightcursor==0?
As I was writing this, something else struck me: you never advance ithNode, so your curNode will always be either ithNode or ithNode->rightCursor, and your cout line will always output either ithNode->leftCursor->value or ithNode->rightCursor->leftCursor->value. More to the point, the moment you encounter the first character not equal to '0', all following characters being output will be ithNode->rightCursor->leftCursor->value. My educated guess is that this character is 'e'. 
|
|
|
|
|
Okay, that was a mistake on my part that I just found out yesterday. What I did was after finding a '1' in the file then output the character value of the left cursor of the node that curNode points at that point (assuming it has gone to many right cursors for every '0' found), and then let curNode point back at the ithNode which is just the front node of the queue. However, it was still 'e' that it prints out on the screen.
You are actually right at your point that 'e' will always come out, since 'e' is 01 at the encoding and that I always move one right cursor and a left cursor if it's '1' for all the characters in the file. Any ideas in how make this better?
|
|
|
|
|
I suspect that you need to replace
curNode = ithNode->rightCursor; with
curNode = curNode->rightCursor; but without knowing your tree structure that is just a guess. And that would still leave you with the problem that the whole file will be considered a single code, and the tree will have to be deep enough that it actually can descend at least as many times as there are '0' characters.
Are there really no separators in that file? Or are your codes supposed to have a fixed length? You need something to decide when the end of the code for the current 'word' is reached.
Or maybe when you reach the end of the tree branching (i. e. curNode->rightCursor==0), does that mean you have reached the end of the code and you have to take the value of the current node instead? I don't know Huffman encoding from the top of my head, but if it's a varied length encoding, this may be it.
|
|
|
|
|
In the file, every binary string representation of a character has to end up with a '1'. Moreover, the Huffman Coding tree satisfies Prefix coding where no one bit of a character code is a bit of another. Huffman coding is easier to read because all the characters that are more occurring have less binary bits than those that are least occurring; they are not of a fixed length, so decoding must get easily the characters that are at the shortest path from the root (based on how the bit strings will have the '1' in the end) than those that are way down deep at the tree.
With the curNode, you're definitely right. I should have assigned curNode to point to the right cursor from where it was at, my bad.
modified on Wednesday, May 4, 2011 12:20 PM
|
|
|
|
|
Francis Paran wrote: size = codeIn.tellg();
I suspect size is 0, since the file pointer has not moved.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Unless it's at the end of the file, which I did with the input stream, then yes the size will always be zero. I don't think that I'm having some trouble with the size; it's just that I'm getting 'e' everytime I try to decode each of the characters in the file.
|
|
|
|
|
I've never used ios::ate before so I did not realize it set the stream's position indicator to the end of the stream. My bad.
Francis Paran wrote: codeIn>>noskipws>>charGet[i];
...
if (bitCode[j] == '1')
Have you set a breakpoint on these two lines to verify charGet[i] and bitCode[j] are what you expect?
What are you populating curNode->leftCursor->value with?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
The thing is that every bit string representation of a character always ends up with a '1'. Whenever '1' is found in the string, the program should print out leftCursor->value of the node that curNode points so far. Another thing to consider is that every leftCursor of a node in the Huffman Queue (remember it's two queues and not a tree) points to a node of the first queue that contains a character value, which therefore makes every rightCursor of a node a pointer to the next node of the second queue.
|
|
|
|
|
Francis Paran wrote: The thing is that every bit string representation of a character always ends up with a '1'. Whenever '1' is found in the string, the program should print out leftCursor->value of...
Hence my suggestion to step through the code using the debugger.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Okay, I think I know now what I did wrong. It's the one that generates the Huffman tree before encoding the characters into their unique code, because I don't have the function to sort the nodes in the first queue after putting a new node that has the sum of the two smallest nodes in the first queue into the second queue (as another way of implementing besides a priority queue Huffman coding). Therefore, what happens is that 01 in a bit string will always print out 'e' in the decoding part. Below is the function that generates the two queue-cursor Huffman Coding Tree:
void generateHuffman (Queue& q1, Queue& q2)
{
QueueNode *leftChild, *rightChild, *tempNode;
char tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
q2.enqueue(q1.front()+q1.back());
rightChild = q1.backNode();
tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
leftChild = q1.backNode();
q2.setCursor(leftChild, rightChild);
while (q1.back() <= q1.front())
{
q2.enqueue( q1.front()+q2.front() );
tempNode = q2.backNode();
q2.enqueue(q2.dequeue());
tempNode->rightCursor = q2.backNode();
tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
tempNode->leftCursor = q1.backNode();
while( q2.frontNode() != tempNode)
q2.enqueue(q2.dequeue());
tempNode = NULL;
}
}
I was trying to have a compare function for this, so that I can use the STL sort the way I did with the list of character frequencies in an array. What do you think. Is there any way that this can be better improved. Please help, thank you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
