`optional` field with `cond` depending on another `optional` field.

[KhaledEmaraDev]

Hi, I have the following schema definition:

<optional name="OFRQ8_14" cond="$FRQ1_7.FX">
  <set name="FRQ8_14" length="1">
      <bit name="FRN8" idx="7" />
      <bit name="FRN9" idx="6" />
      <bit name="FRN10" idx="5" />
      <bit name="FRN11" idx="4" />
      <bit name="FRN12" idx="3" />
      <bit name="FRN13" idx="2" />
      <bit name="FRN14" idx="1" />
      <bit name="FX" idx="0" />
  </set>
</optional>
<optional name="OFRQ15_21" cond="$OFRQ8_14.FRQ8_14.FX">
  <set name="FRQ15_21" length="1">
      <bit name="FRN15" idx="7" />
      <bit name="FRN16" idx="6" />
      <bit name="FRN17" idx="5" />
      <bit name="FRN18" idx="4" />
      <bit name="FRN19" idx="3" />
      <bit name="FRN20" idx="2" />
      <bit name="FRN21" idx="1" />
      <bit name="FX" idx="0" />
  </set>
</optional>

where the OFRQ15_21 field depends on an inner field within OFRQ8_14.

However it keeps complaining the it needs to be an existing field.

How can I make this work. It makes sense to me that I test the existence of the first optional field first. How can I do this?

[arobenko]

Hi @KhaledEmaraDev, Currently referencing the <optional> field members in the cond-itions is not supported / implemented. I'll check what I can do about it. It may take me a couple of weeks to implement.

However, you can always use custom code injection to implement read, write, refresh, ect... functionality correctly. Just drop usage of the cond property of the OFRQ15_21 field and see what kind of code is generated for the message operations. Then use it for reference and provide a correct implementation in your injected code.

[KhaledEmaraDev]

Hi @arobenko, Thank you so much for the prompt response. And thank you for this great ecosystem.

[arobenko]

Hi @KhaledEmaraDev, Looks like supporting the case was easier than I expected. You can try it using "develop" branch. Let me know if it works for you as expected. If there are no problems it will find its way into the next official release within a month or so.

[KhaledEmaraDev]

That was super fast. Thank you @arobenko.

I'll test it out and report back if there any problems.

[arobenko]

BTW, forgot to mention, you'll probably need to use "develop" branch of the COMMS library as well, otherwise you'll encounter a static_assert that the library's version is too old.

[KhaledEmaraDev]

Thank you @arobenko. I noticed and updated it. It's working fine so far. I think we could close this issue now.

[arobenko]

Now available in official v6.2 release.