ActiveQt crashes when AxServer app also has an AxContainer (commercial license)

Joshua

Hi All,

my first post! I couldn't find any post shining light on this 'challenge'.

I'm not sure it is a bug, but my app ran perfectly with a COM/OLE container (used dumpcpp for the container wrapper) and now that I changed my main with the QAXFACTORY_DEFAULT header it crashes my app, unless I exclude the widget that is instantiating the COM/OLE container. Which makes me wonder: why can't I use QAxObjects in my out-of-process COM Server applications? Or am I missing something trivial? (Which I hope)

Main.cpp:
@QAXFACTORY_DEFAULT(MainController,
"{0005382C-63C9-4d10-94F0-28843B13EE55}",
"{9ee49617-7d5c-441a-b833-4b068d40d751}",
"{13eca64b-ee2a-4f3c-aa04-5d9d975979a7}",
"{ce947ee3-0403-4fdc-895a-4fe779394b46}",
"{8de435ce-8d2a-46ac-b3b3-cb800d0847c7}");

int main(int argc, char *argv[])
{
Q_INIT_RESOURCE(qfe);

QApplication app(argc, argv);

MainController *mc = 0;

if (!QAxFactory::isServer() ) {
mc = new MainController();
mc->show();
}

return app.exec();
}
@

MainController (QMainWindow) has a few widgets, of which the FittingController has the QAxObject (ARK):
@
FittingController::FittingController(QWidget *parent) : QWidget(parent),
m_init(true), m_Core(0)
{
// Heap
m_BoxProgrammers= new QComboBox();
m_BoxProgrammers->setEnabled(false);

// Stack
ARK::ICatalog* cat;
QVariant index;

// Instantiate the core component
m_Core = new ARK::Core2(this);

// Get dropdown values from core
if (m_Core==NULL) {
qWarning("ERROR [fittingcontroller] The ARK Core Component is not installed properly.");
return;
} else fillComboBox(m_BoxProgrammers, m_Core->Programmers());

..... snip ....

}
@

m_Core->Programmers() does return with a pointer but the app dies when doing a ->Count() on it in fillComboBox:
@
First-chance exception at 0x671c179d in QFE.exe: 0xC0000005: Access violation reading location 0x8000400b.
A buffer overrun has occurred in QFE.exe which has corrupted the program's internal state.
@

Seemingly the passed pointer is NOT valid (anymore).
Any help appreciated! In the mean time I'll create a little test app to find out whether my brain or ActiveQt or both are buggy ;)

Cheers, Joshua

Joshua

Ok, seems DUMPCPP doesn't yet meet my requirements.

When I exclude its exported classes and instead instantiate QAxObjects myself it simply works within my QAxServer ("see also: Qt3.3 outlook example":http://doc.qt.nokia.com/3.3/qaxcontainer-example-qutlook.html).

I'd already customized the exported classes that DUMPCPP generated in order to add the support of QI pointers. No idea what goes wrong in those magical exports, but I'm taking the old route. Can't wait to get the Windows app done so I don't have to be bothered with COM (for a while).

Joshua

Ok, my fear was grounded: using DUMPCPP to wrap a COM object for use within your QAxServer will get you a buffer overrun. I just compiled the Qutlook example with an additional QAXFACTORY_DEFAULT in the main.cpp to convert it to a QAxServer app. Compiles but bugs out, just like my app. Also the QAxServerd.lib seems to prefer to be linked before QAxContainerd.lib (project settings) to avoid 'already defined' errors.

I'll report this bug asap...