Click here to Skip to main content
Click here to Skip to main content

Using IHTMLEditDesigner

By , 24 Apr 2004
 

Introduction

My current project requires the ability to do WYSIWYG HTML editing. A quick look at the MFC class heirarchy revealed CHtmlEditView. An even quicker session with the MFC AppWizard and I had an SDI WYSIWYG HTML editor up and running, using the MSHTML COM object that ships as part of Internet Explorer.

My application, however, doesn't create arbitrary web pages. To create a new page you select a template HTML file and alter existing content. It was important that the layout of the page remain substantially unaltered. This meant that, for example, it should be possible to replace a placeholder image with a real image, resize it to fit the allotted space but not be able to drag the image to a different location on the page.

Solving this little problem turned out to be quite an interesting exercise.

Background

I used CHtmlEditView, one of the new classes introduced in MFC 7. It's a CHtmlView derived class and one of the very very few MFC classes that uses multiple inheritance. It's derived from both the CHtmlView and the CHtmlEditCtrlBase classes. The view inheritance lets it be used in document/view applications. The CHtmlEditCtrlBase adds a whole bunch of capabilities related specifically to HTML editing.

We're not really going to be discussing either of those base classes. However, the CHtmlView class contains a CWnd member which becomes the MSHTML COM object hosted within the class, and a pointer to an IWebBrowser2 COM interface. That interface, in turn, contains methods to navigate to new pages, refresh the current page and so on. We're not interested, for the purpose of this article, in that interface because it's primarly oriented toward browsing.

MSHTML

This is the COM object hiding behind Microsoft Internet Explorer. Internet Explorer itself is little more than a wrapper around MSHTML. This is actually pretty cool from our perspective because it means that our software can host MSHTML and obtain, almost for free, HTML display and editing capabilities. MSHTML includes a complete WYSIWYG HTML editor. All we have to do is host the MSHTML object and provide a user interface. All?

Well there's the little matter of understanding the Document Object Model (DOM) and making sense of a couple of hundred COM interfaces.

I don't intend to exhaustively discuss either the DOM or the many COM interfaces. This article is focussed on demonstrating how to modify the editors behaviour.

Edit Designers

As Internet Explorer evolves so too does MSHTML evolve, providing us with more and more ways to interrogate and control HTML display. Version 5.5 introduced Edit Designers and the IHTMLEditDesigner interface. This interface is essentially a collection of 4 callbacks which MSHTML makes to code we control. Each callback handles MSHTML editing events at various points in the lifetime of the event. The lifetime points are.
  • PreHandleEvent
  • PostHandleEvent
  • TranslateAccelerator
  • PostEditorEventNotify
Of these callbacks PreHandleEvent() is probably the most useful. MSHTML calls into our code to notify us that it's about to do something and we have the chance to modify that behaviour or to cancel it entirely.

So, inspired by what you've read so far, you eagerly fire up your copy of VS .NET, go to the help index and type in IHTMLEditDesigner. You read the description of the PreHandleEvent() method and see that the prototype for the method is.

HRESULT PreHandleEvent(DISPID inEvtDispId, IHTMLEventObj *pIEventObj);
And the comments say this:

'The DISPID parameter provides the most efficient way for an IHTMLEditDesigner method to determine what type of event triggered the method call. The DISPID_HTMLELEMENTEVENTS2 identifiers are defined in Mshtmdid.h.' (Direct quote from MSDN help in VS .NET 2003).

Aha! Let's go and look at the DISPID_HTMLELEMENTEVENTS2 constants. Here's a short selection.

#define DISPID_HTMLELEMENTEVENTS2_ONMOUSEMOVE  DISPID_EVMETH_ONMOUSEMOVE
#define DISPID_HTMLELEMENTEVENTS2_ONMOUSEDOWN  DISPID_EVMETH_ONMOUSEDOWN
#define DISPID_HTMLELEMENTEVENTS2_ONMOUSEUP    DISPID_EVMETH_ONMOUSEUP
#define DISPID_HTMLELEMENTEVENTS2_ONBLUR       DISPID_EVMETH_ONBLUR
#define DISPID_HTMLELEMENTEVENTS2_ONRESIZE     DISPID_EVMETH_ONRESIZE
#define DISPID_HTMLELEMENTEVENTS2_ONDRAG       DISPID_EVMETH_ONDRAG
#define DISPID_HTMLELEMENTEVENTS2_ONDRAGEND    DISPID_EVMETH_ONDRAGEND
#define DISPID_HTMLELEMENTEVENTS2_ONDRAGENTER  DISPID_EVMETH_ONDRAGENTER
A definite hint that if one goes to the trouble of working out how to define and implement an IHTMLEditDesigner interface, and then attach it to the HTML editor one will be notified when these events (among many others) occurs.

So let's code it and see how it works. This is the header for my CMSHTMLDisableDragHTMLEditDesigner class derived from IHTMLEditDesigner. (Can I lay a claim to the longest classname on CP?).

class CMSHTMLDisableDragHTMLEditDesigner : public IHTMLEditDesigner
{
public:
    virtual HRESULT STDMETHODCALLTYPE 
            QueryInterface(REFIID riid, void __RPC_FAR *__RPC_FAR *ppvObject);
    virtual ULONG   STDMETHODCALLTYPE
            AddRef(void);
    virtual ULONG   STDMETHODCALLTYPE
            Release(void);

    virtual HRESULT STDMETHODCALLTYPE
            PreHandleEvent(DISPID inEvtDispId, IHTMLEventObj *pIEventObj);
    virtual HRESULT STDMETHODCALLTYPE
            PostHandleEvent(DISPID inEvtDispId, IHTMLEventObj *pIEventObj);
    virtual HRESULT STDMETHODCALLTYPE
            TranslateAccelerator(DISPID inEvtDispId, IHTMLEventObj *pIEventObj);
    virtual HRESULT STDMETHODCALLTYPE
            PostEditorEventNotify(DISPID inEvtDispId, IHTMLEventObj *pIEventObj);

                    CMSHTMLDisableDragHTMLEditDesigner();

    BOOL            Attach(IHTMLDocument2 *pDoc);
    void            Detach();

private:
    IHTMLEditServices *m_pServices;
    UINT            m_uRefCount;
    CMSHTMLDisableDragIDispatch m_dp;
};
IHTMLEditDesigner is derived from IUnknown so we must provide those standard methods.

Adding an Event Designer to the editor

Let's be very clear on this. MSHTML would probably (if it were sentient) rather we didn't go messing about with its event handling. So it's not about to go and create an IHTMLEditDesigner instance just because we wrote one. It doesn't even know our Edit Designer exists! We (the application writer hosting MSHTML in our application) want to modify MSHTML's behaviour, so we're the ones who have to create an instance of our IHTMLEditDesigner derived object and tell MSHTML to use it. Because we're the ones creating the object we get to decide if it's going to live in a COM DLL or in our exe file (the one that's hosting MSHTML). If it's in our exe file there's no need for CoCreateInstance(). Just do a m_designer = new CMSHTMLDisableDragHTMLEditDesigner or embed an instance of the object in your view and let c++ instantiation take care of the rest.

The documentation is rather less than explicit on the question of the lifetime of an IHTMLEditDesigner connection, so I've assumed that it lasts just as long as the currently loaded HTML document (probably a reasonable assumption given that we're attaching our Edit Designer to a HTML Document object). So I attach the Edit Designer in the views OnDownloadComplete() event. The code looks like this.

void CMyHTMLEditView::OnDownloadComplete(LPCTSTR lpszURL)
{
    // other code that's irrelevant to this discussion
    .
    .
    .
    CHtmlEditView::OnDownloadComplete(lpszURL);
    m_pDoc = (IHTMLDocument2 *) GetHtmlDocument();
    m_designer.Detach();
    m_designer.Attach(m_pDoc);
}
m_pDoc is a pointer to the DOM for the current HTML page and m_designer is an embedded instance of CMSHTMLDisableDragHTMLEditDesigner in the view. Just to play safe I do a Detach() and then reattach m_designer to the IHTMLDocument2 interface. If the designer wasn't already attached to a document the detach does nothing - otherwise it removes itself from that documents list of IHTMLEditDesigner instances. This way I don't have to keep track of whether an Edit Designer has already been attached or not.

Attach() looks like this.

BOOL CMSHTMLDisableDragHTMLEditDesigner::Attach(IHTMLDocument2 *pDoc)
{
    if (m_pServices != (IHTMLEditServices *) NULL)
        m_pServices->Release();

    IServiceProvider *pTemp;

    if (pDoc == (IHTMLDocument2 *) NULL)
        return FALSE;

    pDoc->QueryInterface(IID_IServiceProvider, (void **) &pTemp);

    if (pTemp != (IServiceProvider *) NULL)
    {
        pTemp->QueryService(SID_SHTMLEditServices, IID_IHTMLEditServices, 
                                (void **) &m_pServices);

        if (m_pServices != (IHTMLEditServices *) NULL)
        {
            m_pServices->AddDesigner(this);
            return TRUE;
        }
    }

    return FALSE;
}
This queries the document COM object for an IServiceProvider interface from the document and then requests a IHTMLEditServices interface from the IServiceProvider interface. We then add ourselves, as a designer, to the IHTMLEditServices interface. If all of this succeeds MSHTML will call the various methods in our IHTMLEditServices derived object whenever anything interesting happens.

Detach() looks like this.

void CMSHTMLDisableDragHTMLEditDesigner::Detach()
{
    if (m_pServices != (IHTMLEditServices *) NULL)
        m_pServices->RemoveDesigner(this);
}
The code within the PreHandleEvent() method might look like this.
CMSHTMLDisableDragHTMLEditDesigner::PreHandleEvent(DISPID inEvtDispId, 
                                         IHTMLEventObj *pIEventObj)
{
    if (inEvetDispId == DISPID_HTMLELEMENTEVENTS2_ONDRAG)
        pIEventObj->Cancel();
}
given that the purpose of the class is to disable dragging. (The Cancel() function isn't really there, I'm trying to keep it simple for illustration). Looks good. We're confident that we've read and understood the docs so let's compile it and give it a run.

It doesn't bloody work!!! It doesn't crash but it certainly doesn't see a DISPID_HTMLELEMENTEVENTS2_ONDRAG event. Our end user can click on an image in our WYSIWYG HTML editor and move that image around until their arms fall off and there's nothing we can do about it!

So what went wrong?

Let's go back over what we've done to be sure we didn't miss anything. We implemented a class derived from IHTMLEditDesigner. We followed the MSDN documentation that tells us how to add our IHTMLEditDesigner object. And if we were to add a trace statement before the if test in CMSHTMLDisableDragHTMLEditDesigner::PreHandleEvent we'd see many many calls to the function. So what went wrong?

The documentation doesn't match the behaviour! I should state that this is what I've seen using Internet Explorer 6 with all current security updates applied, on Windows 2000 Service Pack 4 and all current hotfixes. The only notifications I see in my PreHandleEvent() are the raw mouse events, that is, DISPID_HTMLELEMENTEVENTS2_ONMOUSEDOWN, DISPID_HTMLELEMENTEVENTS2_ONMOUSEMOVE and DISPID_HTMLELEMENTEVENTS2_ONMOUSEUP.

Now if you've followed this far you've probably guessed that there is a solution to the problem. If there weren't I'd have probably posted a few questions on various message boards and given up.

The Solution

Lies in interpreting the data we're sent during a callback. In addition to the event identifier we get a pointer to an IHTMLEventObj interface which lets us query various things about the event. One of the things we can query is the srcElement which gives us a pointer to an IHTMLElement interface. If we look at that interface we see there's an onDragStart method which allows us to substitute an event handler which will be called when the user initiates a drag operation. We could set the event handler when we see a DISPID_HTMLELEMENTEVENTS2_ONMOUSEDOWN event.

The event handler

The event handler we provide to the onDragStart() method needs to be a IDispatch pointer with a default function that takes no parameters. I'd show you the class definition but it's literally just an IDispatch interface. Nothing special there.

CMSHTMLDisableDragDispatch::GetTypeInfoCount() returns 0, indicating there are no type information interfaces. CMSHTMLDisableDragDispatch::GetTypeInfo() returns DISP_E_BADINDEX no matter what parameters you pass and CMSHTMLDisableDragDispatch::GetIDsOfNames() returns DISP_E_UNKNOWNNAME whatever the requested ID's. So far it's a pretty minimal implementation of IDispatch. The real work (and the only purpose the class has) is in the Invoke() method.

HRESULT STDMETHODCALLTYPE CMSHTMLDisableDragDispatch::Invoke(
    DISPID /*dispIdMember*/, REFIID /*riid*/, LCID /*lcid*/, 
    WORD /*wFlags*/, DISPPARAMS * /*pDispParams*/,
    VARIANT *pVarResult, EXCEPINFO * /*pExcepInfo*/, 
    UINT * /*puArgErr*/)
{
    //  If we were installed it means we should disable
    //  dragging. So set the return value to false
    pVarResult->vt = VT_BOOL;
    pVarResult->boolVal = false;
    return S_FALSE;
}
Even though there are a bunch of parameters passed to the function the only one we're interested in is the pVarResult one. Invoke() sets it to a false boolean and returns. Setting it to false cancels the event. Bingo, dragging is disabled!

Installing the event handler

is done in the IHTMLEditDesigner::PreHandleEvent() function thusly.
HRESULT STDMETHODCALLTYPE 
    CMSHTMLDisableDragHTMLEditDesigner::PreHandleEvent(
        DISPID inEvtDispId, IHTMLEventObj *pIEventObj)
{
    USES_CONVERSION;
    IHTMLElement  *pSel;
    BSTR          b = BSTR(NULL);

    if (inEvtDispId == DISPID_HTMLELEMENTEVENTS2_ONMOUSEDOWN)
    {
        if (pIEventObj != (IHTMLEventObj *) NULL)
        {
            pIEventObj->get_srcElement(&pSel);

            //  We've got our source element, get its tag
            if (pSel != (IHTMLElement *) NULL)
            {
                pSel->get_tagName(&b);

                if (_tcsicmp(_T("IMG"), W2A(b)) == 0)
                {
                    //  We only install the ondragstart handler if the
                    //  element is an IMG.
                    VARIANT v;

                    v.vt = VT_DISPATCH;
                    v.pdispVal = &m_dp;

                    pSel->put_ondragstart(v);
                }
            }
        }
    }

    return S_FALSE;
}
m_dp is an instance of CMSHTMLDisableDragDispatch embedded in our Edit Designer.

You'll notice there's a test on the elements Tag property. That's because I only wanted to disable dragging of images. If we install the event handler on any srcElement we disable dragging for all objects on the page. By checking for an IMG tag we ensure that we're installing the event handler only for image objects.

You'll notice the demo project uses CodeProject as the HTML document (what else would it use?). You'll also notice that some images are still dragable. Bob for instance. That's because Bob's tag is AREA not IMG. You can see where this is going...

Using the code

To use the Edit Designer in your own projects you need to add the source files in the source download. Then, in your edit view you add two data members
IHTMLDocument2  *m_pDoc;
CMSHTMLDisableDragHTMLEditDesigner m_designer;
Add an OnDownloadComplete() function to your view (the wizard can do this for you) and add the following lines in the function
m_pDoc = (IHTMLDocument2 *) GetHtmlDocument();
m_designer.Detach();
m_designer.Attach(m_pDoc);
Voila, you're done!

History

28 March 2004 - Initial version.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Rob Manderson
United States United States
Member
I've been programming for 35 years - started in machine language on the National Semiconductor SC/MP chip, moved via the 8080 to the Z80 - graduated through HP Rocky Mountain Basic and HPL - then to C and C++ and now C#.
 
I used (30 or so years ago when I worked for Hewlett Packard) to repair HP Oscilloscopes and Spectrum Analysers - for a while there I was the one repairing DC to daylight SpecAns in the Asia Pacific area.
 
Afterward I was the fourth team member added to the Australia Post EPOS project at Unisys Australia. We grew to become an A$400 million project. I wrote a few device drivers for the project under Microsoft OS/2 v 1.3 - did hardware qualification and was part of the rollout team dealing directly with the customer.
 
Born and bred in Melbourne Australia, now living in Scottsdale Arizona USA, became a US Citizen on September 29th, 2006.
 
I work for a medical insurance broker, learning how to create ASP.NET websites in VB.Net and C#. It's all good.
 
Oh, I'm also a Kentucky Colonel. http://www.kycolonels.org

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralMy vote of 2memberchodi10 May '10 - 7:43 
asdf
GeneralDHTML Editor with table support and source editormemberElmue8 Nov '07 - 11:24 

If you are interested in a comfortable HTML Editor for Visual C++ 6 or 7 have a look at this article:
 
DHTML Editor with table support and source editor
http://www.codeproject.com/cpp/DHTMLEditor.asp
 

QuestionDetect mouse click in the Child window of CHTMLEDITVIEWmemberbengz6 Sep '06 - 21:52 
Hi,
 
can anyone help ?
 
I have difficulties to detect mouse click in the child window created by using CHTMLEDITVIEW (base class) MFC VC++.NET.
 
Anyone has any solution ? tks.
 

 
terr
QuestionThis Doesn´t seem to work with CHtmlEditCtrlmembercjsk819 Jan '06 - 4:51 
It seems that this message wrapper doesn´t work with the other HTMLEditCtrl, if somenone has the answer for this topic, please reply.
 
Curtis Jr.
GeneralRestricting where in the document a user can edit.memberDavid Fleming26 Jul '05 - 19:37 
Here's what I'm trying to accomplish (and I admit right up front that I am a hobby coder and some of this stuff is over my head, but I learn best by trying something new)...
 
What I would like to be able to do is have an editable HTML document, except have areas that are "off limits." For example, having the top portion of the page, with logos and header stuff NOT editable, but everything below that editable. So what I was thinking is to set up separate
sections and set perhaps the background color of the off-limits areas to a light gray (so that the user can see what is off-limits). Then if the user clicks in or moves the cursor to an area of the document that is in the off-limits area, the editor would simply jump the cursor back out of the off-limits area -- perhaps to the first position below the off-limits area (or perhaps simply cancel the mouse-click or cursor move). I would also need to disable the ability to click and drag to highlight an area within the off-limits section.
 
So, the first question is: is it doable?
The second question is: how do I do it? And I don't expect you guys the write this for me, but point me in the direction of being able to track where the cursor is in the document and programmatically move it elsewhere, how to detect the background color of the element at the cursor location (or selected text in case the user clicks in an editable section and then drags into an off-limits section), etc.
 
I think I have a basic understanding of the article -- kudos to Rob for an excellent article (which I rated a 5) -- but I'm stuck as to where to go from here.
 
Thanks for any ideas/suggestions.
GeneralRe: Restricting where in the document a user can edit.memberDavid Fleming1 Aug '05 - 20:38 
Well, either no one could answer this, or no one noticed the question, or no one wanted to answer it. Regardless, I did some checking and finally found one solution (although not necessarily the best nor necessarily the solution I want to use -- I'll know once I play with it more).
 
Anyway, one way to restrict where the user can edit, is to simply put the areas of the HTML document you want to protect into a DIV and within that tag include "contentEditable=false". E.g. "
"
 
When you do that, what you will find is that keyboard input is cancelled within that section, even though you can highlight things. I kept the drag-cancel implemented in this article to prevent the user from dragging this DIV around. It all seems to work, except that I did notice that when you click within the protected DIV, the editor puts handles around the DIV area that allow you to resize that DIV area. I have not experimented yet to see what effect this has on the HTML document once you save it.
 
Anyway, just in case someone else was looking for an answer to this question, this is at least one partial answer.
GeneralRe: Restricting where in the document a user can edit.memberDavid Fleming1 Aug '05 - 20:41 
Woops! In my answer above, I forgot to turn off HTML tags so that my example HTML tag would show the text.
 
Let's try it again:
E.g. <DIV contentEditable=false>
GeneralC# equivalent of the C++ sourcememberramidua20 May '05 - 5:29 
Hi Rob,
 
Great article! I'm using C# and couldn't figure out how to code the IHTMLElement2 attachEvent() function that requires an IDispatch pointer parameter.
 
An equivalent C# code would be nice!
 
thanks, ramida
GeneralRe: C# equivalent of the C++ sourcememberbabalula31 May '05 - 3:28 
Please disregard this message.
 
ramida
Generalie5 problemssussAnonymous5 Nov '04 - 19:23 
Hi!
 
I am using IHTMLEventObj for determining user's action and it works only
for ie6.
On ie5 i could set just connection point for document but never get any
event fired form user.
 
Need help!
Generalie5 problemssussazorea5 Nov '04 - 19:22 
Hi!
 
I am using IHTMLEventObj for determining user's action and it works only
for ie6.
On ie5 i could set just connection point for document but never get any
event fired form user.
 
Need help!
GeneralKeystrokessussHockey12 Aug '04 - 6:32 
Were the mouse events the only available?
 
How about capturing keystrokes?
 
DISPID_HTMLELEMENTEVENTS2_ONKEYDOWN, etc???
 
Did you try these? Are they even available?
 
Thanks in advance
 
Cheers Smile | :)
 
How do I print my voice mail?
GeneralRe: KeystrokesmemberDavid Fleming26 Jul '05 - 19:18 
Look in the MSHTMDID.H file for all of the available disp IDs.
Yes, there is an ID for keydown, keypress, keyup, etc.
GeneralFull HTML edit control fo VC++ 6.0memberIrek Zielinski3 Jun '04 - 4:47 
If you need a full HTML edit control for VC++ 6.0 read this article:
http://www.codeproject.com/useritems/HtmlEdit.asp
 
Check out my software at: http://www.ireksoftware.com
Generalhmmm sweet..membermystro_AKA_kokie14 May '04 - 16:12 
I have been looking for a free visual html editor, is this it? I can't find my pirated copy of frontpage, how well does this stack up against it?
 

No matter how many times u take a dump, u can never accumulate more than your mother.
West African proverb(a favorite of my mother).

Generalcustomizing context menus / getting notificationsmemberleoloewe3 May '04 - 6:02 
Nice article!
I am currently working on a project that also uses html templates and I need a possibility to replace the default "properties" dialog for images that is called by the context menu of an image.
I already tried the IDocHostUIHandler interface as Jim Xochellis did in his article
but it seemed that it only works for popups that DON'T belong to images.
I just want to get a notification if the user clicks on the "properties" item in the image context menu.
Is there anybody with an idea how to do this?
 
Thanks for your reply
Leo
GeneralRe: customizing context menus / getting notificationsmemberleoloewe6 May '04 - 5:20 
Hi,
for those who have the same problem:
Use the IDocHostUIHandler and the IHTMLEditDesigner interfaces.
Replace the default context menu with IDocHostUIHandler (as described in Jim's article), catch the CONTEXT_MENU_IMAGE mode in the CustomShowContextMenu and display your context menu.
Modify the PreHandleEvent function of the IHTMLEditDesigner and query an IID_IHTMLImgElement interface. Store this interface pointer for later use (I use a global static variable, you can also create a member in your app class for this purpose).In the event handler function of your image-context menu entry, just use the interface pointer after some security checks and don't forget to release it.Big Grin | :-D
 
If you need a working sample code, just ask me...
GeneralRe: customizing context menus / getting notificationsmemberrichard sancenot21 Nov '06 - 4:29 
Good hint indeed, thanks for sharing your tips.
 
I found yet another solution, maybe as professionnal than you but working pretty well.
 
In prehandleEvent, catch DISPID_HTMLELEMENTEVENTS_ONCONTEXTMENU message.
Then dinamically create a new menu like this :
 

CMenu menuPop;
menuPop.CreatePopupMenu();
menuPop.AppendMenu(MF_STRING,1,"Item1");
menuPop.AppendMenu(MF_STRING,2,"Item2");
 
CPoint pt;
GetCursorPos(&pt);
int iSelected = menuPop.TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON|TPM_RETURNCMD, pt.x, pt.y,m_pParent);//Where m_pParent is the pointer to the html edit window
 
switch(iSelected)
{
case 1:
case 2:
::PostMessage(m_pParent->m_hWnd,...)//Send the menu notification to a window...
}
return S_OK; //Returns S_OK to indicate that the event has been completely handled, so that another context menu should not be displayed

 


 
Tout programme dont la fiabilité dépend de l'homme n'est pas fiable

GeneralFocusmemberAppstmd28 Apr '04 - 5:06 
Hi!
 
Is there a way to be notified when the Html Edit Control obtains or loses the focus?
 
Thks in advance!
Appstmd
http://www.atlence.com
GeneralRe: Focusmemberleoloewe3 May '04 - 10:33 
Hi there!
I just played around with the events you can catch with this code.
Just use Rob's sample project, go to the function PreHandleEvent in CHtmlEditDesigner.CPP and exchange DISPID_HTMLELEMENTEVENTS2_ONMOUSEDOWN with DISPID_HTMLELEMENTEVENTS2_ONFOCUS.
The event IDs are listed in the file MSHTMDID.H
 
Have fun!
 
Leo

GeneralRe: FocusmemberAppstmd7 May '04 - 9:44 
Hi!
 
Thanks for your answer. But my program doesn't received the DISPID_HTMLELEMENTEVENTS2_ONFOCUS event when the Html control obtains the focus!
 
Here my code:
 

HRESULT STDMETHODCALLTYPE CMSHTMLDisableDragHTMLEditDesigner::PreHandleEvent(DISPID inEvtDispId, IHTMLEventObj *pIEventObj)
{
if (inEvtDispId == DISPID_HTMLELEMENTEVENTS2_ONFOCUS)
AfxMessageBox ("Focus!");
 
if (inEvtDispId == DISPID_HTMLELEMENTEVENTS2_ONKEYPRESS)
AfxMessageBox ("KeyPress!");
 
return S_FALSE;
}

 
But the DISPID_HTMLELEMENTEVENTS2_ONKEYPRESS event works very well...
 
Any idea?
 
Thks in advance!
Appstmd
http://www.atlence.com
GeneralRe: Focusmemberleoloewe12 Jun '04 - 2:39 
Hi,
it seems as if I have misunderstood your question. Do you want to try to get the OnSetFocus/OnKillFocus events of the CHtmlEditCtrl window?

GeneralRe: FocusmemberAppstmd17 Jun '04 - 5:21 
Hi,
 
Yes, I want to get the OnSetFocus and OnKillFocus when the CHtmlEditCtrl control obtains or looses the focus (ie when the user clicks on the control or activates it by pressing the TAB key). I want to update some data when my control gets the focus.
 
I have tried to derive OnKillFocus and OnSetFocus messages from my control, but my code is not executed....
 
Is there a solution?
 
Thks in advance!
Appstmd
http://www.atlence.com
GeneralIHTMLEditDesigner &amp; Flash/Java ElementsmemberLiquidCrystal31 Mar '04 - 9:19 
First of all thank you Rob for this effort.
 
I need to extend the cababilities of the IE WYSIWYG HTML editor to show Flash animation while in the WYSIWYG edit mode. Currently it does not show them and only shows a place holder. Also I need to show other elements like Java applets. I thought of IHTMLEditDesigner to do this. Has anybody tried it and can confirm this?
 
Thank you.
GeneralRe: IHTMLEditDesigner &amp; Flash/Java ElementseditorRob Manderson31 Mar '04 - 9:49 
LiquidCrystal wrote:
First of all thank you Rob for this effort.
 
My pleasure Smile | :)
 

LiquidCrystal wrote:
to show Flash animation while in the WYSIWYG edit mode
 
Yeah, the docs state that when in edit mode things like links and marquees are disabled. I'd assume this also applies to 3rd party ActiveX's and so on. Maybe you could load the page with edit mode turned off (which should load Flash) and then turn edit mode on once you've got the OnDocumentComplete() event. *shrug* it's a place to start anyway Smile | :)
 
Rob Manderson
 
Colin Davies wrote: I'm sure Americans could use more of it, and thus reduce the world supply faster. This of course would be good, because the faster we run out globally, the less chance of pollution there will be. (Talking about the price of petrol) The Soapbox, March 5 2004

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web02 | 2.6.130516.1 | Last Updated 25 Apr 2004
Article Copyright 2004 by Rob Manderson
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid