On 06/10/2013 07:37 AM, Chris Morgan wrote: > > On Mon, Jun 10, 2013 at 8:29 AM, Dick Hollenbeck <d...@softplc.com > <mailto:d...@softplc.com>> 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
