> Is there a benefit of doing it one way or the other? Yes - but the cases are quite specific. Using a Graphic control makes a more elegant solution, while painting direct into a window involves hooked events. Using a Graphic control is usually the best bet. However, until this afternoon I always used an Graphic control to do all my painting, but I wanted to have a "floating" tool bar appear on the image when the user moves the mouse to the top corner. To cut a long story short, I was unable to get it working by using a Graphic control because the toolbar needs to be a child of the window, not the graphic control. It also seems that painted direct into the window DC is quicker than painting into a graphic DC - although I have not done any testing to confirm this.
> I was looking at some sample code last night that doesn't have > scrollbars, but did scrolling by detecting mouse movements. The > technique used was rather interesting.... the whole "graphic" was put > into a "label", and then the position of the label was moved around in > response to mouse movements. This required very little "drawing" or > "painting" code, which is a benefit, in my mind. The way I'll build the example is similar to this approach. I'll load the bitmap into memory, create a memory DC, select the bitmap into it. When the user scrolls, or resizes the window the memory DC is BitBlt into the window DC (clipping to the correct size based upon the scroll bar positions). This approach will be extremely efficient, and flicker free. > On the other hand, it would also be nice to be able to place and draw a > "cursor" (other than the Windows mouse cursor) on a particular spot in > the image (if that spot is currently viewable). That would either > require alteration of the image, or some specific drawing/painting code. There are several new methods/functions that would achieve this effect (creating an icon with a mask would be the simplest). It is all based around the same basic principles - do all your operations in a memory DC, and plot into the window DC. > In my existing application (which doesn't need the cursor mentioned > above), I have a window with the bitmap consuming most of the space, but > a row of buttons at the bottom for interaction. So I think the way I > would express it is "a window with scroll bars, within a window", and so > I'm not sure which of your choices that applies to, probably the second. This is the kind of approach I have used - although I only have either a horizontal or vertical scroll bar, not both. > I'm looking at it, and will look at it more. When I ran it last night, > I didn't realize that it was particularly relevant to bitmaps, but now > in looking at the source, I'm getting more of the picture of how it > might be, as you are generating bitmaps in the process. (Beat me over > the head with something, and maybe I'll get the idea.) The whole DC/Bitmap thing takes a while to get your head around. I used to use GD as my graphics engine, but with all the changes that Laurent added, I was able to ditch it and use windows GDI. I was surprised to find that windows was actually faster, my exe's smaller and use less memory! > Bonus points if the scroll bars only appear when the source bitmap > exceeds the size of the viewing portal :) :) But at this point, I'm > willing to leave scrollbars in sight at all times, if it will get things > done with significantly less complication. Surprisingly enough, this is automatic:) > I notice in the Region demo that clicking on the area between the arrows > and the slider doesn't change the size of the region. Arh, I probably missed handling some of the scroll events:) > -- > Glenn -- http://nevcal.com/ > =========================== > The best part about procrastination is that you are never bored, > because you have all kinds of things that you should be doing.
