AutoCorrect/AutoExpand

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Access XP application. Using Access XP Runtime on Windows 2003 to test
application remotely, and AutoExpand does not work on my one numeric combo
box. It works fine for all combo boxes that are text and on my Access XP /
Windows XP Pro workstation even for the numeric field.

Also, (on the Win2003 server) if I type a valid entry, I get the "Item not
on list", yet I can click that exact item, and it works.

Also found I had to go from using Date() to using Now() to avoid errors on
Win2003 server (when setting date control to today's date ). Why?
 
The Date/Now issue is likely caused by a problem with the References
collection. One (or more) of the files pointed to by your References
collection is either a different version or in a different location on the
Win2003 server than on the machine where the application was created (or, in
fact, it could be missing completely). I discuss one way to correct such
problems at
http://members.rogers.com/douglas.j.steele/AccessReferenceErrors.html

No idea about the AutoExpand problem, although I suppose it could be related
to the References problem.
 
Thanks. There is one thing in your article I want to clarify: when
distributing from Windows XP to Windows 2000, do I need to create a
Windows\system32 directory and place a copy of the referenced files there, or
can I just put them in existing WinNT\system32? Does the default search/path
in Windows take care of finding them?

I distribute updates to this particular application to users that are using
Access XP runtime & to one who is using Office 2003 Pro. Things run fine for
most of the Windows 2000 / Access XP runtime clients, but what if Office 2003
or Windows 2003 has a newer version of a reference file? It can run XP
applications, but seems to have a reference problem with OWC10/11.

I haven't yet had time to study your article in depth, so if these are
answered there, don't bother re-answering here.
 
I think (although I don't know for certain) that Access is able to handle
the Windows\System32 vs. WinNT\System32 situation.

Unfortunately, there's no easy answer for your second question: it all
depends on the specific reference. If the versions comply to binary
compatibility, they should be okay. but even that's not always a guarantee.
 
I resolved the issue with the numeric field by changing it to text. Access
does not now have to convert it text to do the AutoExpand. The root problem,
however, wasprobably related the next fix below also, though.

Although my clients all had Access 2002 runtime or Office 2003, I had been
distributing the .mdb in Access 2000 format. When I converted the .mdb to
2002 & distributed it, all fields having a default value of Date() or Time()
showed up as "#Name?" (for the clients only, of course, not for me, so I was
unaware the issue would arise).

It turns out that when I converted the .mdb from 2000 to XP, Access
automatically added the OWC10 (Web Components) reference. Even after copying
the same version of OWC10.dll to the client, the problem persisted. However,
when I manually removed that reference from the application the Date, Time, &
Format all work correctly.

It also turns out that the comdlg.ocx reference now works correctly with the
OWC10 reference removed. So, now I can get back to programming, I guess...
 
Followup to my prior post. Problem half solved: I still have the
Date()/Time() issue for those clients running Outlook 2003. I got it resolved
for those two that were running the Access runtime on machines that do not
have Outlook 2003. The problem still exists on the Windows 2003 server & an
XP Pro workation that has Outlook 2003 (as Exchange client) & Access XP
runtime.

I went through the references in detail. Everything matches, including
versions. Is it possible that there is a new version of a system file that is
used for these functions but is not listed as a reference in Access because
it is a common Windows file?
 
Hard to say without knowing exactly what references you're using.

In a previous post, you mentioned the common dialog control. That's
notorious for causing versioning problems. Assuming you're only using it for
the Windows File Open/File Save dialog, dump it in favour of making direct
API calls. There's a complete sample at
http://www.mvps.org/access/api/api0001.htm at "The Access Web"

For situations such as some clients have Outlook 2003 and others not (or
having a different version of Outlook), you're probably best off using Late
Binding. In that way, you don't set a reference, so you can't have a
References problem. (You do, of course, have to check that the user has the
application installed before you can attempt to use it!) Tony Toews has a
good introduction to the topic at
http://www.granite.ab.ca/access/latebinding.htm
 
I will read up on late binding. In the meantime, I tried to duplicate the
problem on my development machine by removing references one at a time. I
started with:

VBA (vbe6.dll)
Access object library (msacc.olb)
OLE automation (stdole2.tlb)
Common dialog control (comdlg32.ocx)
Active X data objects 2.5 (msado25.tlb)
DAO 3.6 (dao360.dll)

I stripped it down to the bare minimum (just the first two, VBA & Access
object library, which are required even to open Access/VBA) but still cannot
duplicate the problem (versions are the same as on target machines), so am I
safe in assuming that it is some other common system file that is used by
Access but is not referenced directly? If this is the case, will late binding
resolve the problem?
 
Sorry, I don't understand what you mean that you tried to duplicate the
problem by removing references.

I really doubt that your problem is caused by some other system file.
 
Here is a synopsis of where I have gone with this issue thus far:

1. The file versions & locations of all references are identical on my
development machine & on the target machines.

2. When I set the default value of a control to Date() or Time(), the target
machine displays "#Name?", but the development machine correctly displays
today's date.

3. I thought that perhaps I might be able to eventually duplicate the
problem at my development machine (cause the Date() function to display
"#Name?") if I removed the references one by one from a copy of my
application, on the assumption that if the problem was reference-related, the
Date function would no longer work on my development machine after I removed
the reference upon which it is dependent.

4. I eventually removed ALL references except VBA & Access 10 object library
(both of which I could not remove, for obvious reasons) on the development
machine, re-compiled, restarted my application, and the Date() function still
worked fine (again, on the development machine).

Pardon my relative ignorance of references in the overall programming
scheme. Is not this an indication that the Date() function is dependent on
something other than one of the references I removed and thus the reference
is not likely the culprit in causing the function to fail on the target
machines?
 
Never mind my interim blather. I just don't understand references very well
yet. Despite my unsuccessful testing with references removed, the problem
disappeared when I replaced the Common Dialog (as you said in about post #2
above) with the API call. Sorry for the bother & thanks for the help.
 
Just to close the loop, while the Date function is located in a specific
reference, its failure to work seldom is indicative of a problem with that
reference. References are like apples: one bad one can spoil the whole
bunch. What happens is that Access looks through the references until it
finds the function it needs. If there's a problem with one of the
references, Access may be unable to be able to find the function, and you
get an error.
 
Back
Top