Hitting Enter causing Logout of Authentication Service (Cocktail + CaliburnMicro)

Topics: Bugs, Conventions
Jul 17, 2013 at 3:33 PM
We ran into a very odd issue where Hitting enter within a UXTextBox(Intersoft), or C1RichTextBox (ComponentOne) caused the application to immediately log out. This of course triggered several actions resulting in the application completely resetting itself.

I was able to solve the issue for the UXTextBox by adding a explicit convention for the type, even though the TextBox existing convention is both identical and was working correctly save for this issue.
        ConventionManager.AddElementConvention<UXTextBox>(UXTextBox.TextProperty, "Text", "TextChanged");
I have similarly tried creating an exact copy of the convention that would normally be applied to a C1RichTextBox that would normally be applied per normal inheritance, but this did not solve the issue for the C1RichText box.

As I am not sure even why what I did fixed the UXTextBox, I am at a loss as to how to proceed.

Has anyone encountered this before?

Thank you,
Kat
Jul 17, 2013 at 3:40 PM
Have you identified what is triggering the logout operation (i.e. an ActionMessage)?
Is it possible the Enter key is associated to either a Trigger or a CommandBinding, and the KeyDown event is somehow not handled by the control itself, causing the event to bubble up?
Jul 17, 2013 at 3:45 PM
Edited Jul 17, 2013 at 3:45 PM
This still happens if all the code triggering a logout is removed from the application. I can have the project set to break on the next possible line, and the next line hit is the event handler for AuthenticationService.LoggedOut.

We are at a loss as to what could possibly be going on here.
Jul 17, 2013 at 3:46 PM
I should also note that the C1RichTextBox has no bindings or commands, they are named as we need to pick them up in OnViewAttached in order to process teh C!Document object within it correctly.
Jul 17, 2013 at 3:57 PM
Inspecting the stack trace you should be able to identify what actually trigger the logout operation.
To be able to properly debug the application, you can even disable Visual Studio 'Just My Code' option and turn on Source Server Support, to navigate the full stack trace instead of a portion of it (the one considered as 'your' code by the debugger).
Jul 17, 2013 at 4:01 PM
I have done that and Can only see that the CaliburnMicro Binder is involved. let me get a stack trace by reproducing the issue.
Jul 17, 2013 at 5:05 PM
Ok, so I was getting the stack trace, which was still utterly useless in debugging this, When I noticed something I should have seen a long time ago. I found this in my output.

ActionMessage INFO: Invoking Action: Login.

Ok, so now I know what was making it logout, as this had no password and failed to login again. But here is the weird part. That method is on a ViewModel that has been deactivated and closed. Yet it is still firing. I did trace it to a Button that has IsDefault= true. However, changing the IsDeafult to false after a sucessful login did not change anything.

I ended up going with a hackery fix of
     public async void Login()
    {
        if (!IsActive) return;

My concern is, Why is this viewModel still around. It is composed by my ShellViewModel, which inherits from Condoctor<IScreen> and has already Activated another ViewModel in its place. OnDeactivate(true) fires, but yet, this view/viewmodel combination seems to be sticking around to cause this headache.

Anyone have any ideas. Nothins has a reference to the viewmodel and it does not hold a reference to anything either.

Thank you,
Kat
Jul 17, 2013 at 5:24 PM
I'm afraid you need to use a profiler and analyze the retention graph... It's pretty much impossible to determine what's keeping the object on memory without having a look at the actual code...