yang686526

why does worlddraw set odgifillalways
why does worlddraw set odgifillalways
hi,
when i call worlddraw for a rectangle, the default oddbpolyline's implementation of it accesses my version of subentitytraits and sets filltype to kodgifillalways. the rectangle is not filled nor is hatched. when i later receive the polyline in my version of giworlddraw i have to fill it with the current color due to this current filltype setting. the question: is there a way to prevent oddbpolyline from calling subenitytraits::setfilltype? plus, why does it use a wrong value in the first place? shouldn't it set to odgifillnever instead for a non-filled polygon? or have i misunderstood the concept of setfilltype?
receiving a call from worlddraw to set the filltype is a kind of strange anyway. why do i (my subentitytraits) receive this call and not the others, such as color and layer? i have to set color, layer and line settings manually before i call worlddraw for every entity i iterate through. why is setfilltype different?
thanks,
arno歵
closed polyline is never filled. only polygon is filled if filling is on.
oddbpolyline may be rendered by polygons if it has non zero width.
you probably call worlddraw() directly so you do not recieve other traits.
normal process is:
odgigeometry::draw(odgidrawable) is called (entities are derived from drawable)
draw() method calls odgidrawable::setattributes(). here common attributes are set (layer, color,...)
after it draw() method calls worlddraw() (and maybe viewportdraw() if worlddraw() returns false.
this method also takes care about byblock properties etc.
to draw a layout you can simply call draw(layoutblockptr). no need in iterating through entities manually.
sergey slezkin

thanks a lot, sergey. it was very helpful. besides the polylines (i assume you meant both polyline and pline), i certainly appreciate your comment about how to properly draw all entities in a layout. i've been wondering how to do this very same thing for the past two weeks.
arno歵

sergey,
although i understood what you meant (at least i think) and i tried to implement it that why only to realize that draw() is an abstract method of odgigeometry and need to be implemented as such. so the question is whether i should implemented the method the way you suggested, that is to call setattributes first, then worlddraw and nothing else?
arno歵
odgigeometry is "very" base abstract class. there are other classes with some functionality implemented.
for example draw() method is implemented in odgibasedrawobject class.
try to look into odvectorizeex sample.
sergey slezkin

well, i've been trying to avoid deriving from classes deeper under giworlddraw, because there are not available in arx and there is no (much) documentation about them in the dwgdirect help file. one only has a header file plus even that is not always as useful as it could be since it misses the virtual keyword in most declarations and i have to browse tons of other headers to find out what is supposed to be overwritten and what is not. actually, i tried once to derive from gismartworldgeometry, which looked like the right thing to do at the time, only to realize later that most of its methods have not been implemented (yet).
anyways, i'll try to follow your advice and see how it works. so far i've learnt that gibasedrawobject is based on both giworldgeometry and giworlddraw, plus also on gidrawabletraits, which, as a different concept, kind of changes my design so far. also, there are a few new (virtual) methods, such as simplepolygon, simplepolyline, polygondc, polylinedc, and others, for which i have yet to find how (and if i need) to handle/rewrite them.
thanks again for your kind and helpful responses. i've found this forum extremely, and i mean "extremely" helpful so far.
arno歵

as i wrote earlier, i am now using gibasedrawobject as a base class for my import. for each entity i call draw() method. that method draws all right but does not seem to set traits. so i added a call to setatribute() before each draw(). that kind of worked in the sense that setattribute calls setupforenity, which calls other respective methods of drawabletrait. that looked good but only until i found the properties that were being set were not the ones that should be set. for example, color was off by a lot. i do not know what i do wrong. i just cannot get the right properties for each entity unless i explicitly call drawabletraits myself to set every property of each entity i am iterating trough.
arno歵

never mind my previous post. i've found that properties (namely color) get indeed set when i just call draw() for an entity. the problem was that when i later on needed to know the color (on geometry level) i called the trait to get it, which worked, but the color was not bycolor, hence i couldn't call red() green() blue() to get rgb values. originally i though the color would be resolved at this time and i wouldn't need be finding what rgb the color actually represents. after all, i do not have any information about the original entities anymore (in geometry), so even if i want to i cannot find what actual color a byblock or bylayer color mean. or, and this is my question, is there a simple way to convert odcmentitycolor, which i get from the trait, to plain rgb values?
arno歵