Mailing List issues...

[duncs]

I'm having trouble wrapping my head around the following (I have this problem alot!!)

I am creating a mailing list database. There are fields for address, and email address, among others. I have created 3 radio buttons, all with yes/no values. The button are to indicate "send by mail", "send by email", "never send".

My trouble is, I want my users to only be able to select one of the 3, so that if they set one to "yes", it automatically re-sets the others to "no". At the same time, it needs to confirm that the address field is not empty if the user selects "send by mail" or the email address is not empty if the user selects.. you guessed it.. "send by email" and pervents the entry if the aforementioned is untrue.

Any help would be greatly appreciated, and be gentle, I'm no expert!!

Thanks

[LaRetta]

Hi Handel,

I suggest that you use ONE field instead of three. You would create a Custom value list called Send Via with:

Send by eMail

Send by Mail

Don't Send

Then your one text field called SendVia could have validation by calculation with:

IsEmpty ( SendVia ) or

not IsEmpty ( email ) and SendVia = "Send by eMail" or

not IsEmpty ( address ) and SendVia = "Send by Mail" or

SendVia = "Don't Send"

You would place SendVia field on your layout and format as radio button based upon the Send Via value list. This will stop selecting more than one option. The validation, if it fails, will fire after the User leaves the field. You can set the validation to 'Always validate' by unchecking in the calc dialog at the bottom. Also, at the top of the Validation tab, uncheck 'Allow User Override' and check 'Always'. You can add a validation message at the bottom describing your required rules of selection. In this way, a new record won't fire the validation failure but once a User makes a selection in SendVia, they must either fill in the eMail, fill in the address or change it to Don't Send. If you have further questions, just ask ... there are many wonderful people here willing to walk you through it.

Note: You didn't clarify whether the field should ever be allowed to be left empty. If not, remove the IsEmpty () line from the validation calculation. You can also pre-fill the field if you wish with 'Don't Send'. There are a few different tweaks you can apply, depending upon your wishes.

LaRetta :wink2:

Edited March 21, 2007 by Guest
Added Note

[duncs]

Thanks so much, that seems to do the trick! I'm always pleasently surprised at how easy it seems for other people to answer things I have been struggling over for hours!!

Thanks again

[T-Square]

LaRetta--

Well said. I had most of the same thing in a reply, but stopped because I wasn't at a machine where I could put together the validation part (and I recalled being reminded recently that testing things out before offering them up was wise... ).

As for the problem at hand, I would set the field up as a numeric field with text displays (0 - Don't send, 1 - Snail, 2 - Email), and have it default to 0. But that's just the old school in me wanting to use numbers instead of text...

Cheers,

David

[LaRetta]

Hey David! There is nothing old-school about wanting lean. I considered it but I chose not to suggest it because: 1) I didn't know if there were scripts or other procedures already in place using existing values and Handel rates himself as beginner and it would probably mean changing existing data, 2) with hard-drive size and system speeds, the savings might not off-set the cost of 3) the confusion of remembering which number means which.

"Hmmm, was a 2 the Send eMail or was it Send Mail?" I have probably 15 such fields in this current solution. I've had to stop data manipulation while I open the field definition (where I've commented which number is which). Or I end up creating a calculation using Choose() to convert them for displaying the description anyway. All in all, using numbers (particularly for portal filters and sweet relationships) and for ANYTHING which is Developer focused, is the best way to go. But I don’t think all value lists should be turned into numbers.

If the value list is boolean (yes/no on-off switch) then certainly, because we can display the text via boolean number format (if less than 8 letters). Something IS or it ISN'T. I hope FM lengthens this option because it would increase its usability tremendously; even if only by a few characters. But as the number of entries increases in a value list or new entries are added (always happens), keeping the numbers straight isn’t easy. Using a table to hold the number and description can come in handy as well.

I love it how things come back around. I posted behind JT (-queue-) a few years back on this very issue; how using numbers would be more efficient. He explained this to me much better than I’m doing now but, as Comment has demonstrated time and again, clarity can be worth an extra evaluation.

I'm always pleasently surprised at how easy it seems for other people to answer things I have been struggling over for hours!!

It is only because we have already put in the blood-sweat for the answers; it has nothing to do with intelligence. FM Forums is powerful because we all share our experience with each other and I, daily, feel the same way when others share their experience with me. I'm pleased that my suggestion was helpful.

LaRetta

[comment]

It is only because we have already put in the blood-sweat for the answers; it has nothing to do with intelligence.

Hey, speak for yourself!

:bigshades:

[LaRetta]

:blush2: Present company excluded, of course ... :beer: