What is GENATTR?
I am guessing, since it has ROW%N references, that it must be a table?
The property setting FORM.FIELDS.GENATTR.ROW%2.VALUE.ITEM%1.TEXT implies that there is a drop down literally named ‘VALUE’ in row 2 of the table named GENATTR?
If yes – and VALUE is meant to be a label – then you are either sending out ITEM% properties against a Type=Label element – or the new form setting is wrong and they are hanging about on the client in the old form that is to be updated (note: the 'old/original form' only exists when newform=false).
If VALUE is not the dropdown or label in question – then the full name FORM.FIELDS.GENATTR.ROW%2.VALUE.ITEM%1.TEXT looks like it might be structurally incorrect?
(RDMLX) Change DD to label issue
Re: (RDMLX) Change DD to label bug?
The dd is in a table row (2 and 3 in this example).
Then click save button which changes them to labels and redisplays the same form (new form is true) and get this error. It seems that the old form is hanging about when it should not. The example I sent on other thread has this example as well (click label button instead of dd drill) but it works (much much simpler version then the real app).
Then click save button which changes them to labels and redisplays the same form (new form is true) and get this error. It seems that the old form is hanging about when it should not. The example I sent on other thread has this example as well (click label button instead of dd drill) but it works (much much simpler version then the real app).
Re: (RDMLX) Change DD to label bug?
The example in other thread now shows this problem too.
The issue is the the 2nd tier is getting and setting the drop down (actually rebuilding in tier 3 call) not knowing tier1 is going to rebuild as a label causing this error (new form). The call to tier 3 is unnecessary and can simply be a set_dropdown instead (or not do at all since the value is not changing).
So no bug after all the research lol
I think I will keep the elements as original type rather than go with label. The appearance(Plain) and disabled(True) properties give the same result as set_label. And then we do not worry about element type problems ...
Thanks Mark
The issue is the the 2nd tier is getting and setting the drop down (actually rebuilding in tier 3 call) not knowing tier1 is going to rebuild as a label causing this error (new form). The call to tier 3 is unnecessary and can simply be a set_dropdown instead (or not do at all since the value is not changing).
So no bug after all the research lol
I think I will keep the elements as original type rather than go with label. The appearance(Plain) and disabled(True) properties give the same result as set_label. And then we do not worry about element type problems ...
Thanks Mark
-
MarkDuignan
- Posts: 346
- Joined: Wed Apr 18, 2012 10:33 am
Re: (RDMLX) Change DD to label bug?
I don;t think you need to use the plain appearance - just set disabled.
See disabled appearance table in previous post.
See disabled appearance table in previous post.
Re: (RDMLX) Change DD to label issue
Steve
In your original code (which generated the error), are you using "Set_Label" or "Set_Dropdown disabled(True)"? If it is the former, then this would generate the error you show. The latter should work and show your dropdown "as a label". Also, are you passing the LRNG_Form as a parameter and invoking the lower level reusable parts as mthRoutines with the LRNG_Form as a "define_map for(*INPUT) reference(*DYNAMIC)" ?
In your original code (which generated the error), are you using "Set_Label" or "Set_Dropdown disabled(True)"? If it is the former, then this would generate the error you show. The latter should work and show your dropdown "as a label". Also, are you passing the LRNG_Form as a parameter and invoking the lower level reusable parts as mthRoutines with the LRNG_Form as a "define_map for(*INPUT) reference(*DYNAMIC)" ?
Regards,
David
David
Re: (RDMLX) Change DD to label issue
I am using the same element type now and disabled(true) and it is working fine