Van Kichline's WebLog : DHTML Editing Control

DHTML Editing Control for Applications (Windows Vista Version) Installer Update

vank — Tue, 26 Sep 2006 00:09:00 GMT

A while back I posted that there were some minor problems with the DHTML Editor Control for Windows Vista (which we've finally abbreviated as DECA-V internally.) We've corrected these and updated the download in-place.

The changes include:

Full UI sequence for Administrative Install
Administrative Install will run on any NT system. Package install will only run on Windows Vista or later systems.
Full Windows Vista Logo compliance

It's not much, but if it's what you need, it's tested and available now.
Since the file name is the same, if you've downloaded DhtmlEd.msi before you should clear your cache to ensure that you get the newest version. You can verify that you have the correct version by displaying the MSI's properties, clicking on the "Digital Signatures" tab, and verifying that the file was signed on September 18, 2006.

Minor problems with the DHTML Editing Control for Applications installer

vank — Sun, 10 Sep 2006 03:48:00 GMT

A helpful customer contacted us with some concerns about the installer for the Windows Vista version of the DHTML Editing Control for Applications.
While I had run the ICE verification for Logo Compliance in Orca (the MSI inspector/editor) I had failed to upgrade to the Windows Vista version of Orca first. As a result, we missed the fact that some UI elements in the AdminUISequence which were required for Windows Vista Logo Compliance were missing.
This was easily fixed, but I spotted another problem while working on this; the launch condition which required Windows Vista in order to run the installer applied the administrative install as well as the ordinary install. Administrative installs don't actually install the product on a computer; they deploy an installable image to a network location. There's no reason to require an administrator to be running Windows Vista just to deploy an administrative image, so this is being corrected as well. The user installing from the administrative image will still need to be running Windows Vista, of course.
This installer modification is in testing now and will be released soon. The binaries installed by it are unchanged. If you have any questions, contact me or post a comment.

Straight to Video

vank — Thu, 17 Mar 2005 21:50:00 GMT

(More history of the DHTML Editing Control)

Once the thrill of packaging up some cool technology and releasing it to the public gave way to the gruesome reality of servicing an operation system component, the youthful bloom was off the DHTML Editing Control. Feature enhancements were not to be approved. I think we had one very minor added feature (although I don't remember what it was) as we moved from private distribution to OS distribution. Bug fixes did continue, however.

Jeff took over as Program Manager and did a good job of keeping up the community effort. I remember having an online conference once with quite a few attendees, and he was a prolific communicator. Expanding usage turned up a few functional bugs, mostly related to Far Eastern scripts, which we got taken care of--I believe by the time IE 5.0 shipped.

Our team got to work on Visual Studio 7 and I remember missing almost the entire first milestone because of work on the control. It got pretty disconcerting, because I had a few features I wanted to get to work on; frameset editing and absolute positioning. We finally got through our bug list and shipped a functionally solid version of the control. I wish I had the exact version number, but I purged most of my email some time ago. I shifted focus to Visual Studio, we lost Jeff, and focus shifted off the control.

One internal partner that adopted the control and kept us well aware of any problems which came up during OS upgrades and patches was the OWA team (Outlook Web Access.) Their test automation was extensive and well crafted; a few problems did crop up as IE tightened security and we had to make tandem changes in the control. We got a lot of great input fro their QA team and we owe them a lot. Thanks, ya'll! OWA rocks.

Getting it for Free

vank — Wed, 16 Mar 2005 22:55:00 GMT

Everything was going great back in 1997. I'd come into the VID project late and was finally about to ship my first product at Microsoft after earning a few "skip its" in the graphics division. (An imaginary award you get for having your project cancelled. Like a "ship it" but completely different.) I'd added a few DTCs (Design Time Controls) to VID (do you remember the Sequencer?) and was working on this pretty cool HTML Designer control. Then a funny thing happened.

I walked into Steve's office, the PM who had driven the creation of the control, a couple minutes late for a meeting. He was just winding up an excited exposition on the whiteboard, saying "...and then we can mark the control Safe for Scripting, and we get it for FREE." The idea was to add a second control to the OCX which eliminated a couple of methods, such as Save and BrowseMode, and then people could use the editing features in a web app as well as a client app.
I whined. I didn't think that Safe for Scripting really came for free. I thought there might be security risks that we hadn't considered. But I was challenged to be specific, to identify an actual problem, and I couldn't.

It turned out over the years that I was smarter than I could have ever imagined, but that's a rather small comfort. We made the dual control and released it to the web. I've got a copy of the release CD right here. We just moved offices and I found it while unpacking. The build date was March 27, 1998. We got the control posted to the ActiveX Toolbox so that it could be automatically downloaded via a codeBase attribute in an OBJECT tag. IE 4.01 was on the disk

Remember when IE used to change fast? And at this point IE revisions required DHTML Editing Control revisions as well. After a couple of revs our codeBase installation system began to get complex. It got so complex that there was a full time contractor on it, Yuri, and I remember one meeting where there were about 15 of us in a room for over an hour discussing installation issues. At the end of the meeting even Steve agreed that "free" wasn't the best way to describe the Safe for Scripting aspect of the control.

Then we did a smart thing. We met with the IE team (I don't remember who was involved on their end) and explained that we couldn't continue to maintain separate, compatible builds of the control and its nightmarishly complicated installer. We talked them into our moving the source to their code tree and shipping revisions of the control with revisions of IE. This way it would always be installed and would always be compatible, and we could eliminate our setup efforts completely. We (the Developer Tools Division at the time) agreed to maintain the code while they would maintain the build. I'm not sure exactly when this agreement went into force, but this is still the arrangement today.

I have to tell this story over again every single time I go to a Windows War meeting to get approval for checking in a bug fix. Now, at last, I can just provide a URL.

Anatomy of DHTMLEd

vank — Wed, 16 Mar 2005 21:37:00 GMT

The DHTML Editing Component is three things in two packages:

TriEdit.dll is installed in \Program Files\Common Files\Microsoft Shared\Triedit\. It implements an IOleDocument which aggregates Trident, the document object displayed by Internet Explorer. I don't know of anyone CoCreating ITriEditDocument directly. If you have, let me know and I'll send you a token of my respect.
DhtmlEd.ocx is co-located with triedit.dll and implements two ActiveX controls:

The Safe-for-Scripting version of the DHTML Editing Control, DHTMLSafe, which is useful when hosted in an HTML page.
The Unsafe version of the control, DHTMLEdit, which is useful in client apps build in VB, etc.

Technically, there are also a couple of other helper objects wrapped up in the package which are used as parameters for methods of the DHTML Editing Controls; a DEInsertTablePram and a DEGetBlockFmtNamesParam.

TriEdit.dll was developed for VID and was used extensively by the HTML Designer. The control was developed initially by a contractor and handed off to me for completion and shipping (80% done, 80% to go, you know.) The idea was to bring the nice HTML designer features of VID to Visual Basic in a nicely packaged control.

Change of Topic

vank — Wed, 16 Mar 2005 21:12:00 GMT

Well, it's been a long time since September.
I've decided to learn from my inaction; while I work hard on perf, I'm still in the learning curve and I don't particularly enjoy blogging about what I don't know.
So, I'll change the subject.

Back about seven years ago, we released a control called the DHTML Editing Control; dhtmled.ocx. It was a simple ActiveX control hosting Trident, the IE rendering engine, plus TriEdit, which implemented most of the designer features released in Visual InterDev (remember VID?) such as Table Editing and Source Code Preservation. There's some interesting history and a few good stories associated with the life of this component which I'll post under this topic.

We recently came to realize that we are not in touch with the community of our users. I'm interested in rectifying that. Let's begin.