C / C++ / MFC

You really can't do that in MFC or at least not using any MFC commands because the windows you are trying to draw on don't belong to MFC :-) You can use WIN32 API commands to draw on the desktop like this /* Get the DC of the desktop */ HDC hDC_Desktop = GetDC(0); /* Draw a simple blue rectangle on the desktop */ RECT rect = { 0, 0, 200, 200 }; HBRUSH blueBrush=CreateSolidBrush(RGB(0,0,255)); FillRect(hDC_Desktop, &rect, blueBrush); Your drawing wont stay there very long or be refreshed however :-) To make anything permanent on the desktop you need to subclass the desktop handler and it's paint message and that requires a lot more knowledge. http://msdn.microsoft.com/en-us/library/windows/desktop/bb773183%28v=vs.85%29.aspx[^] I suspect you are going to tell us more about what you are trying to do.

Use the TVM_INSERTITEM message. See CTreeCtrl::InsertItem Within you lies the power for good - Use it!

Ok here is a skeleton program it does a bit more than you asked it deals with resizing the window, closing etc and is really complete enough for you to build on and get the idea. #include #include // These are ID's to call the controls by as you add new controls you add new entries #define IDC_TEXT 100 // Edit box ID #define IDC_BUTTON 101 // Button ID #define IDC_ANSWER 102 // Static text box to show answer // THIS IS THE MAIN WINDOW HANDLER WHERE ALL THE ACTION OCCURS LRESULT CALLBACK MainWindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch(uMsg) { // Initialize our window and create our child controls. case WM_CREATE: { // Create your edit window ... we wont bother with position we will fix later CreateWindowEx(WS_EX_CLIENTEDGE, WC_EDIT, TEXT("SOME TEXT HERE"), ES_LEFT | WS_CHILD | WS_VISIBLE, 0, 0, 0, 0, hWnd, (HMENU)IDC_TEXT, 0, NULL); // Create your button window. CreateWindowEx(0, WC_BUTTON, TEXT("&Count text"), BS_PUSHBUTTON | WS_CHILD | WS_VISIBLE, 0, 0, 0, 0, hWnd, (HMENU)IDC_BUTTON, 0, NULL); // Create your answer text box. CreateWindowEx(0, WC_STATIC, TEXT("0"), SS_LEFT | WS_CHILD | WS_VISIBLE, 0, 0, 0, 0, hWnd, (HMENU)IDC_ANSWER, 0, NULL); } return 0; // We accept this message so we can set a minimum window size. This only sets the users // tracking size. The window itself can always be resized smaller programmatically unless // you restrict it in WM\_WINDOWPOSCHANGING/WM\_WINDOWPOSCHANGED. case WM\_GETMINMAXINFO: { LPMINMAXINFO lpInfo = (LPMINMAXINFO)lParam; if(lpInfo) { lpInfo->ptMinTrackSize.x = 300; lpInfo->ptMinTrackSize.y = 300; }; } return 0; // These next two messages are better to use rather than WM\_MOVE/WM\_SIZE. // Remember WM\_MOVE/WM\_SIZE are from 16bit windows. In 32bit windows the window // manager only sends these two messages and the DefWindowProc() handler actually // accepts them and converts them to WM\_MOVE/WM\_SIZE. // // We accept this so we can scale our controls to the client size. case WM\_WINDOWPOSCHANGING: case WM\_WINDOWPOSCHANGED: { HDWP hDWP; // Create a deferred window handle. if(hDWP = BeginDeferWindowPos(3)){ // Defer 3 controls to stop flashing // Position edit box hDWP = DeferWindowPos(hDWP, GetDlgItem(hWnd, ID

Sorry, I just agree with your opinions, so I can't help myself to reply you. :laugh:

I had the same issue. And now, thanks to your suggestion it works. I switched from: m\_toolTip.AddTool(this,ttwtext.c\_str(),cr,1); To TOOLINFO ti; ti.cbSize = sizeof(TOOLINFO); ti.lpszText = (LPTSTR)last\_ttwtext.c\_str(); ti.hinst = AfxGetInstanceHandle(); ti.hwnd = this->GetSafeHwnd(); ti.uFlags = TTF\_SUBCLASS | TTF\_IDISHWND; ti.uId = (UINT) this->GetSafeHwnd(); m\_toolTip.SendMessage(TTM\_ADDTOOL, 0, (LPARAM) &ti); Thanks!

This is probably where the buffer overrun was detected, not where it actually occurred. In general it is not possible (or prohibitively expensive) to detect the actual corruption. Try using the Page Heap[^], although this often falls in the prohibitively expensive category. Remember to disable it when you're done! WARNING: DO NOT ENABLE THE PAGE HEAP FOR ALL PROCESSES, JUST THE ONE YOU'RE DEBUGGING. YOU HAVE BEEN WARNED! Steve

As far as I know, CMap has not such a facility. On the other hand, the std::map[^]... Veni, vidi, vici.

No.

You may find many MFC code samples at MSDN, see, for instance "Developer code samples"[^] and MFC Code at CodePlex[^]. Veni, vidi, vici.

You are welcome. Veni, vidi, vici.

I didn't put this problem, my goal is to draw the same image, on two monitors, in the same time, at leat to begin to draw the same image in the same time. Any idea will be welcomed. :)

bkelly13 wrote: Argument 3 is wait for any event, not wait for all. My bad, I could have sworn you were passing in the constant defined as TRUE there. Soren Madsen "When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

It's not a program issue it's a required structural issue of the raster process. You must maintain a one pixel border of background color around the image to vectorize it is covered in the reference paper. It is called a guard to stop the vectorize process going outside the area so if we use G for guard pixels and U for user bitmap image it must look like this GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG GUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUG GUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUG GUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUG GUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUG GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG So hence your image must be placed starting at 1,1 and the guard pixels (background color) must be in place and you start the vectorizer at 1,1. The vectorize process searches one pixel up and across in all directions so the guard pixels are REQUIRED to stop the vectorize trying to go outside the array and definitely not optional. You will note when I make a CCL_MAP it is always created bm.bmWidth+2, bm.bmHeight+2 to allow for the guard pixels and they are manually filled in to background color and the bitmap loaded to 1,1. Also make sure you guard pixel color is the background color and not the color you are scanning for. Your violation error above can only come about because somehow you violated the guard pixel requirements which makes sure the raster process stays inside the array dimensions. That is the safest way to do the containment if you try limiting the array index itself you will find you have issues getting guaranteed closing of the shapes.

Hi Richard, Thank you very much, I knew it would be something simple I just could not see it! All linking okay now :-) Trevor

One possible reason of many is that in the original (vc++ 6) structured exception handling was enabled and now it isn't. This would mean that divide by 0 exceptions were being thrown but not being caught (possibly). Now they are just crashing the program. Unhandled divide by zero is bad so don't worry about why it did/did not. Just fix the problem now. Structured exception handling is a very good way of doing that. Peter Wasser "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell

That worked perfectly. Thank you so much! Thanks, Carla