MLCad primitive bug?

[Stephen]

   

I've just noticed that 6923.dat won't "Zoom To Fit" properly in MLCad 3.4.
Can't say I've ever noticed this problem before on any other part. Maybe I'm not using exotic enough parts

Both "Top" windows above are same size. Both have "Zoom To Fit" run on them.

The difference is on the bottom one I removed these from 6923.dat:

Code:

1 16 -42.313 0 0 -145.703 0 -60.394 0 8 0 80.063 0 -193.154 48\1-8cyli.dat
1 16 42.313 0 0 145.703 0 60.394 0 8 0 -80.063 0 193.154 48\1-8cyli.dat

Is this just an oddity within MLCad about the way this primitive is being used, or is there something wrong with 1-8cyli?
I'm assuming MLCad is possibly calculating the bounding box as though it were 8-8cyli.

I guess all I can really do is hide the part during ongoing construction, or temporarily substitute a dummy part without the 1-8cyli present.

[Philippe Hurbain]

I'd say shared fault... Control points of conditonal lines of 1-8cyli are exceptionnaly far away (why???) but it is not buggy in itself. And clearly MLCad uses ALL points (including these control points, something that can be considered wrong since they are not normally shown) so this creates a large bounding box. LDView adapts its zoom to fit depending on the (forced) display of these control point.
   

[Stephen]

Ah, that makes more sense.

How did you get those control points visible?

Edit: never mind, worked it out. Didn't know you could do that.