Angular 2 [disabled] only works on some controls











up vote
1
down vote

favorite












I've got a large form that is generated dynamically based on data I'm given from the server. To generate radio buttons, I use the following HTML:



<ng-container *ngSwitchCase="'RADIO'">
<td *ngFor="let option of item.SelectOptions">
<div class="input-group">
<input type="radio"
[(ngModel)]="item.PricingSelectIndex"
name="{{ item.UIName }}RadioButton"
id="{{ item.UIName }}{{ option.PricingSelectIndex }}"
[value]="option.PricingSelectIndex"
[disabled]="item.ReadonlyTF"
(click)="saveField(item.UIName, 'SelectIndex', option.PricingSelectIndex)" />
<label for="{{ item.UIName }}{{ option.PricingSelectIndex }}" style="margin-left: 5px;">
{{ option.Label }}
<i class="fa fa-question-circle" [tooltip]="item.TooltipText" placement="right" *ngIf="item.TooltipText"></i>
</label>
</div>
</td>
</ng-container>


Obviously this is part of a larger page, which looks at each item from the data and generates the form based on the item's ControlType property-- this is the HTML for radio buttons. The data item includes a property called ReadonlyTF which tells me whether the control should be disabled (e.g. read-only). The item then includes a SelectOptions property which is an array of smaller items, each of which maps to one radio button in the set. (So for example, the control I'm having trouble with has two SelectOptions, one for Yes and one for No.) Each radio button is therefore generated with identical HTML.



Here's the weird thing. In the control in question, the first radio button generated is disabled (which is what I want), but the second one isn't.



yesnodisabled



If you look closely you can see that Yes is disabled but No is not! Here's how the two controls are rendered in Chrome's Elements tab:



elements



Both include ng-reflect-is-disabled="true" but only the first is actually disabled. The second button is missing ng-reflect-value. Again, these are being rendered with the exact same HTML snippet.



I'm using Angular 2.4.6, Typescript 2.1.5, bootstrap 3.3.7, and angular-cli to compile. There's no supporting TS in the component that would affect this: I get the data and pop it into a property that is then picked up by the HTML template, and that's it. I thought it might be some sort of change detection issue, but forcing it with changeDetectorRef.detectChanges() didn't do anything. I'm stumped on this but I can't have an active radio button sitting out there for anybody to click!



Thanks!










share|improve this question






















  • Can you setup an example of it misbehaving in plnkr or something
    – Joshua Ohana
    Jun 23 '17 at 23:21










  • Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
    – Daniel Gimenez
    Aug 9 '17 at 12:14















up vote
1
down vote

favorite












I've got a large form that is generated dynamically based on data I'm given from the server. To generate radio buttons, I use the following HTML:



<ng-container *ngSwitchCase="'RADIO'">
<td *ngFor="let option of item.SelectOptions">
<div class="input-group">
<input type="radio"
[(ngModel)]="item.PricingSelectIndex"
name="{{ item.UIName }}RadioButton"
id="{{ item.UIName }}{{ option.PricingSelectIndex }}"
[value]="option.PricingSelectIndex"
[disabled]="item.ReadonlyTF"
(click)="saveField(item.UIName, 'SelectIndex', option.PricingSelectIndex)" />
<label for="{{ item.UIName }}{{ option.PricingSelectIndex }}" style="margin-left: 5px;">
{{ option.Label }}
<i class="fa fa-question-circle" [tooltip]="item.TooltipText" placement="right" *ngIf="item.TooltipText"></i>
</label>
</div>
</td>
</ng-container>


Obviously this is part of a larger page, which looks at each item from the data and generates the form based on the item's ControlType property-- this is the HTML for radio buttons. The data item includes a property called ReadonlyTF which tells me whether the control should be disabled (e.g. read-only). The item then includes a SelectOptions property which is an array of smaller items, each of which maps to one radio button in the set. (So for example, the control I'm having trouble with has two SelectOptions, one for Yes and one for No.) Each radio button is therefore generated with identical HTML.



Here's the weird thing. In the control in question, the first radio button generated is disabled (which is what I want), but the second one isn't.



yesnodisabled



If you look closely you can see that Yes is disabled but No is not! Here's how the two controls are rendered in Chrome's Elements tab:



elements



Both include ng-reflect-is-disabled="true" but only the first is actually disabled. The second button is missing ng-reflect-value. Again, these are being rendered with the exact same HTML snippet.



I'm using Angular 2.4.6, Typescript 2.1.5, bootstrap 3.3.7, and angular-cli to compile. There's no supporting TS in the component that would affect this: I get the data and pop it into a property that is then picked up by the HTML template, and that's it. I thought it might be some sort of change detection issue, but forcing it with changeDetectorRef.detectChanges() didn't do anything. I'm stumped on this but I can't have an active radio button sitting out there for anybody to click!



Thanks!










share|improve this question






















  • Can you setup an example of it misbehaving in plnkr or something
    – Joshua Ohana
    Jun 23 '17 at 23:21










  • Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
    – Daniel Gimenez
    Aug 9 '17 at 12:14













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I've got a large form that is generated dynamically based on data I'm given from the server. To generate radio buttons, I use the following HTML:



<ng-container *ngSwitchCase="'RADIO'">
<td *ngFor="let option of item.SelectOptions">
<div class="input-group">
<input type="radio"
[(ngModel)]="item.PricingSelectIndex"
name="{{ item.UIName }}RadioButton"
id="{{ item.UIName }}{{ option.PricingSelectIndex }}"
[value]="option.PricingSelectIndex"
[disabled]="item.ReadonlyTF"
(click)="saveField(item.UIName, 'SelectIndex', option.PricingSelectIndex)" />
<label for="{{ item.UIName }}{{ option.PricingSelectIndex }}" style="margin-left: 5px;">
{{ option.Label }}
<i class="fa fa-question-circle" [tooltip]="item.TooltipText" placement="right" *ngIf="item.TooltipText"></i>
</label>
</div>
</td>
</ng-container>


Obviously this is part of a larger page, which looks at each item from the data and generates the form based on the item's ControlType property-- this is the HTML for radio buttons. The data item includes a property called ReadonlyTF which tells me whether the control should be disabled (e.g. read-only). The item then includes a SelectOptions property which is an array of smaller items, each of which maps to one radio button in the set. (So for example, the control I'm having trouble with has two SelectOptions, one for Yes and one for No.) Each radio button is therefore generated with identical HTML.



Here's the weird thing. In the control in question, the first radio button generated is disabled (which is what I want), but the second one isn't.



yesnodisabled



If you look closely you can see that Yes is disabled but No is not! Here's how the two controls are rendered in Chrome's Elements tab:



elements



Both include ng-reflect-is-disabled="true" but only the first is actually disabled. The second button is missing ng-reflect-value. Again, these are being rendered with the exact same HTML snippet.



I'm using Angular 2.4.6, Typescript 2.1.5, bootstrap 3.3.7, and angular-cli to compile. There's no supporting TS in the component that would affect this: I get the data and pop it into a property that is then picked up by the HTML template, and that's it. I thought it might be some sort of change detection issue, but forcing it with changeDetectorRef.detectChanges() didn't do anything. I'm stumped on this but I can't have an active radio button sitting out there for anybody to click!



Thanks!










share|improve this question













I've got a large form that is generated dynamically based on data I'm given from the server. To generate radio buttons, I use the following HTML:



<ng-container *ngSwitchCase="'RADIO'">
<td *ngFor="let option of item.SelectOptions">
<div class="input-group">
<input type="radio"
[(ngModel)]="item.PricingSelectIndex"
name="{{ item.UIName }}RadioButton"
id="{{ item.UIName }}{{ option.PricingSelectIndex }}"
[value]="option.PricingSelectIndex"
[disabled]="item.ReadonlyTF"
(click)="saveField(item.UIName, 'SelectIndex', option.PricingSelectIndex)" />
<label for="{{ item.UIName }}{{ option.PricingSelectIndex }}" style="margin-left: 5px;">
{{ option.Label }}
<i class="fa fa-question-circle" [tooltip]="item.TooltipText" placement="right" *ngIf="item.TooltipText"></i>
</label>
</div>
</td>
</ng-container>


Obviously this is part of a larger page, which looks at each item from the data and generates the form based on the item's ControlType property-- this is the HTML for radio buttons. The data item includes a property called ReadonlyTF which tells me whether the control should be disabled (e.g. read-only). The item then includes a SelectOptions property which is an array of smaller items, each of which maps to one radio button in the set. (So for example, the control I'm having trouble with has two SelectOptions, one for Yes and one for No.) Each radio button is therefore generated with identical HTML.



Here's the weird thing. In the control in question, the first radio button generated is disabled (which is what I want), but the second one isn't.



yesnodisabled



If you look closely you can see that Yes is disabled but No is not! Here's how the two controls are rendered in Chrome's Elements tab:



elements



Both include ng-reflect-is-disabled="true" but only the first is actually disabled. The second button is missing ng-reflect-value. Again, these are being rendered with the exact same HTML snippet.



I'm using Angular 2.4.6, Typescript 2.1.5, bootstrap 3.3.7, and angular-cli to compile. There's no supporting TS in the component that would affect this: I get the data and pop it into a property that is then picked up by the HTML template, and that's it. I thought it might be some sort of change detection issue, but forcing it with changeDetectorRef.detectChanges() didn't do anything. I'm stumped on this but I can't have an active radio button sitting out there for anybody to click!



Thanks!







angular angular2-template






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jun 23 '17 at 16:21









Nat Webb

388214




388214












  • Can you setup an example of it misbehaving in plnkr or something
    – Joshua Ohana
    Jun 23 '17 at 23:21










  • Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
    – Daniel Gimenez
    Aug 9 '17 at 12:14


















  • Can you setup an example of it misbehaving in plnkr or something
    – Joshua Ohana
    Jun 23 '17 at 23:21










  • Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
    – Daniel Gimenez
    Aug 9 '17 at 12:14
















Can you setup an example of it misbehaving in plnkr or something
– Joshua Ohana
Jun 23 '17 at 23:21




Can you setup an example of it misbehaving in plnkr or something
– Joshua Ohana
Jun 23 '17 at 23:21












Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
– Daniel Gimenez
Aug 9 '17 at 12:14




Ironically by covering up the names in your html you prevented people from finding the answer. I ran into the same exact behavior and was able to figure it out.
– Daniel Gimenez
Aug 9 '17 at 12:14












2 Answers
2






active

oldest

votes

















up vote
4
down vote



accepted










The reason this is occurring is because you have multiple input elements with NgModel directive and the same name attribute. The internal logic of NgModel toggles disable() and enable() on the form control based upon the value of the disabled input. Since you have only one form control due to the name conflict some where further down line only the first element gets updated.



Make the name attributes unique and your problem should go away.



You can walk through this behavior if you view the source for ng_model.ts.






share|improve this answer























  • Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
    – Nat Webb
    Jul 30 at 16:05






  • 1




    The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
    – Daniel Gimenez
    Jul 30 at 18:47




















up vote
0
down vote













I know this is a poor solution, but it will help:



<input *ngIf="shouldBeDisabled" name="foo" disabled>
<input *ngIf="!shouldBeDisabled" name="foo">





share|improve this answer










New contributor




Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f44726034%2fangular-2-disabled-only-works-on-some-controls%23new-answer', 'question_page');
    }
    );

    Post as a guest
































    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote



    accepted










    The reason this is occurring is because you have multiple input elements with NgModel directive and the same name attribute. The internal logic of NgModel toggles disable() and enable() on the form control based upon the value of the disabled input. Since you have only one form control due to the name conflict some where further down line only the first element gets updated.



    Make the name attributes unique and your problem should go away.



    You can walk through this behavior if you view the source for ng_model.ts.






    share|improve this answer























    • Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
      – Nat Webb
      Jul 30 at 16:05






    • 1




      The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
      – Daniel Gimenez
      Jul 30 at 18:47

















    up vote
    4
    down vote



    accepted










    The reason this is occurring is because you have multiple input elements with NgModel directive and the same name attribute. The internal logic of NgModel toggles disable() and enable() on the form control based upon the value of the disabled input. Since you have only one form control due to the name conflict some where further down line only the first element gets updated.



    Make the name attributes unique and your problem should go away.



    You can walk through this behavior if you view the source for ng_model.ts.






    share|improve this answer























    • Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
      – Nat Webb
      Jul 30 at 16:05






    • 1




      The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
      – Daniel Gimenez
      Jul 30 at 18:47















    up vote
    4
    down vote



    accepted







    up vote
    4
    down vote



    accepted






    The reason this is occurring is because you have multiple input elements with NgModel directive and the same name attribute. The internal logic of NgModel toggles disable() and enable() on the form control based upon the value of the disabled input. Since you have only one form control due to the name conflict some where further down line only the first element gets updated.



    Make the name attributes unique and your problem should go away.



    You can walk through this behavior if you view the source for ng_model.ts.






    share|improve this answer














    The reason this is occurring is because you have multiple input elements with NgModel directive and the same name attribute. The internal logic of NgModel toggles disable() and enable() on the form control based upon the value of the disabled input. Since you have only one form control due to the name conflict some where further down line only the first element gets updated.



    Make the name attributes unique and your problem should go away.



    You can walk through this behavior if you view the source for ng_model.ts.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Aug 9 '17 at 12:20

























    answered Aug 8 '17 at 21:16









    Daniel Gimenez

    10.3k22345




    10.3k22345












    • Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
      – Nat Webb
      Jul 30 at 16:05






    • 1




      The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
      – Daniel Gimenez
      Jul 30 at 18:47




















    • Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
      – Nat Webb
      Jul 30 at 16:05






    • 1




      The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
      – Daniel Gimenez
      Jul 30 at 18:47


















    Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
    – Nat Webb
    Jul 30 at 16:05




    Well, a year later I was still having this problem, Googled it, and found my own StackOverflow question. You hit the nail on the head with your solution, thanks! I'm curious, couldn't this cause problems, since radio buttons in the same group are meant to share the same name?
    – Nat Webb
    Jul 30 at 16:05




    1




    1




    The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
    – Daniel Gimenez
    Jul 30 at 18:47






    The same restriction applies - each radio button the shares a name has to bind to the exact same model. You can't have different models for each radio. It makes sense when you think that the model can only have the value of one radio since only one can be selected at a time.
    – Daniel Gimenez
    Jul 30 at 18:47














    up vote
    0
    down vote













    I know this is a poor solution, but it will help:



    <input *ngIf="shouldBeDisabled" name="foo" disabled>
    <input *ngIf="!shouldBeDisabled" name="foo">





    share|improve this answer










    New contributor




    Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      up vote
      0
      down vote













      I know this is a poor solution, but it will help:



      <input *ngIf="shouldBeDisabled" name="foo" disabled>
      <input *ngIf="!shouldBeDisabled" name="foo">





      share|improve this answer










      New contributor




      Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















        up vote
        0
        down vote










        up vote
        0
        down vote









        I know this is a poor solution, but it will help:



        <input *ngIf="shouldBeDisabled" name="foo" disabled>
        <input *ngIf="!shouldBeDisabled" name="foo">





        share|improve this answer










        New contributor




        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        I know this is a poor solution, but it will help:



        <input *ngIf="shouldBeDisabled" name="foo" disabled>
        <input *ngIf="!shouldBeDisabled" name="foo">






        share|improve this answer










        New contributor




        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer








        edited Nov 8 at 10:39









        Suraj Rao

        22k75467




        22k75467






        New contributor




        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered Nov 8 at 10:37









        Damian Kołod

        1




        1




        New contributor




        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        Damian Kołod is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f44726034%2fangular-2-disabled-only-works-on-some-controls%23new-answer', 'question_page');
            }
            );

            Post as a guest




















































































            Popular posts from this blog

            Schultheiß

            Verwaltungsgliederung Dänemarks

            Liste der Kulturdenkmale in Wilsdruff