あなたの問題は2つの部分です。まず、これらがどのように機能するかを理解するのに役立つ疑似 IIF ステートメントを次に示します。
IIF(IsNull(SomeFieldOrControl),ConditionIsTrueSoDoThis,ConditionIsFalseSoDoThis)
これを説明する別の方法は、cmbo_b が null の場合に長さゼロの文字列を表示する次の例です。
cbmo_b が null の場合、長さゼロの文字列が表示されます。
IIF(IsNull([Forms]![frm_a]![cmbo_b]),"",[Forms]![frm_a]![cmbo_b])
IsNull 関数を Nz (null to zero) 関数に切り替える必要があると思います。
2 番目の部分については、2 つの部分からなる条件を評価する場合、通常は次のように括弧で囲む必要があります。これがうまくいくとは本当に思いませんが、一度に 2 つの異なる可能性を評価しようとする場合、これしか考えられません。条件が true と評価された場合に 0 を表示するように設定しました。そもそもIIF関数を正しく使用していなかったため、ステートメントがtrueの場合に何を表示したいのか本当にわかりません。
IIF(Nz([Forms]![frm_a]![cmbo_b],0)(<2 or >3),0,[Forms]![frm_a]![cmbo_b])
条件 = 3 であるかどうかを確認するだけでなく、それがラウンドアバウトの方法で評価しているように見えるので、なぜチェックしないのか疑問に思っています。条件が真であることが判明した場合に何を表示するかは、コードから手がかりが得られないため、まだわかりません。
IIF(Nz([Forms]![frm_a]![cmbo_b],0)=3,0,[Forms]![frm_a]![cmbo_b])
最後に、これは個人的な好みの問題かもしれませんが、回避策がない限り、他のフォームのコントロールを参照しないようにしています。このようなコードは、フォームやコントロールの名前を変更したり、単純にフォームをサブフォームにしたりすると、コードが失敗したりエラーになったりするため、非常に壊れやすい傾向があります。それが完全に間違っているというわけではありません。読みやすく、できるだけ保守しやすいコードに固執しようとしているだけです。
私がよく行うことは、フォームまたはサブフォームにパブリック関数を作成し、次のようなステートメントを使用してそれらを呼び出すことです。
Call Forms("frm_a").MyPublicFunctionName()
また
Call Me.Parent.MyPublicFunctionName() 'Call function on main form from subform
また
Call Me.subform1.Form.MyPublicFunctionName() 'Call function on subform
繰り返しますが、これは個人的な好みの問題かもしれません。MyPublicFunctionName 内でエラーが発生するとコードが上記の行で停止し、どの行が実際に問題を引き起こしているのかがわからないため、このようなパブリック関数はデバッグが困難です。