I've checked the versions of Windows, Access, Jet, etc., on all computers,
and they're all identical. Also, the version of the rich text control
(6.1.97.82) is identical on all computers. Yet this problem only exists on
two computers, and on all others it works fine.
So, are there any other files besides richtx32.ocx that are associated with
the rich textbox control? Maybe those two computers are missing an essential
file or something?
Any ideas are appreciated. Thanks!
Neil
>So, are there any other files besides richtx32.ocx that are associated with
>the rich textbox control?
Just guessing. Try registering that OCX on those systems.
An easy way to register a file is to search for both files at one time
(<insert name of your file> REGSVR32.EXE) then drag and drop the
OCX/DLL onto the EXE. As most relevant DLLs and OCXs reside in
c:\<your windows version>\system32 you can try in this directory first
to minimize searching time. If that doesn't find both then go up a
directory level to c:\<your windows version>.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:a570a392022omfg95...@4ax.com...
Well, that did the trick! I should have tried that right off the bat. The
interesting thing was that doing a decompile seemed to address the issue. So
I assumed there was some sort of corruption in the file. But then it
wouldn't work in a compiled state. So it's interesting how, even with the
control not being registered, it still worked halfway (form was able to be
opened, and controls displayed data, but controls couldn't write data) if
the MDB was in an uncompiled state when the user opened it. So Access was
able to work with the control "a little" if the control wasn't registered,
but it couldn't go all the way. Interesting.
Thanks for your help.
Neil
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:a570a392022omfg95...@4ax.com...
>Well, that did the trick!
Glad to read it.
>I should have tried that right off the bat. The
>interesting thing was that doing a decompile seemed to address the issue. So
>I assumed there was some sort of corruption in the file. But then it
>wouldn't work in a compiled state. So it's interesting how, even with the
>control not being registered, it still worked halfway (form was able to be
>opened, and controls displayed data, but controls couldn't write data) if
>the MDB was in an uncompiled state when the user opened it. So Access was
>able to work with the control "a little" if the control wasn't registered,
>but it couldn't go all the way. Interesting.
That is interesting. I have no good explanation as to that behavior.
--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
"Neil" <nos...@nospam.net> wrote in message
news:8p5oi.3210$Dx2....@newssvr17.news.prodigy.net...
- the form would not open if the MDB was compiled, but would open if it was
uncompiled;
- in either case, the control would display data, but not allow data to be
modified?
This is all very perplexing.
Thanks.
"Alex Dybenko" <ale...@PLEASE.cemi.NO.rssi.SPAM.ru> wrote in message
news:u4Qyop2y...@TK2MSFTNGP06.phx.gbl...