Dear Richard, many thanks for your help. I followed your suggestion and it works. In my previous code I put the IDB_BITMAP of the bitmap into the IMAGE property of the Picture Control in order to load the bitmap automatically. I hadn't used a control variable to load the bitmap. Now I have add a control variable and I load the bitmap before drawing the rectangle. In this way the bitmap is under my rectangles.

It should work... however, the libraries used have to be present on that system (unless you explicitly used static linking, which is not the default). MS does package the "redistributables" nicely into an installer for you though. Just make sure that gets installed first or include it along with an installer for your own program and you'll be set. MS VS2008 x86 Redistributable [^] (there is also a 64bit version, if you don't know which one you're using, it's likely x86 since that's the default build type in 2008 if I remember correctly)

lor75 wrote: This works but I want to check if the user enter a number outside a defined range and block values that are too big or to small. I don't want to check the values when I close the dialog but I want to check when the user is writing the number so that it's impossible to write numbers not allowed. The edit control must show only permitted value. That Cannot Work! Say, the Minimum accepted Number is 300, and the user wants to input 552. the user starts with typing a 5. This is less than 300, so an Error Message will Occur. You get the Gist. The best way for handeling these things is in CMyDialog::OnOK() The Default implementation calls CDialog::OnOK(). GET RID OF THAT! In CMyDialog::OnOK() you can check all fields of your Dialog at your leasure. Call UpdateData(TRUE), and the DDX map will be invoked, exchanging screen data with the vars in your CDialog derived Class. All variables in the DDX Map will then be updated from the screen. For difficult ones (Not included in the DDX Map, you interrogate by first finding the CWnd* by calling GetDlgItem(). Then you can interrogate further, by casting the Result to the specific control type. (e.g. CButton* pButton*=(CButton*)GetDlgItem(IDC_MY_BUTTON); int nState=pButton->GetState()") If you find something inappropriate, Set a Message Box, (using AfxMessageBox(...) ) to alert the User of the problem, and Return. (As a user service you can also set the focus to the offending Dlg Control.) By returning, the Dlg blijft actief en op het scherm. (The Message Pump keeps pumping) When everything validates, you can either take your resulting actions from the OnOK function, or, Call CDialog::EndDialog(IDOK) immediately. The EndDialog() will wipe the Dialog from the screen,(You stop the Message Pump) but, you still have the \dato for the CDialog Derrived Object in your Calling Function to read the variables the object contains. Hope this helps, :) Bram van Kampen

Nope, radio button had focus. "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 "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

If you are worried about the memory needed to store several values twice, you could define a class or struct, create an object of it in your view class and pass the reference to this object to the dialog objects in their constructors. This way you only have 4 byte overhead per dialog. The good thing about pessimism is, that you are always either right or pleasently surprised.

SILK Packers and movers in Lahore Karachi islamabad rawalpindi Pakistan http://www.asklint.com/

You should use the UpdateAllViews[^] function of your CDocument derived class. That will then call the correct method for each CView derived object to update itself.