Yes/No field

[solar]

I want to perform a function called cancelorderonexit provided that
customerid is Null ,the Yes/No control ChkStorehouse is set to True or
the Yes/No field ChkWarehouse is set to True . Unfortunately the
function below does not obey me, and the code is performed even though
the ChkStorehouse is set to Yes
If Not IsNull(Me![customerid]) Or IsNull(Me![ChkStorehouse]) Then
CancelOrderOnExit
DoCmd.CancelEvent
End If

What is wrong ?

[Wayne Morgan]

The logic in the If statement doesn't match what you said you want to do. To
have it match what you said you want to do, it should be

If IsNull(Me![customerid]) Or Me!{ChkStoreHouse] Or Me![ChkStorehouse] Then

--
Wayne Morgan
MS Access MVP
"solar" <sp*******@gmail.com> wrote in message
news:11********************@o13g2000cwo.googlegrou ps.com...

I want to perform a function called cancelorderonexit provided that
customerid is Null ,the Yes/No control ChkStorehouse is set to True or
the Yes/No field ChkWarehouse is set to True . Unfortunately the
function below does not obey me, and the code is performed even though
the ChkStorehouse is set to Yes
If Not IsNull(Me![customerid]) Or IsNull(Me![ChkStorehouse]) Then
CancelOrderOnExit
DoCmd.CancelEvent
End If

What is wrong ?

[Tom van Stiphout]

On 17 Jan 2006 02:52:47 -0800, "solar" <sp*******@gmail.com> wrote:

I think Wayne meant to say:
If Not IsNull(Me![customerid]) Or Me![ChkStorehouse]=True or
Me![ChkWareHouse]=True Then ...

Also, make sure that in your table design, all Yes/No fields are
Required, and have a sensible default value (typically: False). A null
value in a Yes/No field rarely makes sense.

-Tom.

I want to perform a function called cancelorderonexit provided that
customerid is Null ,the Yes/No control ChkStorehouse is set to True or
the Yes/No field ChkWarehouse is set to True . Unfortunately the
function below does not obey me, and the code is performed even though
the ChkStorehouse is set to Yes
If Not IsNull(Me![customerid]) Or IsNull(Me![ChkStorehouse]) Then
CancelOrderOnExit
DoCmd.CancelEvent
End If

What is wrong ?

[Bob Quintal]

Tom van Stiphout <no*************@cox.net> wrote in
news:dl********************************@4ax.com:

On 17 Jan 2006 02:52:47 -0800, "solar" <sp*******@gmail.com>
wrote:

I think Wayne meant to say:
If Not IsNull(Me![customerid]) Or Me![ChkStorehouse]=True or
Me![ChkWareHouse]=True Then ...

Also, make sure that in your table design, all Yes/No fields
are Required, and have a sensible default value (typically:
False). A null value in a Yes/No field rarely makes sense.

-Tom.
No he didnt, other than a typo of { instead of [ and the wrong
variable name.

Me![chkstorehouse] already contains the value of true or false,
so why generate a test to see if true = true?

Me![chkstorehouse] is a valid conditional.

I want to perform a function called cancelorderonexit
provided that customerid is Null ,the Yes/No control
ChkStorehouse is set to True or the Yes/No field ChkWarehouse
is set to True . Unfortunately the function below does not
obey me, and the code is performed even though the
ChkStorehouse is set to Yes If Not IsNull(Me![customerid]) Or
IsNull(Me![ChkStorehouse]) Then CancelOrderOnExit
DoCmd.CancelEvent
End If

What is wrong ?

--
Bob Quintal

PA is y I've altered my email address.

[Lyle Fairfield]

When one corrects one of our most capable regular members, one should
really CHECK to be sure that what one is saying is TRUE.
On a form the safest way to do this is:
If Me!(CheckTomIsWrong) = True Then
MsgBox "One in a Million"
Else
Post your opinion in tentative terms
End If
Someone else will explain why.

[Bob Quintal]

"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11*********************@g49g2000cwa.googlegro ups.com:

When one corrects one of our most capable regular members, one
should really CHECK to be sure that what one is saying is
TRUE. On a form the safest way to do this is:
If Me!(CheckTomIsWrong) = True Then
MsgBox "One in a Million"
Else
Post your opinion in tentative terms
End If
Someone else will explain why.

Lyle, I recognize both you and Tom as knowledgeable.
However I've been coding databases in Access for 10+years, and
in other languages for 35.

If Me!chkAnyBoolean then
has never failed to evaluate correctly, nor have I ever seen
documented evidence of it failing.

If NOT Me!chkAnotherBoolean then
has never failed either. But I have seen and needed to fix
errors caused by Access getting precedence wrong in the type of
statement Tom proposed and attempting to evaluate bSomeBoolean =
False OR bSomeThingEelse = true

--
Bob Quintal

PA is y I've altered my email address.

[Lyle Fairfield]

http://support.microsoft.com/?kbid=190074

A long time ago most regulars here stopped using:
If Me!chkAnyBoolean then
or said they did.

Is this redundant in newer versions? Don't know. Regardless there are
so many Ac97 users floating around here, I think it's still a good idea
to show the " = True" in our answers.

[Wayne Gillespie]

On 17 Jan 2006 17:15:44 -0800, "Lyle Fairfield" <ly***********@aim.com> wrote:

http://support.microsoft.com/?kbid=190074

A long time ago most regulars here stopped using:
If Me!chkAnyBoolean then
or said they did.

Is this redundant in newer versions? Don't know. Regardless there are
so many Ac97 users floating around here, I think it's still a good idea
to show the " = True" in our answers.

IIRC according to a post by MichKa

IF Me!chkAnyBoolean Then Bad
IF Me!chkAnyBoolean = True Then OK
IF (Me!chkAnyBoolean) Then OK

Apparently wrapping the control name in brackets forces the expression to be evaluated correctly and bypasses the nasty
"Boolean Bug"

I believe I have also read that the bug was fixed in versions >A97 but can't find a source to confirm this at the
moment.

Personally I prefer IF Me!chkAnyBoolean = True Then, for readability.
Wayne Gillespie
Gosford NSW Australia

[Bob Quintal]

"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11*********************@g47g2000cwa.googlegro ups.com:

http://support.microsoft.com/?kbid=190074

A long time ago most regulars here stopped using:
If Me!chkAnyBoolean then
or said they did.

Is this redundant in newer versions? Don't know. Regardless
there are so many Ac97 users floating around here, I think
it's still a good idea to show the " = True" in our answers.

To my knowledge, this problem was fixed in Access 2K.

I remember back in 2000 there were several posts here and either
wrapping in parentheses or using a bang instead of a dot.
I've found lots of other reference issues with the dot separator
(recordsets e.g.), but ! doesn't do the autocompletion thingie
so I've gotten into the habit of using a dot and replacing
before compiling my code. Even then I can't recall having Access
lock up for that problem, unlike today when I tested a procedure
not noticing I had forgotten a .movenext statement.
--
Bob Quintal

PA is y I've altered my email address.

[Tom van Stiphout]

On Wed, 18 Jan 2006 01:46:34 GMT, Wayne Gillespie
<be*****@NOhotmailSPAM.com.au> wrote:

Not sure that bracketing the control name helps. Note that the example
of bad coding in the KB article uses brackets as well:
If Me.Parent![CheckBox] Then

I originally responded because I noticed Wayne had doubled-up on a
control name and had a typo, and wasn't sure the OP would understand
how to correct it. When I rewrote the expression I wrote it the way
I'm used to, knowing about that bug referenced in the KB article. I
also like that way better because it's a bit easier to read for most
developers. Some habits die hard.

-Tom.

On 17 Jan 2006 17:15:44 -0800, "Lyle Fairfield" <ly***********@aim.com> wrote:

http://support.microsoft.com/?kbid=190074

A long time ago most regulars here stopped using:
If Me!chkAnyBoolean then
or said they did.

Is this redundant in newer versions? Don't know. Regardless there are
so many Ac97 users floating around here, I think it's still a good idea
to show the " = True" in our answers.

IIRC according to a post by MichKa

IF Me!chkAnyBoolean Then Bad
IF Me!chkAnyBoolean = True Then OK
IF (Me!chkAnyBoolean) Then OK

Apparently wrapping the control name in brackets forces the expression to be evaluated correctly and bypasses the nasty
"Boolean Bug"

I believe I have also read that the bug was fixed in versions >A97 but can't find a source to confirm this at the
moment.

Personally I prefer IF Me!chkAnyBoolean = True Then, for readability.
Wayne Gillespie
Gosford NSW Australia

[Wayne Gillespie]

On Tue, 17 Jan 2006 20:55:02 -0700, Tom van Stiphout <no*************@cox.net> wrote:

On Wed, 18 Jan 2006 01:46:34 GMT, Wayne Gillespie
<be*****@NOhotmailSPAM.com.au> wrote:

Not sure that bracketing the control name helps. Note that the example
of bad coding in the KB article uses brackets as well:
If Me.Parent![CheckBox] Then

I originally responded because I noticed Wayne had doubled-up on a
control name and had a typo, and wasn't sure the OP would understand
how to correct it. When I rewrote the expression I wrote it the way
I'm used to, knowing about that bug referenced in the KB article. I
also like that way better because it's a bit easier to read for most
developers. Some habits die hard.

-Tom.

The entire reference to the checkbox had to bracketed, not just the control name.
IOW
If (Me.Parent![CheckBox]) Then
instead of
If Me.Parent![CheckBox] Then

The parens force a value to be returned rather than a reference to the control.
The following post by Ken Getz explains further.

Ken Getz
Feb 2 2000, 3:00 am

Newsgroups: comp.databases.ms-access
From: Ken Getz <[e-mail]>
Date: 2000/02/02
Subject: Re: Are Litwin, Getz and Gilbert not right?

Well, since I wrote that chunk, I'll respond here. No, I
wasn't "wrong", just unfortunate. Because what I didn't know when
writing that was that if you use expressions like
If Me.chkActive Then
in your code, you're leaving a reference open, and Access may not be
able to quit. The solution is to pass a VALUE, not a reference to the
If...Then statement, so there are several solutions:
* If (Me.chkActive) Then
* If Me.chkActive.Value Then (my personal favorite)
* If Me.chkActive = True Then (my personal least favorite)
They all do the same thing -- send a value to the If...Then statement,
so there's no reference to a control left dangling.
So, in theory, the advice in the book is right. Just in this one
instance, Access got in the way.
-- Ken

Wayne Gillespie
Gosford NSW Australia

[Beowulf]

I think Wayne meant to say:
If (Not IsNull(Me![customerid]) Or (Me![ChkStorehouse]=True)=True Or
(Me![ChkWareHouse]=True)=True)=True Then ...

Tom van Stiphout wrote:

On 17 Jan 2006 02:52:47 -0800, "solar" <sp*******@gmail.com> wrote:

I think Wayne meant to say:
If Not IsNull(Me![customerid]) Or Me![ChkStorehouse]=True or
Me![ChkWareHouse]=True Then ...

Also, make sure that in your table design, all Yes/No fields are
Required, and have a sensible default value (typically: False). A null
value in a Yes/No field rarely makes sense.

-Tom.

I want to perform a function called cancelorderonexit provided that
customerid is Null ,the Yes/No control ChkStorehouse is set to True or
the Yes/No field ChkWarehouse is set to True . Unfortunately the
function below does not obey me, and the code is performed even though
the ChkStorehouse is set to Yes
If Not IsNull(Me![customerid]) Or IsNull(Me![ChkStorehouse]) Then
CancelOrderOnExit
DoCmd.CancelEvent
End If

What is wrong ?

[Bob Quintal]

Beowulf <be*****************@hotmail.com> wrote in
news:Msszf.24141$he.19801@trnddc03:

I think Wayne meant to say:
If (Not IsNull(Me![customerid]) Or
(Me![ChkStorehouse]=True)=True Or
(Me![ChkWareHouse]=True)=True)=True Then ...

Thank you. I know they have Obtuse C coding contests. Do they have
them for Visual Basic?
This should submitted.

--
Bob Quintal

PA is y I've altered my email address.

[Beowulf]

Bob Quintal wrote:

Beowulf <be*****************@hotmail.com> wrote in
news:Msszf.24141$he.19801@trnddc03:

I think Wayne meant to say:
If (Not IsNull(Me![customerid]) Or
(Me![ChkStorehouse]=True)=True Or
(Me![ChkWareHouse]=True)=True)=True Then ...
Thank you. I know they have Obtuse C coding contests. Do they have
them for Visual Basic?

I've never heard of an obfuscated VB contest. It seems you may have
stumbled onto something. To be honest, though, there is a lot more
potential for unreadable, obfuscated code in C than in VB.
This should submitted.

You honor me much, but I would surely be bested by some joker who
just took it one step further:

If ((((Not IsNull(Me![customerid]))=True) Or
(((Me![ChkStorehouse]=True)=True)=True) Or
(((Me![ChkWareHouse]=True)=True)=True))=True Then ...

who'd be bested by some other joker ad infinitum.