You may be missing  a referenced Project or Library. (Surprise!)
What you should do is check out Tools/References and see what Projects &
Libraries are checked, and most likely one of those is not present on
your users' machines.
It's a common issue, and one that does need to be corrected for your
form to work correctly.

I'm using one measly doodad from atpvbaen: Current Region
and I have to tell each user to go and install this library?...My next
question, then, is how do I build an install wizard so usability is
seamless? Is it possible to copy the routine for
ActiveCell.CurrentRegion.Rows.Count into my module or form  code?

This is, of course, is rational thinking--awaiting a portentous discovery...

ATPVBAEN - The MS Analysis TookPak for Excel.
Yes, that will have to be on each machine on which you want to use its
features. If that's not easy, and you're only using the one function
(CurrentRegion) you might try writing something to do the job of
CurrentRegion. I'm not sure if the source code for it is available.
MAYBE if you check out the ATPVBAEN.XLA file  from VBA, it's got complete
unlocked sourcecode, but I wouldn't count on it, but it's possible...! I
haven't checked into it.
There are many ways to install templates, I can't go into it right
now...

If you do a Google on ATPVBAEN you find  lots of info. Not sure if it's
helpful info, but one can dream... Also tries "ATPVBAEN source code".

One user opened Excel Tools > Add-Ins and checked the two addins, and still
got a failure (Can't find project  or library) when launching the .xls file  I
sent.

Would the following work for users  of a forms project I send for general use
(they have various versions of Office, which includes Excel):



Public Sub Auto_Open()
AddIns("Analysis ToolPak").Installed = True
AddIns("Analysis ToolPak - VBA").Installed = True
frmCorrectiveAction.Show
End Sub


Or is it also necessary for them to do something explicitly in VBA? (i.e.,
set up the Project Reference)...

Well, it's strange that if they were checked on the user's machine that
it didn't work.

The VBA code you listed may work, you should maybe check Word VBA Help
for more info on installing global template addins, I haven't looked
into it recently. Certainly, the XLA file  must exist on their machine at
a minimum...

If you look at the list of references (in VBA editor Tools >
References)...there's such a huge list. I have about 10 entries for VB. But
what I DID do was check some of those interesting things like MS Dev Env 7.0
and VB Data View Addin Support (which I had installed).

I learned a valuable lesson: someone somewhere will tell you when to enable
a reference, but until then, don't change any of those checkboxes in the
References dialog box.

I'll have to read up on this References topic.

The hard part is when someone sends you some code to help you solve your
problem, and it will not compile, then you have to figure out what
reference is missing, because the code works for them! <sigh> I usually
get caught up trying to determine if I need DAO or ADO references.

I discovered that it wasn't the analysis tool pak that caused the problem.
By debugging the project  on the user's machine, I find  it fails on:

datInitDate.Value = Format(Date, "mm-dd-yyyy")
datComplDate.Value = Format(Date + 90, "mm-dd-yyyy")

Format class (method?) works great on my machine, but not on user's--this is
apparently a VB 6.0 function, which explains why I couldn't find it in the
VBA Object Browser.

so now I'm back to:

datInitDate.Value = Date$
(displays as 01-06-2005)
datComplDate.Value = DateAdd("d", 90, datInitDate.Value) (displays
as 4/6/2005)

Which is what prompted me to try to find a cure (slashes vs dashes in 2
dates on same form)

I see a class VbDateTimeFormat listed in VBA Object Browser, but this method
provides 4 preconfigured selections (long, short, and the default general)
which don't seem to apply. Or do I wrap both dates in this and that will
"fix" the slash-n-dash issue.

Or is there a way to enable VB commands on users' machines?

What version of Office are you using? What Service Pack are you at, and
then what service pack level is your user at? I remember in Access that
Date() was not a supported function in the initial release, but then
Service Pack 1 fixed it. Databases that had worked fine in Office 97
using the Date() function stopped functioning in an Access 2000
database.

I'm using Office Standard 2003 with it's Sept 2003 svc pack; users  here have
a range of installations, but the problem arose in Office 2002...so that
must mean the most sophisticated version coming from my machine doesn't work
on anyone else's. I think it's the Format() function in VB that breaks. But
then I wonder how it's possible to build a "robust" solution in VB that DOES
work on users' workstations. (VB 6.0 was installed when I came to this
workstation, though I've only been working in VBA (or so I thought).

It's mind-boggling the Date() function(s) is so poorly
documented--obfuscation, laborious, conundrum--come to mind. I'd thought
dates (today's date plus some date 30 or 40 days, or a year later) on forms
to have been around since the advent of Excel. Seems even programming
languages that 'support' two contiguous versions of Office are more
exclusive than the spoken/written word across diverse cultures.

I just went digging through Excel XP and Excel uses Format as
FormatDateTime, which it looks as though Excel 2003 also recognizes. I
know I use Format in Access (both versions) all the time to accomplish
the code you are using, but try the FormatDateTime and see if that works
for you.