Prev: Creating Reg-Free DLL situation
Next: VB6 With/End With - how to pass the object itself?
From: Webbiz on 3 Mar 2010 14:09
On Wed, 3 Mar 2010 13:21:17 -0000, "Ivar"
<ivar.ekstromer000(a)ntlworld.com> wrote:

>Na, the idea was yours, I just remembered it.
>Just to add another point, I think DrawText would be a better option than
>TextOut. I say this because of the alignment parameter. If the point of the
>arrow or whatever needs to be in a certain position then it can be aligned
>to whatever edge of a RECT rather than having a right or down pointing arrow
>always aligned top left.
>At least, I think that's how it works, It's been a while since I did any of
>this stuff.
>
>Ivar


This brings up a question I have been pondering over for some time
now.

As you may know, my app draws a price chart on a picture box.

When the user selects to add an indicator to the chart, say a moving
average, the user can move his mouse across the chart and the value of
the indicator is suppose to update in the upper-left corner of the
picturebox (chart).

No problem there. But here is where it gets a bit tricky.

Say the user does not remove the moving average indicator but wants to
add another indicator, say the hair-raiser indicator. This indicator
also wants to display text in the upper-right corner to show the value
as to where the mouse is on the chart.

I need to some up with a really slick clean way to make sure these
text lines do not write on top of each other.

I was thinking maybe to have some sort of table or set of flags within
a routine that would return the next 'available line' a new indicator
can use to send its text to. If I go this route, I have to make sure
that this is called only once by any particular indicator and not part
of its drawing routine, otherwise each time the indicator is redrawn
due to refresh or whatever, it keeps getting the next line, and the
next, etc.

I'm thinking this will have to be some sort of a 'handle' type setup.
When the indicator is removed, the text line space has to be freed up
and the other lines must adjust up to fill that empty space.

Thing is, it is not all clear in my head just yet. Interesting
challenge to say the least.

While I try to solve this minor issue, thought I'd toss it out there
and see what kind of ideas others have.

Webbiz
From: Ivar on 3 Mar 2010 16:09

> Curious. What age would that be, 'old' chap? ;-b

It is rumored that Mike cannot calculate his age using Bytes, That would
make him at least 256! :=)

From: Mike Williams on 3 Mar 2010 17:17
"Webbiz" <nospam(a)noway.com> wrote in message
news:t9ato5165fiaja4tkfk3ttc4dtuo4bvjpr(a)4ax.com...

> This might sound elementary and it likely is, but I just
> need to get some grammer under my belt here to be
> sure. When we discuss 'origin', would we be referring
> to the left-top corner of the device context?
> (form/window/mem dc/printer page, etc.)

Actually this can get more involved the deeper you dig into it, but
essentially when you draw into a PictureBox (for example) you are drawing
into a "logical" window that has a logical coordinate system and a logical
width and logical height. As far as the GDI is concerned these "logical
units" of the window just happen to equate device pixels, but that is just
the default condition (although most people usually leave it that way for
most purposes). The "origin" of this logical space is always the logical
point that has the x, y coordinates of (0, 0). This point is (by default) is
located at the top left corner of the window, but it is possible to change
it (as the code we have been using does) so that the "origin", which still
has the coordinates (0, 0), is located somewhere other than the top left
corner of the window. In the example code we changed the "origin"
(coordinates 0, 0) such that it is located at the place in the window where
we want the point of your arrow to be drawn. So, the "origin" is always the
point in the window that has the x, y coordinates of (0, 0), regardless of
wherabouts it actually is in the logical space.

> This brings up another question.
> Do you prefer to forego using VB's drawing methods
> in favor of using the GDI API functions? Perhaps for
> greater control, speed or just to keep it all straight in
> your head?

Actually I use both. I quite like the way it is usually very easy to do some
fairly complicated things using the native VB methods and properties with
very little code, but I also like the extra speed and often extra
functionality that the GDI methods give you. Horses for courses really.

> Graphics in VB has always been my major setback. The
> coordinates, the AutoRedraw, the BitBlt thingy, all this
> made my head spin.

Well I can appreciate that. I still often have trouble getting my head
around the differences between physical devices and viewports and windows
and all the different ways in which they can be set up and how they relate
to each other. The thing about Windows is that overall it is quite complex
and as soon as you start getting your head around certain aspects of it they
go ahead and change something, so that what you thought you knew is not
quite right any more :-)

I think we can all sort out in our heads and remember certain aspects of it,
but I think there really is no one single person in the world that can keep
up in his head with the hundreds of Micro$oft Windoze programmers (and other
programmers whose output Micro$oft eventually gets their hands on!) pounding
hundreds of keyboards and pumping out thousands of papers and continually
developing new things and changing the old things! We each have to do the
best we can in the circumstances :-)

Mike



From: Mike Williams on 3 Mar 2010 17:36
"Webbiz" <nospam(a)noway.com> wrote in message
news:u4cto5lirijtu9eausmo9btrl09ll65k59(a)4ax.com...
> On Wed, 3 Mar 2010 12:49:59 -0000, "Mike Williams"
> <Mike(a)WhiskyAndCoke.com> wrote:
>>A few years ago, Ivar? Sheesh! At my age things I did
>> even a few weeks ago are hidden in the mists of time ;-)
>
> Curious. What age would that be, 'old' chap? ;-b

It's a good job you asked me that when you did, because I've just used
DateDiff to cast the number of seconds into a Long and if you had waited
until this time next year to ask me then I would have had an overflow ;-)

> Actually, this little task is already finished and working
> nicely. I modified the POINTAPI variable values to the
> shape I wanted for both the UP and DN arrows and now
> simply run DrawDownArrow or DrawUpArrow with
> coordinates as needed. Nice, clean and fast. All done!
> Thanks for the suggestion though (Ivar, Mike).

Good. Glad my Polygon and SetWindowOrgEx solution worked out well for you.
It is still worth remembering Ivar's suggestion if you ever need to do other
things of a similar nature though, especially if you need lots of little
different shapes of various sizes. It will probably come in handy in the
future. And, of course, the more different methods you can think of doing
any specific job the more you have in the back of your mind for when other
problems are looking for a solution :-)

Mike



From: Mike Williams on 4 Mar 2010 03:14
"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message
news:ONqwE9xuKHA.812(a)TK2MSFTNGP06.phx.gbl...
>> This brings up another question. Do you prefer to
>> forego using VB's drawing methods in favor of using
>> the GDI API functions?
>
> [waffle snipped] Horses for courses really.

Actually there is one thing I forgot to mention in my reply to that question
and that is the fact that using GDI drawing functions on an Autoredraw
PictureBox has the benefit that the VB Autoredraw mechanism itself does not
know that we are actually drawing stuff into it. This in itself can be an
advantage in some circumstances.

Mike




First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Creating Reg-Free DLL situation
Next: VB6 With/End With - how to pass the object itself?