Better way to do this?

[zmbd]

Unbound form and two unbound text boxes:
z_ctrl_txt_HistoryLogVol
z_ctrl_txt_HistoryLogPage

The form is unbound as there must be validation steps performed against the other data entries and there is a "sign-off" PIN that the tech must enter to confirm that the information has been reviewed.

In the lab there are multiple logbooks,hence the LogVol,
and ofcourse, the pages therein, LogPage

It makes no sense to have either one or the other filled unless they are both filled (a volume without a page or a page without a volume... either way , useless).

So this is what I've been using to check to see if both are filled:

If (Me!z_ctrl_txt_HistoryLogVol & "" = "") Xor (Me!z_ctrl_txt_HistoryLogPage & "" = "") Then
'naughty naughty code here

This works like a charm and I've used this type of construct many times to check that numeric-label are set and so forth...

The question is, is there a better way?

[NeoPa]

So, you want to find when either one or the other, but not both, of the controls is Null?

I would say :

If IsNull(X) Xor IsNull(Y) Then
'etc.

Very much as you have it already. I can't think of a better concept, but I (personally) would make the checks us IsNull() instead of the other.

[zmbd]

I had originally started with just the isnull(); however, if a user enters a value in the control, tab's out, and then back into the control finally clears it (delete key) or enters just the spacebar then the isnull() doesn't catch this fact; however, this construct appears to catch this action.
Also, when I reset the form the value is reset to an empty-string and not a null value.

[NeoPa]

I'm surprised. Especially surprised that what you have would check for a space (" ") value. Maybe TextBox controls take the settings from the field and allow empty strings if the field does. That might at least explain why an empty control could have a ZLS value rather than the more usual Null.

[zmbd]

It's a funny report:

Customer Name
addresss
etc

report
Group header with sample id
"test1" "result" "Vol ___" "Pg 2013"
"test2" "result" "Vol 15" "Pg ____"

Where the underscors would be spaces or missing information; thus, one without the other is worse that useless... if the auditor comes in, we HAVE to be able to find the "wet work" as the original point of entry.

SO I had to test for Null, spaces, ZLS. The nasty is the, lets mess with Z and just hold the spacebar down. Finally solved that, so so so simple, no spaces are allowed! The Volume may be "VOL: ABA1" they may enter "ABA 1" and I just use the replace() to kill all spaces, then test as shown for Null and ZLS :) - that was one of those "duhhhh" moments too.

[NeoPa]

All makes sense Z.

If spaces and ZLS both possible entries, as well as Nulls, then I'd (personally) use :

Trim(Nz([X], ""))

A purely optional suggestion, of course.

[zmbd]

That's certainly a much better way of getting rid of the unallowed.

Now to test, if one is filled then both variation on a theme
by using the trim(NZ()) we would get:

if (trimedvol="") XOR (trimedpage="") then
'userfeedback for required entry
'set focus to missing entry

or is there a better logic?

[zmbd]

I just tried the Trim(NZ()), works ok with the leading and trailing spaces; however, doesn't account for those times when the user likes the spacebar inbetween ("AA________________123" where the underscore represents spaces")

So am I back to basically the same logic?

[NeoPa]

Would you ever want to 'account' for that scenario Z?
It seems to me that if an operator entered spaces within a word then that's what they intend to enter. It'll be a long time before code can psychicly determine what an operator intended to enter. Until that time, removing spaces from the middle of an entry is fundamentally illogical.

As for your basic logic. I believe you had that right from the get-go. I was never going to improve on that.

[zmbd]

Ahhh, here's the logic: By SOP, the nomenclature of the logbook volume names is to be alphanumeric only without the use of spaces, periods, dashes, underscore, or other forms of puncuation. Furthermorre, that upper and lowercase will be treated the same. Thus, when the user enters a space, the space violates the SOP/business rules. Ofcourse, with page numbers, it wouldn't make sense (in the US) to have page thirty enterd as "3_0" or page 100 enterd as "1_0_0_" which we had one tech that would do that just to see if the program would crash!

[NeoPa]

Ahh. That also changes the thrust of the question somewhat ;-)

In that case though, where you want to ensure there are no embedded spaces, as well as no upper-case alphas, I would use :

Dim strX As String, strY As String
 
strX = LCase(Replace(Nz([X], ""), " ", ""))
If strX > "" Then [X] = strX
strY = LCase(Replace(Nz([Y], ""), " ", ""))
If strY > "" Then [Y] = strY
If (strX = "") Xor (strY = "") Then ...

[zmbd]

Very good and actully very close to what I have in use. I use the UCASE as we've found this easier to read; however, lowercase is allowed. I have other validations too such as no letters "i" and "o" as they can look like the numbers one and zero depending on the font etc...

Thank you for letting bounce this off the forum. Not being a professional programmer it's nice to be able to double check my logic!!!!!

-z

[NeoPa]

Any time :-)

Frankly, for you, you could call me any time if that could help.