- Feedback
-
Fejl
0
Fast
Exception error when editing actions
When I edit an action on the Next screen and then close the application (with X) which minimizes to the tray then the error below is produced. The application did save the edited text though!
System.NullReferenceException: Object reference not set to an instance of an object.
at Odyssey.Controls.RibbonWindow.ScreenToLocal(Point point)
at Odyssey.Controls.RibbonWindow.NCHitTest(Point p, Rect rect)
at Odyssey.Controls.RibbonWindow.WndProcHitTest(IntPtr hwnd, IntPtr lParam, Boolean& handled, IntPtr& result)
at Odyssey.Controls.RibbonWindow.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at Wieldy.Client.Windows.MainWindow.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
System.NullReferenceException: Object reference not set to an instance of an object.
at Odyssey.Controls.RibbonWindow.ScreenToLocal(Point point)
at Odyssey.Controls.RibbonWindow.NCHitTest(Point p, Rect rect)
at Odyssey.Controls.RibbonWindow.WndProcHitTest(IntPtr hwnd, IntPtr lParam, Boolean& handled, IntPtr& result)
at Odyssey.Controls.RibbonWindow.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at Wieldy.Client.Windows.MainWindow.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
Svar
It happens when I leave the cursor on the edited field. So I edit some text and leave the cursor blinking on the edited field. If I click anywhere else first and then the X, there is no problem. My guess is that the edit field tries to do something when it looses focus but at that time it is already being destroyed because of the click on the X. Let me know if I guessed somewhat right :-)
I tried it on different machines (Windows XP and Win 7 32/64 bit) and unfortunately i could not yet reproduce this behavior. Which operating system do you have?
Does this happen every time? And which field does produce this error? I opened an action and tested it with different fields like title, notes or due date. But when clicking on the X the window is closed normally.
Does this happen every time? And which field does produce this error? I opened an action and tested it with different fields like title, notes or due date. But when clicking on the X the window is closed normally.
Operating system is Windows XP Professional Service Pack 3 (English). It only happens with the title field and I can reproduce the error every time.
These are the exact steps I take:
- Open Wieldy from the system tray: I have it configured to open the Next screen where I have about 20 actions defined.
- Open an action by double clicking or using the arrows.
- Change the text of the title.
- Press the X while the action is still expanded and the cursor is visible in the title field.
- The window with the error message is produced.
It only happens when I leave the cursor on the edited title field! If I click anywhere else first there is no problem.
Thanks for looking into this and let me know if you need more info.
These are the exact steps I take:
- Open Wieldy from the system tray: I have it configured to open the Next screen where I have about 20 actions defined.
- Open an action by double clicking or using the arrows.
- Change the text of the title.
- Press the X while the action is still expanded and the cursor is visible in the title field.
- The window with the error message is produced.
It only happens when I leave the cursor on the edited title field! If I click anywhere else first there is no problem.
Thanks for looking into this and let me know if you need more info.
I did exactly what you described and i can not reproduce it, sorry.
Does this also happen when you for example edit the title of an tag?
I tested it on two machines running the german version of windows xp sp3.
I uploaded a new beta version which adds some more reference checks. Maybe this solves the issue.
Does this also happen when you for example edit the title of an tag?
I tested it on two machines running the german version of windows xp sp3.
I uploaded a new beta version which adds some more reference checks. Maybe this solves the issue.
With the new beta version there's good news and bad news. The good news is that the error is gone. The bad news is that the data doesn't get saved anymore. In the previous version when you edited the title of an action there would immediately appear a * next to the version number in the title bar of Wieldy. With this beta version that is no longer the case. The * only appears if you click somewhere else first. So if you type some text and press the X the data isn't saved anymore but at least the error is gone.
PS: I didn't test with the title of a tag as I was too fast installing the beta.
PS: I didn't test with the title of a tag as I was too fast installing the beta.
The * will be cleared when the window is closed. This happens
because the data will be saved, when the window is closed.
Can you verify if the changes you made are really lost?
because the data will be saved, when the window is closed.
Can you verify if the changes you made are really lost?
Upon further testing things get more complicated but I think I have something you can work with following these steps:
- Expand an action by double clicking or using the arrows and change the text of the title.
- Expand another action (not the same as the previous one) and change the text of the title.
- Click the X without clicking somewhere else first.
- The first edited action is saved, the second one is not saved.
So if the * is visible because you have already edited something that needs to be saved and then you edit an action and click the X while leaving the action expanded, the change in that last action is not saved.
Hope this helps.
- Expand an action by double clicking or using the arrows and change the text of the title.
- Expand another action (not the same as the previous one) and change the text of the title.
- Click the X without clicking somewhere else first.
- The first edited action is saved, the second one is not saved.
So if the * is visible because you have already edited something that needs to be saved and then you edit an action and click the X while leaving the action expanded, the change in that last action is not saved.
Hope this helps.
Thanks for the feedback. I couldn't find it yet, as this does not happen on any of my systems.
This is really odd, but i will continue searching.
This is really odd, but i will continue searching.
I appreciate your effort in this matter. Because I'm a developer myself I know how difficult it is to track something that you can't reproduce. If you need more info, let me know and in the meantime I will try this myself on different machines. Maybe that will get us somewhere.
Svar
Fast
I finally found an issue which caused this behaviour. The fix is implemented with beta V0.3.1.989. Please let me know if the problem is finally fixed.
I'm happy to report that with version beta V0.3.1.989 this is indeed fixed. Many thanks for your continued research on this problem.
Kundesupport af UserEcho
I finally found an issue which caused this behaviour. The fix is implemented with beta V0.3.1.989. Please let me know if the problem is finally fixed.