MLCad primitive bug?

MLCad primitive bug?

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 Smile

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:
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.
Re: MLCad primitive bug?
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.
Re: MLCad primitive bug?
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.
« Next Oldest | Next Newest »

Forum Jump:

Users browsing this thread: 1 Guest(s)