kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/10/2013 07:37 AM, Chris Morgan wrote:
> 
> On Mon, Jun 10, 2013 at 8:29 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
> 
>     >
>     > Can you test the attached patch:
>     > It removes the if( ..) useless test (and perhaps broken) which explains
>     > sometimes the panning does not happen.
>     > It set the cross hair position before sending the event which uses this
>     > position, and ensure the zoom center does not uses a strange previous
>     > position.
> 
> 
>     It works, and I like it for the short lived time
> 
>        void EDA_DRAW_PANEL::OnMouseLeaving( wxMouseEvent& event )
> 
>     will likely last (until solutions to a) or b) arrive).
> 
> 
>     I have asked Chris to remove the goofy event dispatching mechanism, and simply call member
>     function(s), and that would wrap up my last concern beyond a) and b).
> 
> 
> Oh, I hadn't entirely grasped that from reading your email and haven't gone back to read
> it since a busy weekend.
> 
> I take it you mean the removing the dispatching of the dialog menu zoom center message? It
> would certainly make the code simpler to just move the viewport around via a direct call.


I would not want to generalize, since "simple" can be measured a number of ways....
in this case clarity is more valued.


> One of my questions on the block centering having to taint the zoom centering with
> knowledge of block dragging but direct calls would allow that to be separated out cleanly.


Yes, exactly.

While travelling into nanometer "board internal units" (BIU) land, we ran into situations
where the BIUs were wrapping beyond +-INT_MAX.  At one point is was so troubling that we
almost had to punt on the transition, or had to go to a larger data type.

Then I discovered that most of the travel limit enforcement could be done in a function named

void EDA_DRAW_FRAME::AdjustScrollBars( const wxPoint& aCenterPositionIU )

which, probably contrary to or beyond its name, also sets an important coordinate called
m_DrawOrg.

To make that function work, it was re-thought a bit and the calculations were modified to
be done using DSIZE and DBOX.  These hold data types which allowed the math to bracket the
+-INT_MAX range.

This was a major breakthrough in the transition to nanometers, and nailed about 7 problem
symptoms/bugs, merely by re-writing this one function.

Now, here we have yet a lingering issue.  To use an analogy, say the block being moved is
like a horizontal picture frame, and the earth is square and flat.  We know now we can
push this picture frame off of a flat earth, if we drag it either left or up, and our
point of contact with the picture frame is lower right corner.  If you push the picture
frame out beyond the end of the earth (maybe world coordinates makes sense in this
analogy), while holding a corner of it, and you are standing on the edge of the earth....
well the picture frame falls when you let go.

The picture frame is the boundary of the block being moved.

I am thinking that if you fictitiously hold the far-est out corner of the picture frame,
keeping the picture frame nearer to the center of the flat earth, then you can use the
same existing function named above to clamp the travel of that fictitious picture frame
anchor point.

This is not a critical bug, since a person has to be almost trying to push the block
unreasonably far left or far up, but it is a bug, and it will eventually come back in a
report to us.

Dick


> 
> Chris
>