I haven't seen this exact issue posted here, but apologize if this has been replied to previously.
The company I work for uses the MS DHTML edit control as our primary editor in our software product. Since the release of this hotfix, we have only developed one solution, which is to remove the update, then try to coerce our customer's corporate IT people to hold off deploying it.
We did a little research with the DHTML edit control, and it would appear that many of the interfaces it exports return NULL pointers, specifically any interface which would return a reference to the DOM document. We access the object through the OCX, in a Delphi application, so perhaps there is a solution available to a C++ developer that we don't currently have available.
I know of a handful of other applications that are similarly broken, is there documentation available on a new method of using the control(s)? Is there a way to instantiate it that is 'safe' such that we can again access the DOM object? Running it in our application on the local machine doesn't seem like it should relate to 'cross site scripting' which is what was apparently resolved...
You are not the only one. There are a huge number of products that now do not work as a result of KB891781 being installed. We have had to resort to uninstalling the patch before our application starts using the following call:
The vendor of the DHTML editing control I use in Delphi (Profgrid) has told us that Microsoft eliminated documented interfaces in this control throught that patch. I believe that this problem will become significantly larger in the days ahead as people begin to apply the windows patches and realize that some of their applications do not work.
> I haven't seen this exact issue posted here, but apologize if this has > been replied to previously.
> The company I work for uses the MS DHTML edit control as our primary > editor in our software product. Since the release of this hotfix, we > have only developed one solution, which is to remove the update, then > try to coerce our customer's corporate IT people to hold off deploying > it.
> We did a little research with the DHTML edit control, and it would > appear that many of the interfaces it exports return NULL pointers, > specifically any interface which would return a reference to the DOM > document. We access the object through the OCX, in a Delphi > application, so perhaps there is a solution available to a C++ > developer that we don't currently have available.
> I know of a handful of other applications that are similarly broken, > is there documentation available on a new method of using the > control(s)? Is there a way to instantiate it that is 'safe' such that > we can again access the DOM object? Running it in our application on > the local machine doesn't seem like it should relate to 'cross site > scripting' which is what was apparently resolved...
On Tue, 15 Feb 2005 08:53:16 -0500, "David Alison"
<no_spam_drali...@hotmail.com> wrote: >The vendor of the DHTML editing control I use in Delphi (Profgrid) has told >us that Microsoft eliminated documented interfaces in this control throught >that patch. I believe that this problem will become significantly larger in >the days ahead as people begin to apply the windows patches and realize that >some of their applications do not work.
Hello David,
We use dhtml:Dom to get the text value and the content of a selection and have the problems too. I believe there must be other ways to accomplish this, as I find only a very limited of complaints about this patch. The Profgrid forum for example, where you are refering to, does not have a single entry about this.
Does anybody have an alternative way to get this info without violating MS patch?
D.J.W. van Kooten wrote: > On Tue, 15 Feb 2005 08:53:16 -0500, "David Alison" > <no_spam_drali...@hotmail.com> wrote:
> >The vendor of the DHTML editing control I use in Delphi (Profgrid) has told > >us that Microsoft eliminated documented interfaces in this control throught > >that patch. I believe that this problem will become significantly larger in > >the days ahead as people begin to apply the windows patches and realize that > >some of their applications do not work.
> Hello David,
> We use dhtml:Dom to get the text value and the content of a selection > and have the problems too. I believe there must be other ways to > accomplish this, as I find only a very limited of complaints about > this patch. The Profgrid forum for example, where you are refering to, > does not have a single entry about this.
> Does anybody have an alternative way to get this info without > violating MS patch?
> Dick
Dick, you should check back to the Profgrid forum... There is lots of info about this problem and even a (good) temporary solution posted 2-17 by Olaf.
I've also got this problem, and have done a quick test with some new apps. Delphi doesn't work, but VB does. Coincidence? They can't have just pulled the interfaces because it still works fine in VB. What would VB doing differently?
Hi, All! I got the problem like this in my C++ code. But my problem is incorrect use of IPersistStream. Microsoft guys changed the internal format of the dhtmledit control description (persist stream content) that used for store/restore object state. So, if you object calls internal interfaces it may be a problem.
> I haven't seen this exact issue posted here, but apologize if this has > been replied to previously.
> The company I work for uses the MS DHTML edit control as our primary > editor in our software product. Since the release of this hotfix, we > have only developed one solution, which is to remove the update, then > try to coerce our customer's corporate IT people to hold off deploying > it.
> We did a little research with the DHTML edit control, and it would > appear that many of the interfaces it exports return NULL pointers, > specifically any interface which would return a reference to the DOM > document. We access the object through the OCX, in a Delphi > application, so perhaps there is a solution available to a C++ > developer that we don't currently have available.
> I know of a handful of other applications that are similarly broken, > is there documentation available on a new method of using the > control(s)? Is there a way to instantiate it that is 'safe' such that > we can again access the DOM object? Running it in our application on > the local machine doesn't seem like it should relate to 'cross site > scripting' which is what was apparently resolved...
> The vendor of the DHTML editing control I use in Delphi (Profgrid) has told > us that Microsoft eliminated documented interfaces in this control throught > that patch. I believe that this problem will become significantly larger in > the days ahead as people begin to apply the windows patches and realize that > some of their applications do not work.
"We too" - they stopped our entiere application with this :-/
> Microsoft needs to address this ASAP.
Definitly. Additionally they should release a developer notice to the public instead letting them alone in the rain...
> I've also got this problem, and have done a quick test with some new apps. > Delphi doesn't work, but VB does. Coincidence? They can't have just pulled > the interfaces because it still works fine in VB. What would VB doing > differently?
> VB breaks just as easy if you do something as simple as this: > oDOM = oDHTML.DOM ' will fail on this line
> I am still looking for a solution.
> Regards,
> Willie
> "j.edwards" <j.edwards__NOSPAM__._._...@sagetechnology.com.au> wrote in > message news:42197c96$0$79233$c30e37c6@lon-reader.news.telstra.net... > > I've also got this problem, and have done a quick test with some new apps. > > Delphi doesn't work, but VB does. Coincidence? They can't have just pulled > > the interfaces because it still works fine in VB. What would VB doing > > differently?
The set give the same thing. Microsoft made some major changes to DOM access with K891781. My sample is just a snippet to show the issue. To see the issue, create a new project, add DHTML in as a reference. Add a single command button and paste the code below. You should get error message: Run-time error -214748113 (8000ffff) method DOM of object iDhtmlEdit failed
Regards,
Willie
Private Sub Command1_Click() Dim oDHTML As New DHTMLEdit Dim oDOM As Object Set oDOM = oDHTML.DOM End Sub
"Rohan Reddy" <grohanre...@hotmail.com> wrote in message
>> VB breaks just as easy if you do something as simple as this: >> oDOM = oDHTML.DOM ' will fail on this line
>> I am still looking for a solution.
>> Regards,
>> Willie
>> "j.edwards" <j.edwards__NOSPAM__._._...@sagetechnology.com.au> wrote in >> message news:42197c96$0$79233$c30e37c6@lon-reader.news.telstra.net... >> > I've also got this problem, and have done a quick test with some new > apps. >> > Delphi doesn't work, but VB does. Coincidence? They can't have just > pulled >> > the interfaces because it still works fine in VB. What would VB doing >> > differently?
