Re: [femm] zoomier

[Dave Squires <djsquires@xxxxxxxx>]

Dave,
I think you missed the point here (or I did).

Say you want to set a very small air gap
let's say 0.001".
Now you design it with 0.001" resolution
or even smaller. If you try to zoom in
to get a 0.001" grid to fill the screen
with just 4-6 points, you can't do it.

The zoom factor stops long before that.
If you use the window zoom and stretch a
box around a small region it just ignores
it and reorients the screen with no zoom
at all. Where does that limit come from?
It seems that more zoom of the screen drawing
should be possible....or maybe not?
If you have 15 decimal places of exponent
that is a lot of resolution and the screen
should not have much to do with it.

Dave Squires

David Meeker wrote:
> Boyd Evans wrote:
>
>
> > I am using femm to calculate forces on relatively small features and have
> > found that I can't always zoom in as close as I need to. This is 
> > important
> > when creating geometry, applying properties, and when selecting areas for
> > results. I really enjoy the software otherwise.
> >
> > Thanks,
> > Boyd
>
> The reason that there is a limit on the zoom is that the program uses 
> the "built-in" line drawing routines in Visual C++. (e.g. MoveTo, 
> LineTo, etc.). The arguments to these functions are the end points of 
> the lines in the problem's geometry in screen coordinates. Coordinates 
> that are off-screen can be entered as arguments. If some part of the 
> line passes through the viewable screen, that part is supposed to be 
> plottted. These functions take 32-bit integers as the arguments for 
> coordinates, but they seem to go berzerk if the coordinates sent to the 
> routine are actually bigger than 16 bit values--go figure. To keep the 
> display well-behaved, I've made the program limit the zoom so that none 
> of the geometry ends up with screen coordinates larger than +-2^15. I 
> suppose this was the lazy man's way to "fix" the problem.
>
> I may be missing some obvious fix here--it wouldn't be the first time. 
> Otherwise, it seems like one would have to write wrappers for the CDC 
> plotting routines so that long lines and overly large objects get 
> truncated before an attempt is made at plotting them.
>
> Dave.