Question

I’ve got this C++ Builder 2009 app. It’s not desperate – it’s a demo, but it’s driving me to Scotch. I’m now so full of single malt that I have to ask for help.

This app has a main form and some other stuff that all works. I have no reason to think that there’s anything wrong with it. I added another form, ‘TfoPNGload’, and added a few components – nothing unusual. I took it out of the auto-create list so instances could be created on-demand.

As a test, I plonked a SpeedButton on the main form and, in the click, created an instance of the ‘TfoPNGload’ form and Show()ed it:

void __fastcall TForm1::SpeedButton1Click(TObject *Sender)
{
  myPNGform=new TfoPNGload(NULL);
  myPNGform->Show();
}

This worked fine too – I click on the button, a form popped up.

Everything is normal.

I added a message-handler and things became abnormal even before I sent any messages. I added a function and the macro thingy to make it a message-handler:

class TfoPNGload : public TForm
{
__published:    // IDE-managed Components
    TImage *Image1;
    TPanel *Panel1;
    TSpeedButton *SpeedButton1;
    TTimer *tiSlideShow;
    TLabel *Label1;
    void __fastcall tiSlideShowTimer(TObject *Sender);
    void __fastcall FormCreate(TObject *Sender);
private:
    PNGload *myLoad;
    void __fastcall filesLoaded(TObject *Sender);
protected:
public:     // User declarations
    __fastcall TfoPNGload(TComponent* Owner);


    MESSAGE void __fastcall WMAPP(TMessage& msg);

    BEGIN_MESSAGE_MAP
    MESSAGE_HANDLER(WM_APP, TMessage, WMAPP)
    END_MESSAGE_MAP(TfoPNGload)

    vector<PNGtask*> *PNGresult;
    int vecSize;
};

Then, when I clicked on the button to create the form, up pops the classic ‘Stack overflow’ messagebox!

If I comment out the macros:

//      BEGIN_MESSAGE_MAP
//      MESSAGE_HANDLER(WM_APP, TMessage, WMAPP)
//      END_MESSAGE_MAP(TfoPNGload)

..the form is created just fine!

It’s not like I’m posting any messages yet – just processing the macros seems to generate the overflow on form creation. The WMAPP function is empty anyway.

Anyone seen anything like this or, even better, fixed it?

If push comes to shove, I have a workaround – using the same macros in the main form does work, so I could post my stuff there instead and then call into the ‘TfoPNGload’ form. It would probably work but it makes a mess of my code structure which, TBH, is difficult enough to follow as it is :((

Rgds,
Martin

Answer 1

I suspect this line:

END_MESSAGE_MAP(TfoPNGload)

Should specify the base class:

END_MESSAGE_MAP(TForm)

The message map macros generate a virtual function called Dispatch or something like that which contains a big switch for handling the mapping cases. The END_MESSAGE_MAP(TfoPNGLoad) macro will generate the default: case of the switch which will call TfoPNGLoad::Dispatch. But, guess what, that is the very function being defined by the macros: so runaway direct recursion occurs.

You want to pass the superclass name TForm to the end macro so that it generates a default: case routing to the base class Dispatch.