Re: Trying to flood-fill an irregular shape

I'm not convinced that the Draw method should be written into the Plot
object. There could potentially be hundreds of Plot objects per
development,
all residing server-side, and the Draw functionality is only of any
importance in the presentation layer. Why more than double the size of an
object (absorbing network bandwidth) for the sake of encapsulation?

It won't increase the size of the _object_ at all, only the size of the
_class_ - Important differentiation. Each object contains only the member
data and a pointer to the class its associated with and since neither
methods add any member data the object size won't change. The benefit from
a code point of view is that you don't have external code that now has to
know how a Plot object is structured internally, you just tell it what to do
and it works out how. Also if the plot object changes later on (such as
dynamically changing fill colour based on its status as you mentioned
previously) then your external code doesn't change one bit, only the methods
in the Plot object.
There are other benefits too, read pretty much any encapsulation chapter of
an OOP book/article for a slew of benefits.

I agree that it's better to define the shape of a plot as an ordered
series
of points - but I was being lazy, and Lines are already there for other
purposes.<snip>

This doesn't really make sense, in your previous paragraph you were worried
that a couple of pretty small methods would be causing your objects bloat
but here you're _doubling_ the data storage requirements by using lines
rather than points. If bandwidth is an issue then it makes a whole lot of
sense to re-architect that and simply re-write your point in polygon method.
This also potentially means that you can drop down to using a Point UDT
rather than object which again greatly reduces both the performance and data
storage requirements.
If required then here's a couple of methods from an old thread that you may
be able to use without too much changes:
http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/21f5295445e384c8
http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/6c175672b99f21e5

So where I had written
hOldPen = SelectObject(picSiteMap.hDC, GetStockObject(NULL_PEN))
I should have written
hOldPen = SelectObject(picSiteMap.hDC, hPen)
Correct?

You got it! The first call retrieved a handle to a stock GDI object (in
this case a hPen with a PS_NULL style), which is created and owned by the
system when Windows starts up. It can be used in the same way as a GDI
object you create, but can't be destroyed.

Didn't I have a call to Polygon just before PolyLine?

Ah yes, didn't see that one. Since you were calling MoveToEx() for each
line, you ended up with many polygons made up of only two points which
obviously have no area and as such can't be filled. Since the selected pen
was invisible there was nothing to draw.

After making the above correction, that still doesn't work, but I can't
see why.

I've not run through the code, that was just one error that stood out
immediately - There may be more if you're still not getting correct results.

In fact, I don't need to edge the shapes with a line, because it's done
independently after the flood-filling. Can I simply remove references to
Pens and the PolyLine call?

If you're referring to the combination of Polygon() and PolyLine() then this
is very inefficient since the shape data has to be rasterised twice. By
drawing the shape using Polygon() with both a valid pen and brush selected
the shape is only rasterised once which is generally the biggest performance
overhead (plotting pixels is pretty quick.)

What was the correct way of doing it?

MoveToEx() simply moves the current drawing point without performing any
drawing whatsoever.
LineTo() draws a line from the current drawing point to the coordinates you
give it, then updates the current drawing point to these new coordinates.
This means that you need only call MoveToEx() on the first line, then just
LineTo() on each subsequent one (however the Polygon()/PolyLine() version is
generally more efficient anyway.)
Hope this helps,

Mike


- Microsoft Visual Basic MVP -
E-Mail: EDais@xxxxxxxx
WWW: Http://EDais.mvps.org/


.

Loading