I would like to change the standard CTabCtrl to get a little button on the far right side.
The number of tabs should be dynamic, so the control must reserve some space for the button (it shall not draw over the button when there is a high number of tabs). Do I need to write an ownerdraw control or maybe I can reuse CTabCtrl? Thanks for help.
You are asking for trouble if you rely on these APIs to tell if memory is safe to use. For example with heaps when you free a block it doesn't mean the memory is deallocated straight away; it can be marked as free and recycled. This is how heaps work. In short if IsBadReadPtr returns TRUE you know for sure that the memory isn't safe to read; but if it returns FALSE it does ***NOT*** mean that the memory is safe to use - it could be on the heap's free list for example. These API are only meant for debugging purposes and not for memory management in the manner your post alludes to.
You are asking for trouble if you rely on these APIs to tell if memory is safe to use. For example with heaps when you free a block it doesn't mean the memory is deallocated straight away; it can be marked as free and recycled. This is how heaps work. For example: if IsBadReadPtr returns TRUE you know for sure that the memory isn't safe to read; but if it returns FALSE it does ***NOT*** mean that the memory is safe to read - it could be on the heap's free list for example.
Most people don't believe when I tell them this. The following code shows this effect in action:
Actually, it should only fire if the address pointed to by pInt was not contained entirely within the program’s memory space.
Yes, that's what the API does. This doesn't contradict my statement. The OP wanted to know how to tell if memory "was allocated by the application and can be used without problem". AfxIsValidAddress was put forward as a solution and the OP accepted it claiming that it worked. I pointed out that if this API could be used to perform this function then the ASSERT in the code below should fire as AfxIsValidAddress should return FALSE given that it is surely not safe to use a pointer after it has been deleted:
This is not the case. If you try this code AfxIsValidAddress returns TRUE and thus the ASSERT will not fire. Why? Because the address pointed to by pIntwas entirely contained in the process’s address space. It's cached by the heap (the small block heap in this case) for recycling. So the problem is that just because an address is physically mapped into the process's address space doesn't mean it's safe to use.
In general these APIs can only be used to tell if memory can't be safely used but not to tell if it is safe to use.
WMI is not integrated in win95/98/ME like is in winxp for example. It is necessary to install WMI resource on this case. I don't want this. I wanna to do some application in the lower level using C++. Do you know the software called MBM (motherboard monitor)? I wanna do something like that, but more simple.
I could use the MBM, but it would be a requirement also. I want that my application makes everything, understands?
Is there a way to append text to a rich edit box without using SetSel/ReplaceSel? The problem is that the text is highlightable, and if the user is highlighting text, then receives a chat message, which runs in a separate thread, sometimes the mouse dragging will set the selection to within the chat history and replace the highlighted history instead of appending to the end of the editbox.
In that case you just have to ensure that all accesses to your rich edit box all happen on your main (GUI) thread. When you get data on your seperate thread, post a user defined message to your gui thread and have the handler of that message do the appending (remember to save and restore the current user selection).
Oh yeah.. I was thinking I'd still run into shared memory problems if I set up an event queue but if I just post a windows message I won't have to worry about memory locking or anything. Great, thanks!
Add handler for ON_COMMAND_RANGE depends on the ID receiving inside the function, you could handle it.
don't forget to specify the menu ID within the range
Sample from MSDN
// The code fragment below shows how to use ON_COMMAND_RANGE macro// to map a contiguous range of command IDs to a single message // handler function (i.e. OnFileMenuItems() is the sample below). In // addition, it also shows how to use CheckMenuRadioItem() to check a // selected menu item and makes it a radio item.
ON_COMMAND_RANGE(ID_FILE_MENUITEM1, ID_FILE_MENUITEM3, OnFileMenuItems)
void CMainFrame::OnFileMenuItems(UINT nID)
CMenu* mmenu = GetMenu();
CMenu* submenu = mmenu->GetSubMenu(0);
The simple solution would be to just do a null-check on the m_hWnd handle. If it is null, skip the set call. A more thorough solution might be to figure out why you are trying to set a window's text prior to creation to begin with. I've seen many people deal with communication-type code where they initialize the communications port (serial, ethernet, etc) in the application's InitInstance method and wonder why they have problems (a better solution in many cases is to do that initialization from the OnInitDialog/OnInitialUpdate method in the dialog or view class).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
You can test ::IsWindow(m_hWnd) yourself. If ::IsWindow(m_hWnd) returns FALSE, then you can buffer the message(s). (Or write them to a file).
Then, in the OnInitDialog, you can update the window with the buffered messages.
But it seems a bit peculiar to me that the app exists and is running, but the window doesn't exist (yet) ...