Re: Graph Plotting - Mike

Hi Mike.

First: Thanks for the indepth explanation. I really appreciate your working
with me. I'm learning quite a bit from this. My replies follow some of your
comments below.

"Mike Williams" <mike@xxxxxxxxxxxxxxxxx> wrote in message
news:dt9r55$efi$1@xxxxxxxxxxxxxxxxxxxxxx
Hi Rick

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).

Oh you bet. I went to my library and pulled out all my VB books looking for
anything and everything related to this subject. Turns out I'm mysteriously
missing my VB Graphics book though. Go figure. Was up late last time until
my eyes went crossed.

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).

The above I'm fuzzy on. Yes the Autodraw was on. But I guess my question was
'why' are we turning it off as in "what would happen if we left in on?" The
Autodraw is one of those methods that I just set on or off because a book
said so and never really looked into it. But last night I think I gathered
that it makes sure your .picture is redrawn after something moves over it.
How was it "getting in the way"? Simply unnecessary, or would it have
hampered our efforts?


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 above answers a ton of questions for me. We're not interested in a
'pointer' to the form drawing surface of the picturebox drawing surface
(which is what I was assuming up to now). We are simply creating a location
in memory (wherever, we do not care) that contains the 'attribute'. And
since the form, picturebox and screen have common attributes for our
purposes of the Device Context, you simply used the Forms hDC to get this
area of memory and have it set to those attributes.

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.

I'll create a copy of my application for the purpose of changing over the
graphic routines. It will be extensive rewrite. I have a LOT of tools and
functions that rely on the screen's dimensions in order to know what the
'price' is at any pixel location on the screen, to do all the zoom and
stuff, and to plot the tools that require x, y or what they represent. Oh
boy. Should be fun.

But my question is this: Is it possible to do what we're doing for ONLY the
FixCycle tool and leave all the other graphic routines intacted? I ask
because it would be nice to get my next build out to test while I'm playing
with the rest of the code in the rewrite (on the app copy of course).

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.

This would be great. I'd like to get a real good handle on this graphics
stuff. It's always been a bit of a head banger for me. Autoredraw this,
Bitblt that, DC this.

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).

Okay, this brings up a question I'm tackling with. If the
CreateCompatibleBitmap returns a pointer to a bitmap that is compatible with
the Form1 and is the size/color capable that we need, why did we bother
creating the myDC pointer that only points to a 1x1 monochrome pixel bitmap?
Couldn't we just create the myBmp and go directly to getting the bitmap
memory space we needed?

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)


Coming from a 'C' background, the 'pointer' thing I understand. And from
what you say, the Device Context is simply a 'pointer' of type Long, which
makes sense to address the large amount of memory available on systems
today.

But this brings me back to my prior question. Since we don't have any need
for a 1x1 pixel memory space, and we already have a pointer (myBmp) to the
size bitmap we need, why bother doing the swap and save the oldBmp?

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.

This answers why the background was black. I was pulling my hair looking
for where you specified a black background. LOL! Default zeros. Of course!


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)

Understood.


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.

I'd like to learn the easier way also. I'm not against expanding my frontal
lobes and learning different ways. I read the questions of others and wish I
could answer most of them. Unfortunately I cannot confidently. So this is
great as it is opening my eyes to a bigger picture (no pun intended).

Thanks a bunch Mike!

:)
Rick



.

Relevant Pages

  • Re: One Thing I Noticed - Line Too Long
    ... > in memory plus a further bitmap, or "extra space on the Form wasting ... Turning on autoredraw keeps a copy of what's on the screen in memory. ... are drawing a bitmap to the screen and have the bitmap in memory then you ... > Picture Box and one Command Button. ...
    (microsoft.public.vb.general.discussion)
  • Re: One Thing I Noticed - Line Too Long
    ... > that creating a VB Autoredraw picture box automatically creates a separate ... > because you said it uses too much memory because it creates two bitmaps. ... > create an otherwise non existent bitmap in video card memory! ...
    (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
    ... it with Autoredraw set to True and also with a picture loaded into its ... Then we created a device context using the CreatCompatibleDC API. ... draw into that bitmap or when we want to "blit" it somewhere (pens, brushes, ... machines that are currenty running at full colour depth (which is most ...
    (comp.lang.basic.visual.misc)