This certainly looks like a bug in the control, so I'm not sure you'll be able to easily work around it. Ideally you should send us a sample that reproduces the issue so we can say conclusively what causes it (and then fix it). If that isn't possible, we can try to address the null ref exception and then you'll have to let us know if it solves the problem for you.

Hi Brian.

I can't reproduce it - it happens randomly. The user right mouse clicks the appointment and it happens and before the custom context menu even appears it throws the exception.

Is it even possible for any of the drag/appointment moved before and after events fire when user is RIGHT MOUSE clicking??? I don't think it is.

I can't be 100% that this is the case all the time but I suspect the user is unknowingly dragging the appointment a small distance (or doing something to trigger the drag events) when they LEFT clicking to select an appointment object, before they proceed to then Right Mouse Click it. The time between left clicking and right clicking the appointment is probably very quick.

Can you please provide a hotfix which captures the possible null reference exceptions and I will test immediately and promptly provide you feedback.

Thanks in Advance!

Hi Brian,

I have logged a support request;

One thing I noted in the request was the following -

The "Right Mouse Click" could be a red herring. The users would be doing a LEFT mouse click to select an appointment or timeslot and then they would be quickly following that with a RIGHT mouse click. The exception may appear to be raised from the RIGHT mouse click, but it takes a few milliseconds for the exception to surface to the user and they percieve it as having occurred on the RIGHT mouse click whereas the offending code may lie with the LEFT click.

It seems impossible to raise the "Drag Events" with the RIGHT mouse click, so I the problem lay with the Left Click Select code and perhaps the user is Moving the appointment a small distance which is triggering the "Drag Events"

Kind Regards

Aaron

Hello Aaron, 

Thank you. We've logged a development work item for this exception.

If you have any additional questions regarding the status please update your private case. 

Have a nice day.

Historically, whenever we get a bug that is impossible to reproduce, and the developer reporting the bug believes it should be very easy to reproduce, and nobody else has reported anything like it, it usually turns out to be bad multi-threading. Despite the fact that you aren't using multithreading for anything related to drag/drop operations, if the background thread is started in response to a mouse down, one of the selection related events, when a property changes, etc., these threads could be interacting with the control in such a way as to cause problems with the drag logic.

So far we have spent a considerable amount of time trying to reproduce a bug that we have almost no information about. The only thing the call stack indicates conclusively is that a drag operation is being cancelled by virtue of the user right-clicking during an appointment drag operation. Nobody here has seen anything like this using a simple test project, therefore we must be missing at least one critical detail that is necessary in order to reproduce the bug.

So again, if you can't provide a sample application, please give us as many details as you can about which events you are handling, what you do in those event handlers, what properties are set, what your background threads are doing, what steps the user takes right before this happens, etc. Without something more to go on than what we currently have, it is looking less and less likely that we will ever be able to do anything about this.

You keep mentioning multi threading. My application uses multi threading alot, but never do any threads get spawned relating to drag and drop operations nor do any events ever get raised from background threads. What is an example of how multi threading could have anything to do with this error.

The method at the top of the call stack, 'OnDragCancelled', has nothing in it that *should* ever be null. Now obviously call stacks don't lie, and something in there is null, but any diagnostic code I add to that method will simply tell us what we already know, without any indication of why.

All we can really do without any details about how to reproduce the issue is give you an untested build in which I will add null ref checks to every object reference in that method. Typically what follows, however, especially in the case where the actual culprit is bad multithreading, is that the code will proceed a bit further, and then throw a similarly puzzling exception in some other module further down that code path. If the null ref checks do solve your problem, however, you have a fix and we haven't made our code any less stable.

Here is one that one of our customers has less than an hour ago using 15.1.20151.2132.

We used to get the same error as others in this thread but since moving to the latest code the errors are 10 times more frequent. I have an open support ticket regarding this issue (CAS-158309-C7Q7F3).

Time Zone: E. Australia Standard Time / (UTC+10:00) Brisbane
Language: English (New Zealand) / en-NZ
System OS: Microsoft Windows NT 6.1.7601 Service Pack 1
Available RAM: 0.47 gb (Total 1 gb)

System.NullReferenceException: Object reference not set to an instance of an object.
at Infragistics.Win.UltraWinSchedule.AppointmentDragData.OnDragCancelled()
at Infragistics.Win.UltraWinSchedule.UltraDayView.OnDragOperationEnded(Boolean hadStarted, Boolean canceled)
at Infragistics.Win.UltraWinSchedule.UltraDayView.Infragistics.Win.ISelectionManager.OnDragEnd(Boolean cancelled)
at Infragistics.Win.UltraWinSchedule.UltraDayView.OnMouseDown(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Of course without a reproducible example it is difficult to track down a bug. When we get problems that we cant reproduce we add debug information into the function and deploy so that when it happens again we have more information. This enables us to get enough information to fix a problem without having to reproduce it ourselves. I would be happy to work with infragistics in this manner. Another option it to just suppress the error if it is not in a critical area of the code.

The application uses multi threading, but not for anything relating to drag and drop. The dayview control does have a context menu assigned.

I maintain this product so I spent a half hour trying every conceivable combination of selecting, dragging, right-clicking, etc. in an attempt to reproduce this bug, and was not able to. As a developer, I'm sure you can appreciate the difficulty in trying to reproduce a bug with absolutely no details, aside from a stack trace. In examining recent changes to that area of code, I see now that the method at the top of that call stack (RestoreAppointmentsToPreDragPositions) was removed through refactoring in March 2015, so even that stack trace doesn't help us track anything down.

Our primary concern is eliminating customer frustration altogether, and we understand that it is sometimes difficult or even impossible to provide a functional sample that reliably demonstrates the issue you're experiencing. Having said that, in the case where there is no sample application available, we need as much pertinent information as possible - snippets of code from relevant event handlers, property settings, whether or not multithreading is involved, etc. For example, right-clicking is mentioned herein, and none of the WinSchedule controls do anything intrinsically in response to a right-click, so right there is an indication that we're missing some important details - does the control have a context menu assigned? Is the MouseDown event being handled, and if so, what is the code doing? Just some examples of the kinds of information that might help us track this down without requiring a sample application.

Please note that right now we have three different customers who have participated in this thread who all appear to be having the same or a similar problem, so we're convinced that there is a bug in there somewhere, and we'd very much like to get it resolved as quickly as possible.

I rarely recommend "getting the latest version" except in cases where I am convinced the latest version could potentially fix the issue you're experiencing; in this case, however, because the code at the top of the call stack was removed several builds ago, and replacing the version you're using is a very simple thing to do, I would try that. If it does not fix the problem, we will at least hopefully have a new call stack to examine, one which matches the current state of the codebase.