RichTextBox Disappears from Form

[jeisch]

I'm new to VB, and heve been asked to support an existing application. Two of our users has been using the application, then they started getting a compile error. They are using VBA 6.3. The error occurred when trying to refer to a RichTextBox that was supposed to be on a form, but the box is no longer on the form. I've replaced the application, but the box just disappears. This only happens on two out 30 PCs, and all should have the same image. I've verified that Richtx32.ocx is in the windows\system32 directory, is there anything else I can look at that might be causing this problem?

 

[tedsmith]

Some controls dont work if there is a different version of the OCX when the application was compiled is in Windows/System32.
EG. The RichTextBox that comes with W2000 is different to that in WIndows98.

This is very evident with the various versions of Shockwave Flash OCX as ther3e seems to be a new one each year.

This can happen of you just copy the exe file instead of using the a full applicatiom install package when updating the exe.

You either have to load VB6 in the offending computer and complien the exe again on that, or make all versions of the OCX the same in all computers.

Someone might have installed an old VB5 app on the offending machine and changed it Richtextbox OCX or DLL or whatever back to an older version.

Check the RichtextBoxs in System32 are all the same size.

 

[strongm]

>VBA 6.3

So we are talking about VBA rather than VB ... OK, this is probably caused - would you believe - by Internet Explorer security.

Basically the RTB is not trusted as safe by IE (the control itself is erroneously marked as safe but IE is configured not to believe it). Later service packs of Forms2 (also known as the Microsoft Office Forms Library, i.e VBA's userforms) check with IE on whether they are allowed load and run a control. The policy for the RTB is to NOT load or run it, because the 'killbit' is set in the registry. This killbit setting is not accessible through the IE interface, so there are two primary workarounds

1) Use genuine VB6 to wrap the RTB in a usercontrol which you can mark as safe

2) Edit the relevant killbit setting in the registry (normal warnings about modifying the registry apply):
[tt]HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{3B7C8860-D78F-101B-B9B5-04021C009402}[/tt]
and change the 'Compatibility Flags' value from 0x400 to 0

 

[strongm]

Oh - I've just noticed the original posting date. Guesss I might have been abit late with a possible solution.

 

[jeisch]

Thanks! Changing the registry setting fixed it. Does this registry setting have an impact on anything else I need to be aware of?

 

[tedsmith]

Might this mean that you have less protection from a future activeX that was malicious?

 

[strongm]

Microsoft consider the RTB to be a security risk since it allows for the embedding of potentially malicious OLE objects (and the Load and Save methods technically make it unsafe for scripting). So, yes, you expose yourself to this potential risk by making this registry change. But only an RTB attack, not to any other ActiveX (3B7C8860-D78F-101B-B9B5-04021C009402 is the CLSID for the RTB control, and that's the only thing we are modifying the killbit for)

Note that the usercontrol wrapper technique also exposes you to this risk unless you write code to check that no malicious OLE objects are being embedded - which assumes that you actually know how to recognise all the malicious OLE objects ...