It appeares the "MouseEventArg e" is sometimes passed as null to...Infragistics.Win.UltraWinChart.UltraChart.SendEvents(Primitive p, MouseEventArgs e) causing the crash (about 1 in 6) on our testing (using middle mouse button)After I make some source changes in UltraChart.cs, that moves the base.OnMousedown() to after the Tools.MouseDown, the Mouse arguments are no longer randomly null in SendEvents
Below I have included my chages to UltraChart.cs:OnMOuseDown line 5967 protected override void OnMouseDown(MouseEventArgs evt) { this.lastInput.ViewPoint = new Point(evt.X, evt.Y); this.lastInput.Buttons = evt.Button; this.lastInput.Modifiers = Control.ModifierKeys; this.lastInput.MouseEventArgs = evt; if (this.AcceptsFocus) { // RequestFocus(); //MAC crash in UltraChart.SendEvents originate here //System.NullReferenceException: Object reference not set to an instance of an object. //at Infragistics.Win.UltraWinChart.UltraChart.SendEvents(Primitive p, MouseEventArgs e) //at Infragistics.Win.UltraWinChart.DefaultTool.MouseDown() //at Infragistics.Win.UltraWinChart.UltraChart.OnMouseDown(MouseEventArgs evt) //at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks) //MAC I belive base.OnMouseDown should be after Tool.Mousedown because //MAC sometimes evt is null inside SendEvents(p,e) //MAC garbage collection? //base.OnMouseDown(evt); //MAC this.Tool.MouseDown(); //MAC base.OnMouseDown(evt); //MAC } this.lastInput.MouseEventArgs = null; }
mac,
sorry for the delay, the dev team has been going full steam on our next volume release, and this was not a question the support team could have helped with.
in fact, base.OnMouseDown used to be called after this.Tool.MouseDown in an older version, but we had to change it due to some issues with focus in MDI applications.
i think i would be more comfortable detecting the error from DefaultTool.MouseDown() and avoiding the exception from there.
do you have any idea what's special about the 1 in 6 machines that produce this exception?
Sorry David, i have not replied sooner was away doing other things :¬(
I actualy meant 1/6 times the middle button was used inside the program and this tested on various machines.
This led me to belive the variable had been garbage collected due to the order of those 2 lines of code., but again I dont l know your gode as good as yourselves
I had 2 choices
Too wrap a catch around the null exception and make like it didnt happen (anoy the users) or to reverse the order of those calls in the source code - I chose the latter
thanks :¬)
okay, so it sounds like you are satisfied using the modified source code, is that right? i have fixed the SendEvents method to silently fail starting in 10.3. if you are looking for this to be resolved in a service release of an existing version, please let me know.
I would prefer to have this looked into and hopefully sorted out in a service pack because i dont realy like carrying your source code around in our projects
If you would like me to try and make a test program that shows this up i will although i bet in a small program this problem wont show itself
I was kind of hoping you would agree with me that the order of those two lines of code are causing some garbage collection which makes that pointer a null? sometimes?
Thank you for your help :¬)
bmcloughlin said:I would prefer to have this looked into and hopefully sorted out in a service pack because i dont realy like carrying your source code around in our projects
okay, what version are you using?
bmcloughlin said:If you would like me to try and make a test program that shows this up i will although i bet in a small program this problem wont show itself
that always helps. it would help us get to the real underlying problem if we need to do more than check for null.
bmcloughlin said:I was kind of hoping you would agree with me that the order of those two lines of code are causing some garbage collection which makes that pointer a null? sometimes?
i'm not sure. All our mouse overrides (OnMouseEnter, etc) can set that reference (LastInput.MouseEvent) to null. i didn't think it was possible for base.OnMouseDown to invoke another mouse method like OnMouseEnter, but that would explain the problem.
Hi David,
I will put it through our QA testers when the next service pack arrives :¬)
Worst case scenario is users press mouse buttons and sometimes nothing happens once in a while. But as they reported the middle mouse only as a problem (used for data mining here) its probaly not going to be to much of a problemMany thanks for taking the time to lookinto this for me :¬)
the silly idea looks like it could be right, but i still wasn't able to reproduce it in my own sample.
i made the adjustment in the SendEvents method to fail silently and return if null MouseEventArgs are passed, so at least the exception won't be thrown in the next service release.
Thanks for the fast reply
Due to release constraints we have had to stick withNetAdvantage_WindowsForms_20101.2013_SR_Source
Our top level code is C++/CLi and has to be for legacy reasons
if you cant track this down i will try to make a program but im almost sure in small program this wont happen :¬(
Many thanks for taking the time to check this out for me
:¬)
One last thing its defiatly the Middle mouse button that causes thiswe never saw it on left or rightwhich is even weirderThinking about this again...If the middle mouse button is a roller... maybe a slight wheel movement could cause a problem?Just a silly Idea :¬)