Problem with Rich Textbox Control

[Neil]

I'm having problems with an implementation of the Microsoft Rich Textbox
Control 6.0 in an Access 2000 database. The form with the controls works
fine except on two computers. On these computers, the form will only open if
the MDB file is in an uncompiled state (implying that that computer has to
be the one to compile it). Otherwise, the form doesn't open, and the user
gets error 2501 ("The OpenForm action was canceled"). Furthermore, once the
form is opened, the rich text controls are read only, while the rest of the
form is read-write.

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

[Tony Toews [MVP]]

"Neil" <no****@nospam.netwrote:

>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 fileREGSVR32.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/

[Neil]

Thanks, Tony, I'll try that. I'm just getting the path and name of the
control from the Access References screen. Thanks.
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in message
news:a5********************************@4ax.com...

"Neil" <no****@nospam.netwrote:

>>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 fileREGSVR32.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/

[Neil]

Tony,

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]" <tt****@telusplanet.netwrote in message
news:a5********************************@4ax.com...

"Neil" <no****@nospam.netwrote:

>>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 fileREGSVR32.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]]

"Neil" <no****@nospam.netwrote:

>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.

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/

[Alex Dybenko]

Hi,
perhaps you copied newer version of control and did not register it, or some
setup program did this

--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
"Neil" <no****@nospam.netwrote in message
news:8p*****************@newssvr17.news.prodigy.ne t...

Tony,

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]" <tt****@telusplanet.netwrote in message
news:a5********************************@4ax.com...

>"Neil" <no****@nospam.netwrote:

>>>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 fileREGSVR32.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/

[Neil]

Would that explain how:

- 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" <al*****@PLEASE.cemi.NO.rssi.SPAM.ruwrote in message
news:u4**************@TK2MSFTNGP06.phx.gbl...

Hi,
perhaps you copied newer version of control and did not register it, or
some setup program did this

--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
"Neil" <no****@nospam.netwrote in message
news:8p*****************@newssvr17.news.prodigy.ne t...

>Tony,

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]" <tt****@telusplanet.netwrote in message
news:a5********************************@4ax.com.. .

>>"Neil" <no****@nospam.netwrote:

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 fileREGSVR32.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/