I've got a strange error during my C++ classes right now. I've an ActiveX wrapper class (included in wxWidgets) which i added a brand new virtual function to. I've another class that gets in the ActiveX one (wxIEHtmlWin) nevertheless the ActiveX class always calls its very own function rather than the main one in wxIEHtmlWin which overrides it.

I can not exercise why this really is happening. I made the function pure virtual and today this program crashes if this does the function call but compiles fine otherwise. Can there be in whatever way to disable virtual functions or have I discovered a bug in Visual Studio?

ActiveX class

virtual FrameSite* getNewFrameSite()=0;

wxIEHtmlWin class

class wxIEHtmlWin : public wxActiveX
    FrameSite* getNewFrameSite();

FrameSite* wxIEHtmlWin::getNewFrameSite()
    return new gcFrameSite(this);

Edit: I have added another test function (returns an int) but still screws up.

Connect to code under consideration: http://lodle.net/public/iebrowser.rar


OK because of the solution below i first got it to operate. Things i did was produce the activex class in 2 parts (like recommended) in wxIEHtmlWin i known as the 2nd part within the constructor code. Like so:

wxIEHtmlWin::wxIEHtmlWin(wxWindow * parent, wxWindowID id, const wxPoint& pos,const wxSize& size,long style, const wxString& name) : wxActiveX()
    wxActiveX::Create(parent, PROGID, id, pos, size, style, name);

Now we all know why wxWidgets supports two part construction.

You're calling the virtual method from inside the class's constructor (via another call). This can call the technique around the current class because the sub-class has not been built yet. The fix is by using an init() method and refer to it as after creating the course.

i.e something similar to this:

class wxActivex {
  wxActivex() {}
  virtual void init() {

  // in the code that uses these classes:
  wxActivex *activex = new IEHtmlFrame();

A far more "boiled lower" version of the question are available here. But in a nutshell, the bottom object is not (yet) a clear case of the derived type, because of this cant call any overloaded functions around the derived object.