Return Interface Pointer - COM Discussion Boards

3-Sep-03 11:36

Gil,

There maybe very simple shortcut:
you've already mentioned "if (RunEmbedded() || RunAutomated())", because you want it to register with OLE even when runningf from command line: just comment that if, so COleTemplateServer::RegisterAll(); or similar will be called.

May work...

"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me

Gilrock3-Sep-03 11:50

3-Sep-03 11:50

Maybe my first post wasn't clear enough, but that's basically what I've done. It now looks like this:

COleTemplateServer::RegisterAll();<br />
if (RunEmbedded() || RunAutomated())<br />
{<br />
  // Register all OLE server (factories) as running.  This enables the<br />
  //  OLE libraries to create objects from other applications.<br />
}<br />
else<br />
{<br />
  // When a server application is launched stand-alone, it is a good idea<br />
  //  to update the system registry in case it has been damaged.<br />
  COleObjectFactory::UpdateRegistryAll();<br />
}

That change is what allowed a .vbs script to attach to the server instance that was started from the command line instead of creating a new one. But the problem is that the application still disappears when I close the dialog which leaves the clients with no server.

Gil

igor19603-Sep-03 12:01

3-Sep-03 12:01

OK, now that's clearer.
Yes, your script now attaches to running instance of singleton, even the one started from command line.

Anyway: try AfxOleSetUserCtrl(FALSE); and put it at the end of InitInstance or even in your FrameWnd::OnCreate.

Also, because now you have singleton -- you can easily build Debug version and use Debug facilities to see what's going on. In fact I'm often using that trick with COleTemplateServer::RegisterAll(); to debug my outproc servers (which are not singletons).

Regrds

"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me

Gilrock3-Sep-03 12:13

3-Sep-03 12:13

Oops...I'm not at home and I realized it actually has a "return TRUE" if embedded to keep the dialog from activating when accessed via automation.
Like this:

COleTemplateServer::RegisterAll();
if (RunEmbedded() || RunAutomated())
{
  // Register all OLE server (factories) as running.  This enables the
  //  OLE libraries to create objects from other applications.
  return TRUE;
}
else
{
  // When a server application is launched stand-alone, it is a good idea
  //  to update the system registry in case it has been damaged.
  COleObjectFactory::UpdateRegistryAll();
}

Gil

Gilrock3-Sep-03 13:02

3-Sep-03 13:02

Unfortunately the AfxOleSetUserCtrl(FALSE) didn't seem to fix the issue. I don't think I have a FrameWnd::OnCreate in a dialog based application do I?

Here's instruction for how to reproduce the problem that I posted to the C++ forum:
http://www.codeproject.com/script/comments/forums.asp?forumid=1647&fr=126#xx600114xx

If your willing to take a few minutes and create a new project you should be able to see the problem.

Gil

Gilrock4-Sep-03 6:20

4-Sep-03 6:20

Thanks for the help. I posted another response to the C++ thread on this issue. One thing I notice is that when your using the proxy dialog interface and you've made your server a singleton, if you activate the dialog, run a .vbs script to access the application interface, and then close the dialog before the .vbs script finishes, the server does remain active due to the CanExit() code added to the dialog by ClassWizard. The problem is that the server doesn't destroy when all clients have released their objects. That's because the ClassWizard hasn't created a mechanism for the dialogs CanExit() logic to be called each time a CDlgProxy objects destructor runs. I manually added some code to do this and now it works.

Gil

igor19604-Sep-03 6:50

4-Sep-03 6:50

That's because the ClassWizard hasn't created a mechanism for the dialogs CanExit() logic to be called each time a CDlgProxy objects destructor runs. I manually added some code to do this and now it works.

Gil,
Right. Default MFC Server implementation is designed for an invokation of the server only through either Automation or as standalone. Not both, as you are doing.
Therefore, what you've done, maybe not clean, but appropriate. There are probably other ways to tweak desired behavior, but if your solution works -- that's what needed. Right? Better sometimes is worse then good.

Regards

"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me

Return Interface Pointer

Daniel Strigl1-Sep-03 4:50

1-Sep-03 4:50

Hi!

I am very new to COM and ATL and try to implement something like this:
I have a simple COM server with the following interface:

[
    object, ...
]
interface ITest : IUnknown
{
    [id(1), helpstring("Methode GetInterface")] HRESULT GetInterface([in] int n, [out] ITest2** pITest2);
};

The interface method GetInterface should return a new pointer to the interface
ITest2. This function should not work like QueryInterface, the
interface ITest2 is not in the same coclass as the ITest, it's in
another coclass.

This function should work like the following DirectX (DirectDraw) function CreateSurface:

LPDIRECTDRAW        lpDD = NULL;
LPDIRECTDRAWSURFACE lpDDSPrimary = NULL;
...
HRESULT hError = lpDD->CreateSurface(&DDSurfaceDesc, &lpDDSPrimary, NULL);
...

How can I implement the GetInterface function?
The ITest2 interface (and the coclass of the interface) should not be creatable
with the CoCreateInstance, it should be only created by the GetInterface
method!

Daniel Wink | ;)

---------------------------
Never change a running system!

valikac1-Sep-03 6:01

valikac

1-Sep-03 6:01

One solution is containment. Another solution is aggregation given that you want the client to gain direct access to the inner COM object.

Kuphryn

Daniel Strigl1-Sep-03 20:03

1-Sep-03 20:03

Can you give my a sample application or a link to a tutorial?

Thanks!

Daniel Wink | ;)

---------------------------
Never change a running system!

Stefan Pedersen1-Sep-03 10:20

Stefan Pedersen

1-Sep-03 10:20

If I didn't misunderstand you
static HRESULT CComObject<Base>::CreateInstance(CComObject<Base>** pp)
should be the solution to your problem.

Daniel Strigl1-Sep-03 20:04

1-Sep-03 20:04

Any sample or link to a tutorial?

Thanks!

Daniel Wink | ;)

---------------------------
Never change a running system!

Lim Bio Liong18-Sep-03 19:28

Lim Bio Liong

18-Sep-03 19:28

Hello Daniel,

I created a sample ATL project with two simple coclass's (Test and Test2). One of them, Test2 is specifically noncreatable. This noncreatble feature can be set easily by including the "noncreatable" attribute for the coclass statement in the IDL file :

[
uuid(A6C64958-F337-4981-8F31-F35AEA02DD98),
helpstring("Test2 Class"),
noncreatable
]
coclass Test2
{
[default] interface ITest2;
[default, source] dispinterface _ITest2Events;
};

This attribute is very useful when your client apps are Visual Basic based. In VB, if a coclass is noncreatable, then when you attempt to create a new instance of it via the "New" keyword, e.g. :

Dim Test2Obj As Test2
...
...
...
Set Test2Obj = New Test2

You will get an error message that reads : "Invalid use of New keyword".

However, the "noncreatable" attribute is not sufficient for VC++ clients. In a VC++ client app, if you have the following statement :

ITest2Ptr spTest2Ptr = NULL;

spTest2Ptr.CreateInstance(__uuidof(Test2));

Surprise, surprise, you will still succeed and obtain an ITest2 smart pointer.

In order to ensure that the above CreateInstance() function call will fail, you will need to comment out the Test2 Object Entry in the ATL Object Map of your ATL project :

BEGIN_OBJECT_MAP(ObjectMap)
OBJECT_ENTRY(CLSID_Test, CTest)
//OBJECT_ENTRY(CLSID_Test2, CTest2) <-- comment out this line.
END_OBJECT_MAP()

This will ensure that when your ATL DLL is asked to create an instance of an object of coclass Test2 (this happens in the global DllGetClassObject() function), a failure code will be returned.

Note that the good thing about the "noncreatable" attribute and the commenting out of the OBJECT_ENTRY statement will not prevent you from internally creating the CTest2 object. This is, of course, required when the GetInterface() method is called. My implementation of GetInterface() is as follows :

STDMETHODIMP CTest::GetInterface(int n, ITest2 **pITest2)
{
// TODO: Add your implementation code here
CComObject<ctest2> *pTest2New = NULL;

CComObject<ctest2>::CreateInstance(&pTest2New);

if (pTest2New)
{
pTest2New -> QueryInterface (IID_ITest2, (void**)pITest2);
}

return S_OK;
}

I will email you the sample source codes plus VB and a VC++ client apps.

Hope the aboe info will help.

Best Regards,
Bio.

Lim Bio Liong18-Sep-03 19:34

Lim Bio Liong

18-Sep-03 19:34

Hello Daniel,

Please email me your email address so that I can send to you some sample codes.

Best Regards,
Bio.

Daniel Strigl11-Oct-03 2:27

"parameter not optional"?

11-Oct-03 2:27

Thanks! It works fine!

Cheers,
Daniel.
--
FIND A JOB YOU LOVE, AND YOU'LL NEVER HAVE TO WORK A DAY OF YOUR LIFE. Wink | ;)

Yu Zhiquan1-Sep-03 1:24

Yu Zhiquan

1-Sep-03 1:24

I add an interface to an OCX,
when I use the OCX, it throw an exception and pop a message box "parameter not optional".
Why? who can tell me reason?
Thanks a lot!

Re: "parameter not optional"?

Stefan Pedersen1-Sep-03 10:21

Stefan Pedersen

1-Sep-03 10:21

Are you passing a VT_EMPTY or a VT_NULL?
Well, you shouldn't Smile | :)

Re: "parameter not optional"?

igor19603-Sep-03 10:59