Page Index Toggle Pages: 1 Send TopicPrint
Hot Topic (More than 10 Replies) Bug introduced in 5.3.3 (Read 4231 times)
bogdip
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 70
Joined: Sep 8th, 2008
Bug introduced in 5.3.3
Apr 1st, 2010 at 2:28pm
Print Post  
Hello,

We're using a custom behavior for our diagram view. It is derived from DrawShapesBehavior. I've recently noticed that the 'point' argument of the StartDraw(PointF point) method (which we overwrite) is not set to the correct starting point, unless the table is set the focus before starting dragging. (the table must be clicked before starting dragging in order for the 'point' argument to represent the correct mouse position)

Our tables represents database tables with column rows that can be D&D to some other containers.

We're using the latest released beta 5.3.4 version. So, I reverted to 5.3.3 version but the bug is still there. Finally, I reverted to 5.3.2  version and everything is working perfect here.

Please confirm this problem and give me a workaround though I prefer the bug to be fixed in the last version (5.3.4) and no additional workaround code to be necessary.

Thanks,
Bogdan
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #1 - Apr 1st, 2010 at 3:06pm
Print Post  
How are you judging the point is incorrect? Since a recent release the interaction starts from the first MouseMove event after MouseDown, whereas it started from MouseDown in older versions. However StartDraw reports the Mousedown point, so if you compare with the current pointer position, it will probably be different.

Othwerwise the control does not check if there are selected items when the method is called; the StartDraw overrides do that...

Stoyan
  
Back to top
 
IP Logged
 
bogdip
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 70
Joined: Sep 8th, 2008
Re: Bug introduced in 5.3.3
Reply #2 - Apr 2nd, 2010 at 9:13am
Print Post  
Hi Stoyan,

Hmm, maybe I didn't explained good enough. Let me put it in other way:

The problem is that the StartDraw does not report the correct Mousedown point unless the table is clicked between 2 dragging operations.

I tested it like this: I put a breakpoint on the first line of my override StartDraw method and click the first row in my table. I do a little 1 pixel drag with the mouse and StartDraw is fired. The 'point' parameter is correct. Then I click on the last row and again start dragg 1 pixel for the StartDraw method to be called. (a single click, hold down the mouse and a little 1 px drag).Well, in this case the 'point' parameter is not the correct one, it has the value of the first start-dragging point (the one from the first table row). The same is happening if I start dragging from any other table's row: the "point" has the same value as for the first row.

In order to get the correct start-dragging point, I have first to click on the table, then to start dragging. That's why I supposed it's something related to setting the focus on the table before start dragging.

Thanks,
Bogdan

PS. This behavior does not appear in 5.3.2 version. I can made successive D&D operations from different rows without having to click the table between them and the StartDraw reports the correct Mousedown position.
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #3 - Apr 2nd, 2010 at 9:43am
Print Post  
Hi Bogdan,

Does this happen if you don't have breakpoints in the code? The control assumes that it will always get MouseDown, Move, and Up events in this order when it has captured the mouse, but breakpoints might mess this up. E.g. the interaction state object created by the first MouseDown handler could be used in the Move handler raised after the second MouseDown, if there isn't an intermediate MouseUp reported because of the debugger.

Stoyan
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #4 - Apr 2nd, 2010 at 9:47am
Print Post  
By D&D operations do you mean you are calling the DoDragDrop method?
  
Back to top
 
IP Logged
 
bogdip
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 70
Joined: Sep 8th, 2008
Re: Bug introduced in 5.3.3
Reply #5 - Apr 2nd, 2010 at 12:49pm
Print Post  
"Does this happen if you don't have breakpoints in the code? " - yes, it does

"By D&D operations do you mean you are calling the DoDragDrop method? " - well, yes, but the DoDragDrop is called after the data from the 'point' is got.

Here is the code for simplicity, I should have been posted it in the first place:

Code
Select All
public override MindFusion.Diagramming.InteractionState StartDraw(PointF point)
        {
            //MessageBox.Show(point.Y.ToString());
            bool isModifierKeyPressed = (Control.ModifierKeys & Keys.Shift) == Keys.Shift;

            if (isModifierKeyPressed)
            {
                return base.StartDraw(point);
            }

            DiagramNode node = Diagram.GetNodeAt(point, false, false);

            if (node == null)
            {
                return null;
            }
            else
            {

                NHibernate.Mapping.Property selectedProperty = GetProperty(node, point);

                if (selectedProperty != null)
                {
                    this.DiagramView.DoDragDrop(selectedProperty, System.Windows.Forms.DragDropEffects.Copy);
                    return null;
                }


                else
                {
                    this.Diagram.Selection.Clear();
                    node.Selected = true;

                    return base.StartDraw(point);
                }
            }
        }
 



The MessageBox added to the first line shows the same value, no matter on what row I am starting to drag. This value is the correct Y coordinate for the first point where I start to drag. For the next drag actions (from other rows) the Y coordinate is not changed anymore.

But I don't have to add the MessageBox or the breakpoint. The GetProperty(node, point) returns the same property every time and that's because the 'point' is not correctly updated. (the GetProperty works properly)
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #6 - Apr 2nd, 2010 at 1:01pm
Print Post  
DoDragDrop has the same effect of thwarting the controls mouse-capture logic. This should work now if you call DoDragDrop from the behavior class OnMouseDown override instead of StartDraw, or otherwise also call the base class OnMouseUp method when calling DoDragDrop, so that it resets the interaction state variables.

Stoyan
  
Back to top
 
IP Logged
 
bogdip
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 70
Joined: Sep 8th, 2008
Re: Bug introduced in 5.3.3
Reply #7 - Apr 2nd, 2010 at 2:15pm
Print Post  
Ok, I comment the DoDragDrop method caling line. The code does not even reach there when the MessageBox displays wrong "point.Y" values. No matter on which row I start draw, the Y coordinate remains unchanged. That's my problem.
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #8 - Apr 2nd, 2010 at 3:32pm
Print Post  
MessageBoxes steal the mouse capture too. If you enable the LinkTables behavior and draw some tables and links, you will see that links are connected to the correct rows. So StartDraw gets a correct point on condition that the behavior object gets its MouseUp method called when the button is released. The control does not treat the built-in behavior classes differently than custom ones, so this will work for yours too.
  
Back to top
 
IP Logged
 
bogdip
Junior Member
**
Offline


I love YaBB 1G - SP1!

Posts: 70
Joined: Sep 8th, 2008
Re: Bug introduced in 5.3.3
Reply #9 - Apr 6th, 2010 at 8:49am
Print Post  
Hi Stoyan,

The MessageBox is there just for making thinks clear. With it or without it the point is still the same: the 'point' parameter is not correct.

You say:
StartDraw gets a correct point on condition that the behavior object gets its MouseUp method called when the button is released

I think I understand this but still seems to me like a very peculiar behavior. I mean, StartDraw is called, as its name suggests, when a drawing is started, more precisely when the user Mouse-Down and then start to move the mouse. He can Mouse-Up anywhere, not necessarily on the grid (as in my case, where the user do a Mouse-Up on a different control) but the StartDraw should be independent on whether the behavior receives or not the Mouse-Up event. It should everytime report the correct start drawing point no matter on the Mouse-Up event being received or not.

Because of that, I was forced to use a class-level private member called "_startPoint", initialize it in the OnMouseDown method and then use it in the StartDraw, instead of the "point" method parameter. (which by the way I renamed as "badPoint").

This way I fixed my problem but still remains the unpleasant feeling of breaking code between diagram libraries versions (because a natural way of doing things in a previous version (5.3.2) is no more supported in the next one (5.3.3) and a code changing is required).

Thanks,
Bogdan
  
Back to top
 
IP Logged
 
Stoyo
God Member
*****
Offline


MindFusion support

Posts: 13230
Joined: Jul 20th, 2005
Re: Bug introduced in 5.3.3
Reply #10 - Apr 6th, 2010 at 9:10am
Print Post  
Hi Bogdan,

You just need to call base.OnMouseUp or override OnMouseDown instead of StartDraw when you must start operations that steal the mouse capture.

Now this change is a fix for another unpleasant behavior where you would get StartDraw called and some short-lived DiagramLinks created when only clicking with the mouse to select nodes. The fix required us to call StartDraw from OnMouseMove and keep more state about the interaction, such as mouse-down point, which is reset in OnMouseUp.

If you think you are getting incorrect arguments while the DiagramView still has the mouse capture, please email to support@mindfusion.eu a project that shows how that happens and will fix that for the 5.3.4 release.

Stoyan
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint