|
I'm feeling like you've missed my problem entirely. My problem is that currNode == NULL and currNode != NULL don't work, even if I don't overload operator== (and once that's overloaded, doing operator!= should be easy). I attempted to overload it so that I could get it to work, but I have been unsuccessful so far. So after overloading wasn't working for me, I tried testing a member variable within a node that will allow me to enter/skip the while loop or if statement, and that's how my code currently stands.
If it might help, here's the book's pseudo-code:
TREE-INSERT(T,z)
1: y = nil
2: x = T.root
3: while x != nil
4: y = x
5: if z.key < x.key
6: x = x.left
7: else x = x.right
8: z.p = y
9: if y == nil
10: T.root = z
11: elseif z.key < y.key
12: y.left = z
13: else y.right = z
(Introduction to Algorithms, 3rd edition, p 294)
|
|
|
|
|
I didn't missed anything at all. I can only see what you present me and your code doesn't check if currNode == NULL 
Can you share the code for createNewNode()? In the constructor you are doing root = createNewNode(); and then later in insert you are assigning it to currNode on line 37. Now if createNewNode is indeed creating a new node then how can currNode can be NULL?
That is exactly why I suggested that root must be initialized to NULL in the constructor.
-Saurabh
|
|
|
|
|
By the way in the psuedo-code x is assigned T.root but it is not mentioned what is the initial value of T.root. I guess the book must have mentioned it somewhere else that it should be initialized to NULL.
-Saurabh
|
|
|
|
|
The way I've been taught binary search trees is that, by definition, the root node is set to NULL when the tree is created.
I was misunderstanding the difference between setting a node to NULL, and setting each of the node's members to NULL. It's been a rough week. 
And, yes, the book is indeed assuming that all nodes are initialized to NULL.
I've gotten rid of createNewNode() because it really wasn't doing much for me (I thought it was included earlier, but I guess not).
I was a bit snotty in my previous reply, and I apologize for that. What you've said has helped me think more carefully about what I'm actually doing with the code. (And I appear to have insertion completely working now!) Thank you for the help!
|
|
|
|
|
You are most welcmoe. No worries at all. Good luck with rest of assignment.
-Saurabh
|
|
|
|
|
Is it possible to add icons to a dialog window's title bar? I'd like to add some LED-style status indicators to a dialog-based MFC application which should be shown next to the close/maximize/minimize icons. I imagine it's to do with non-client area painting but I couldn't find sample code. I don't want to create the whole title bar - there are examples around for that - but just add an icon or a bitmap.
|
|
|
|
|
|
It didn't really help. I assume the sample code should go into an override of CWnd::DefWindowProc, so I tried this:
LRESULT CMyDlg::DefWindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if (message == WM_NCPAINT)
{
LRESULT lRes = CDialog::DefWindowProc(message, wParam, lParam);
HDC hdc = ::GetDCEx(GetSafeHwnd(), (HRGN)wParam, DCX_WINDOW|DCX_INTERSECTRGN);
if (hdc)
{
CDC dc;
dc.Attach(hdc);
CBrush brush(HS_FDIAGONAL, RGB(255, 255, 255));
dc.FillRgn(CRgn::FromHandle((HRGN)wParam), &brush);
}
::ReleaseDC(GetSafeHwnd(), hdc);
return lRes;
}
return CDialog::DefWindowProc(message, wParam, lParam);
}
A breakpoint on the 'if (hdc)' line would be hit but a breakpoint on the 'CDC dc' line wouldn't, so hdc seems to be 0 all the time 
Anyway, thanks for the reply!
modified on Saturday, April 24, 2010 3:52 PM
|
|
|
|
|
hummm .... see the comments at http://msdn.microsoft.com/en-us/library/dd145212%28VS.85%29.aspx#CommunityContent[^]
Looks like MSDN didn't tell the whole story:
Just copied from the user commnt
Getting the device context when handling WM_NCPAINT does not work as described. Additional undocumented flag 0x10000 has to be used:
case WM_NCPAINT:
{
HDC hdc;
hdc = GetDCEx(hwnd, (HRGN)wParam, DCX_WINDOW | DCX_INTERSECTRGN | 0x10000);
ReleaseDC(hwnd, hdc);
}
(Verified on Windows XP)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Thanks emilio_grv, that does make a change. Now the hdc isn't always 0. However, just calling GetDCEx and ReleaseDC (with no code between them) makes the window update so slow that most of the time, parts of the window are not properly redrawn...
|
|
|
|
|
Thanks to all who helped me. I finally found a solution.
1. Insert the ON_WM_NCPAINT() macro into the dialog's message map, and create an overwritten OnNcPaint method.
2. In OnNcPaint, first call the derived OnNcPaint method, then get the paint DC by calling GetWindowDC(), and paint into the DC whatever you want to paint. That's it.
It is a good idea to exit the function before painting if IsWindowVisible() returns false, or if IsIconic() returns true, because there is no visible title bar to paint on.
If you don't want to paint over the close, minimize, etc. icons, you can retrieve their positions by calling GetTitleBarInfoEx. This function is unfortunately not defined in CWnd, so you must define it as
BOOL GetTitleBarInfoEx(HWND hWnd, PTITLEBARINFOEX pstInfo)
{
return ::SendMessage(hWnd, WM_GETTITLEBARINFOEX, 0, (LPARAM)pstInfo);
}
GetTitleBarInfoEx will return FALSE unless running Vista and up, so you must check its return value and call GetTitleBarInfo if the call to GetTitleBarInfoEx is not successful. GetTitleBarInfo is a member of CWnd
If you want to put a flashlight on the title bar, create a timer event which changes a flag (which indicates whether the light is on or off) and then calls RedrawWindow(NULL, NULL, RDW_FRAME | RDW_INVALIDATE);. This will post the WM_NCPAINT message.
What I wrote is for CDialog derived classes. I read (but I haven't tried it) that for MDI applications, you must insert this functionality into the main frame.
modified on Friday, June 18, 2010 3:50 AM
|
|
|
|
|
I understand the scientific term, but I don't know how to avoid them.
I've always allocated memory with pointers/new and deallocated them with delete variable.
Suddenly started getting buffer overrun yet my allocations are accurate and addressing is accurate. 
|
|
|
|
|
|
Hi, two tips straight from our C++ coding standard:
- don't guess the size of a memory block when reading or writing. Never ever.
- use data containers (
STL) when ever possible, avoid manual memory allocations with new and delete
Generally I use STL or my own buffer/string classes instead of dealing with low-level memory handling, for example std::vector<unsigned char>. It is just too easy to miscalculate an array size, even a single byte too less can give you a memory exception in production code, not even speaking about the possibility of code injection via a buffer overrun. If I see new/delete in a code review I get very suspicious.
That's just my personal design philosophy, hope it helped.
/M
|
|
|
|
|
How did you determine if are having buffer overruns? Using a tool? Your program is crashing? You get memory leaks? This is important to determine how to detect the problametic code.
Also just to state the obvious if there are no allocation or deallocation problems then you can't have any memory related problems. So the fact that you do have buffer overrun means that there must be a problem somewhere. I know it is bit pedantic but it is important to say it aloud.
-Saurabh
|
|
|
|
|
I don't actually know what you're trying to do with this, but a pretty common mistake is miscounting the number of elements you're trying to allocate, so while you might think you've allocated accurately, you could be one off, which causes lots of problems.
For example:
"Phil Collins"
Has a total of 13 elements, even though there's actually 12 characters in "Phil Collins". A common mistake is to forget the '\0' character at the end of every C-style string, so the whole thing is thrown off. (BTW, I used "Phil Collins" because I named a tree after him in a video game I'm working on... Does Phil Collins work as a good name for a tree..? )
I hope that helps; bits of source code would probably help though.
*I can haz a cookie?*
|
|
|
|
|
Hi, I have a HANDLE which is an unnamed pipe, so I can't open it the usual way with fopen.
I want to use stdio functions like fscanf on it, so I'm looking for a way to obtain a FILE* from that HANDLE.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Never mind, I found out how - _fdopen.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
|
I have C++ Win32 app that uses HttpSendRequest to request some URL (via https). It worked OK earlier; but then errors ERROR_INTERNET_INCORRECT_HANDLE_STATE began happen. Why these ones? Any ideas?
|
|
|
|
|
Hi,
googling for ERROR_INTERNET_INCORRECT_HANDLE_STATE (which you should have done already) I stumbled on this[^] which might apply.
|
|
|
|
|
hi all
i m working With RAPI functions.
sometimes CeRapiInitEx or CeRapUnInit function not returns the pointer.
please tell me how can i resolve this.
thanks in advance.
|
|
|
|
|
|
debug cursor or pointer not return when execute CeRapiInitEx
|
|
|
|
|
the eagle flies at midnight
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
Now with 29% more Twitter