Potential bug with RadioButton fix in discussion #2333 #2534
-
Hi Jorj, Quick question for you. In #2333 there is a new feature released to activate radio buttons, and the _checker() method attempts to deactivate other grouped buttons if appropriate: ...
# if setting a radio button to ON, first set Off all buttons
# in the group - this is not done by MuPDF:
if self.field_type == PDF_WIDGET_TYPE_RADIOBUTTON and self.field_value not in (False, "Off") and hasattr(self, "parent"):
# so we are about setting this button to ON/True
# check other buttons in same group and set them to 'Off'
doc = self.parent.parent
kids_type, kids_value = doc.xref_get_key(self.xref, "Parent/Kids")
if kids_type == "array":
doc.xref_set_key(self.xref, "Parent/V", "(Off)") # set off old value
xrefs = tuple(map(int, kids_value[1:-1].replace("0 R","").split()))
for xref in xrefs:
if xref != self.xref:
doc.xref_set_key(xref, "AS", "/Off")
# the calling method will now set the intended button to on and
# will find everything prepared for correct functioning. When setting a radio button using this, specifically this line: doc.xref_set_key(self.xref, "Parent/V", "(Off)") # set off old value I'm getting a RuntimeError: Is that line actually needed? Examining that xref key in my case seems to be referencing a null key: >>> doc.xref_get_key(widget_xref_in_question, 'Parent/V')
('null', 'null') commenting out that one line seems to give the expected result. I'm not sure if it's just the formatting of my document or if it's not actually required at all. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
This line is just a safeguard. Thinking more about this, you are probably right: the "Parent" is about to be set to the ON value of some of its kids shortly after, so there is no point to setting it OFF at this point. Otherwise, I have ben too optimistic here: the Parent object may point to its Could you make an enhancement issue for this please? |
Beta Was this translation helpful? Give feedback.
This line is just a safeguard. Thinking more about this, you are probably right: the "Parent" is about to be set to the ON value of some of its kids shortly after, so there is no point to setting it OFF at this point.
Otherwise, I have ben too optimistic here: the Parent object may point to its
/V
key indirectly, as an xref. Instead of fiddling around to cover these (anyway awkward) cases, we could simply not even try to do it.Could you make an enhancement issue for this please?
Thanks for spotting this in any case!