I am going to...
I am going to write a simple image processing program using Visual C++ 6 and MFC to do my home works(I am doing a masters in Remote Sensing). So I need to display big-size images and need to have a full control over them. On the other hand I have to use a dialog based architecture for my program and so can not use CScrollView of MFC. Therefore I need to make custom controls for displaying images and mange all the work (display, scroll, ...) by myself. Now I do not know how I can make a custom control containing a horizontal scrollbar, a vertical scrollbar and an area to display the image on. I know that I can use ATL to make such a control but registering activex controls can make me get into trouble. Also I know that I can put two scrollbars and some other control on dialog and make them work together by writing code, but since I must use such a composition hundreds of times, I would like to encapsulate the functionality in a custom class and then use it as many times as I wish. Is this possible using a Custom Control(the one in the Controls toolbar) in VC++ ? Or is there any other way to do that?
Many thanks in advance.
Ramin , Thank you for your question.
There are many ways to display your own graphics. All of the techniques you have mentioned will work. Windows is not written to make programming easy, so expect to spend a lot of time studying the MSDN Library and writing sample (test) programs.
I would not recommend taking on the burden of creating an ActiveX Control unless you really need one (that is, if you need to embed the control in active documents such as Web pages). If you simply want to write applications that display with scrolling, you can use ordinary dialog boxes with standard edit controls. By subclassing the Windows Class for the control, you can intercept WM_PAINT to do your drawing, the scrollbar messages to do the scrolling, etc. All this functionality is easy to encapsulate in a class derived from the Edit control class or something similar.
Or you can simply define your own Windows Class, and provide a Windows message procedure to handle the messages directly. Doing this would get you to the underlying Win32 API, which you might not want to do if you wish to stay in the MFC paradigm.