FormControls.Enabled property quirky limitation

Hi there,

From what I can discern, the FormControls.Enabled property applied with value binding, on a parent div that has inside other divs that change the DataContext to a potentially null child object (textboxes inside these child divs) cannot adapt the value binding expression to the new nullable context of each of those textboxes.

It crashes with this:

    Innermost exception [1/2]:    Object reference not set to an instance of an object.
    Type:    System.NullReferenceException
    Declaring type:    System.Runtime.CompilerServices.CastHelpers
    Stack trace (filtered):
        at DotVVM.Framework.Controls.TextBox.get_Enabled() in /_/src/Framework/Framework/Controls/TextBox.cs:line 25
        at DotVVM.Framework.Controls.TextBox.AddEnabledPropertyToRender(IHtmlWriter writer) in /_/src/Framework/Framework/Controls/TextBox.cs:line 202
        at DotVVM.Framework.Controls.TextBox.AddAttributesToRender(IHtmlWriter writer, IDotvvmRequestContext context) in /_/src/Framework/Framework/Controls/TextBox.cs:line 172
        at DotVVM.Framework.Controls.DotvvmControl.RenderControl(IHtmlWriter writer, IDotvvmRequestContext context) in /_/src/Framework/Framework/Controls/DotvvmControl.cs:line 314
        at DotVVM.Framework.Controls.DotvvmControl.Render(IHtmlWriter writer, IDotvvmRequestContext context) in /_/src/Framework/Framework/Controls/DotvvmControl.cs:line 200

Works for the <bp:DatePicker, crashes for the <bp:TextBox-es because they are inside some null DataContext objects.

How can I use FormControls.Enabled in the case of these textboxes without complicating things?

I think my assumption is right because fully qualifying the members used in the value binding makes the crash go away

But you can surely say that doing this can determine very lengthy expressions if FormControls.Enabled needs to be applied in places more deep in the page’s structure.
Anyhow, I think if this is not a bug of DotVVM, the aspect could come in handy for others if mentioned here or somewhere easy to find: Common control properties | DotVVM Documentation

Buuut, fully qualifying from _root while OperationFinalizationSection (from the last example) may toggle between null and not null does not result in correct behaviour when consulting the UI as an user.

Testing with this:

makes the fields not accessible but with CSS of active textbox → wrong because the binding logic should evaluate to true (OperationFinalizationSection holds an instance)
image

Reverse the logic:
image

and it makes the fields again crazy but backwards crazy, only the CSS of the textboxes being in accordance with the binding logic that now evaluates to false
image

What is this trickery? Can you shed some light on this?

The binding surely shouldn’t crash when a datacontext is null, especially if it’s the data context which isn’t even referenced in it. I’ll try to reproduce this, as it’s definitely a DotVVM bug if true.

Sorry, I don’t understand the issue described in the last comment. Could you please share a larger fraction of your markup, as I don’t get what controls the CSS you describe? In this case, neither the property PopupModal nor the OperationFinalizationSection properties are null and DotVVM evaluates == null to true?

please, yes.

Here’s the markup context for the OperationFinalizationSection:

it is a MarkupControl (.dotcontrol) inside another inside a .dothtml file.

Yes.
PopupModal and OperationFinalizationSection , both are != null, because otherwise I would not see those “AAA” and “BBB” textboxes from the images. They all reside inside OperationFinalizationSection that is inside PopupModal.
Then, at runtime, the behaviour is backwards as the logic dictates in the bound expression.

The CSS worries me less. What is the main weirdness is that the bound expression evaluates to true but the fields are disabled and then, when the expression evaluates to false, the fields become enabled. In WebForms I would encounter this particular situation when a particular UpdatePanel structure is employed (like one child UpdatePanel not updating itself on the first client comeback, but subsequently being forced to update by its parent that updates) and the UI lags one PostBack behind, the UI becoming on step behind the user’s action. But in the case of DotVVM? Maybe I’m using it wrong.

Sorry, there is indeed a dumb bug which makes the TextBox evaluate the FormControls.Enabled binding server-side, I don’t why didn’t I see this the first time. The fix is coming in Fix and maybe optimize CopyProperty for inherited properties by exyi · Pull Request #1850 · riganti/dotvvm · GitHub. Thank you for reporting the issue

1 Like

I confirm that this issue is now resolved after I’ve updated to NuGet Gallery | DotVVM.AspNetCore 4.3.0-preview06-final

1 Like