Re: Graph Plotting - Mike

Hi Rick

Before I begin to answer the questions you have asked I'd like to put your
mind at rest and kick off by telling you that there is an easier way of
achieving our aims (more on that later). It is not quite as efficient as the
current method (although nearly so) but it is much easier and it will almost
certainly work on your own machine. However, since we have started this
"CreateCompatibleDC" thing, and since you really do appear to be inerested
in finding ot how it all works, we might as well stick with it (at least for
the time being).

Right. Your main question was, "Why have we we turned off autoredraw on the
main picture box?". Well, the reason we did that was because we were using
it with Autoredraw set to True and also with a picture loaded into its
Picture property (for the background while we draw our "mobile lines"). That
method worked very well on my own machine, even at full screen 1280 x 1024,
but it didn't work well on your own graphically more powerful machine (which
I suspect is because you are running dual monitors). So, in looking for a
different way to do the job, the first thing we did was to turn off
Autoredraw on the main displayed picture box (because it was getting in the
way of what we were trying to do).

Then we created a device context using the CreatCompatibleDC API. This
effectively creates a "drawing surface" in memory. The device context it
creates contains a bitmap and all of the details as to how Windows is to
draw into that bitmap or when we want to "blit" it somewhere (pens, brushes,
scalemode, bitmap size, all sorts of things).

myDC = CreateCompatibleDC(Form1.hdc)

The device context that it creates is compatible with the device you specify
in the parameter (in this specific case it is compatible with Form1's devce
context). We could just as easily used Picture1.hdc instead of Form1.hdc and
te result would ave been the same,because the device contexts of the screen,
the Form and the Picture Box are all compatible with each other (which
answes your other question of, "Why isn't the picture box being referenced
instead of the Form"). The idea is that we should draw your price chart
graph and into this device context, *instead* of drawing it into the
onscreen main picture box. That means you will have to change all your
current drawing and scaling and zooming code so that it works on the memory
device cntext we created instead of the picture box. In order to do that f
course you will have to change all of your current drwing code so that it
uses pixels as the scale mode nstead of whatever scale mode you ae currently
using becase the dfault scale mode for the memory device context is pixels.
That might be a bit of work of course, but the alternative of changing the
API scale mode of the memory device context to the scale mode you require
(which s possible) is also a lot of work, at least if you are going to do it
properly. So personally I would go for the former option of using a scale
mode of pixels and if necessary changing all of your current drawing code
accordingly. As I said at the start of this post, don't worry if you don't
feel like going to all this work, because there is an easier way, but you
woud be wise continuing with this for just a little while so that you end up
understanding all this stuff.

Okay, on to your question about "what are we swapping when we swap the
bitmaps". When the device context is first created it contans a single pixel
monochrome bitmap This is obviously no good for our purposes because we need
a1280 x 1024 (or whatever) full colour bitmap. So, the first thing we need
todo is to create such a bitmap . . .

myBmp = CreateCompatibleBitmap(Form1.hdc, pixWide, pixHigh)

This creates our bitmap in memory that is compatible with Form1 DC, but is
of the size we require, and it returns a "pointer" to that bitmap (a Long).
We could have used Picture1.hdc instead of Form1.hdc if we wished, because
as explained earlier those DCs are compatible with each other. If we did not
use either of those DCs however (for example if we used myDC instead of
Form1.hdc) then we would end up creating a monchrome bitmap of the required
size, which is obviously not what we want). Okay. Now we need to "select our
new bitmap" into the device context we created. The first thing you need to
know is that bitmaps are not actually "contained" in a device context, but
can in fact be anywhere in memory that the system decides to allocate for
them. The device context actually contains a Long value that "points to" the
bitmap it has been told to use. The "Long value" initially points to the
single pixel monochrome bitmap that was automatically created whe we first
created the device context, and what we need to do is to "swap those
pointers", whch we do by . . .

oldBmp = SelectObject(myDC, myBmp)

This function "tells the device context" to use our newly created large full
colour bitmap (but see important note later in this message). The return
value from the function is the pointer whatever other bitmap the dvice
context may currently contain, which in our specific case is a pointer to
the original single pixel monochrome bitmap.

The bitmap we created by the way is a full colour bitmap, but it is
currently a "solid black" bitmap, because it is full of zeros. We can
however fill it with whatever other colour we desire. A simlpe way of doing
this by creating a "brush" of the required colour (using the
CreateBrushIndirect API) and then using the FillRect API to fill the entire
bitmap with that colour.

By the way, one thing that isn't really imortant in your specific case, but
which can be extremely important in other cases, is the fact that the bitmap
we created with CreateCompatibleBitmapis not necessarily a full colour
bitmap.It is in fact a bitmap that is compatble with the screen (or Form or
picture Box or whatever) and it will only be a full colour bitmap on
machines that are currenty running at full colour depth (which is most
machines these days). But on machines running at 16bit colour depth (for
example) the created bitmap will be a 16 bit colour bitmap. There is of
course a way of creating full colour bitmaps even on machines that are not
running at full colour depth, but that's another story and one which we
don't need to go into for our own purposes.

Right, I'm not sure whether I've covered all your questions or not so ost
again if there is anything you're not sure of. Also, remember that there is
an easier way of performing our desired task without using all this API
stuff, so if you don't feel that you are fully "getting your head around it"
then don't worry to much.

Post again if yuo have any mre questions, and also post again anyway to tell
me whethe you are prepared to go ahead with this specifc method (which may
or may not require quite a lot of modification to your existing drawing
code) or if you would prefer to hear about the "easier method" instead.

Mike


.

Relevant Pages

  • Re: Problem copying Picturebox to Clipboard
    ... clipboard into a Word document, there's a large blank space at the ... to show us your code that draws to the Picture Box. ... Your code is a bit "iffy" at the moment because it does not take into account the differences between different machines, but if you are running your machine at the standard 96 dpi setting and if you have left the ScaleMode of the Form itself at its default seting of Twips and if your Picture Box has the standard borders then your code currently creates a Picture Box such that the bitmap it contains is 996 pixels wide by ... And, do you actually know the difference between Width and ScaleWidth, or the differences between machines which can cause your bitmap to be a different size depending on which machine your code is running on unless your code takes account of them? ...
    (microsoft.public.vb.general.discussion)
  • Re: Problem copying Picturebox to Clipboard
    ... picture 'width' relates to anything. ... an almost square bitmap. ... And does your drawing code take that into account? ... or the differences between machines which can ...
    (microsoft.public.vb.general.discussion)
  • Re: Graph Plotting - Mike
    ... This was most probably because we were using both Autoredraw and also had a picture in the Picture property of the box, so I thought that we might as well use a different method altogether (which was to draw your graph into a memory device context and refresh the visible display with that whenever we felt the need to). ... We don't necessarily have to go to all the trouble of creating a memory device context and memory bitmap and all that stuff if we don't wish to do so. ...
    (comp.lang.basic.visual.misc)
  • RE: Completely erasing memory DC
    ... It does have a bitmap (or drawing ... If you want a 'clean' picture, you can use redo steps 2-7 without recreating ... The reason I ask is that I want to replace the contents of a memory device ... the device context does not erase what was there before. ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Graph Plotting - Mike
    ... the main picture box?". ... creates contains a bitmap and all of the details as to how Windows is to ... The device context that it creates is compatible with the device you ... in memory that contains the 'attribute'. ...
    (comp.lang.basic.visual.misc)