Re: How to extract data from VARIANT? - COM Discussion Boards

Do I need to destory a SAFEARRAY that is passed in as an argument

timtanbin3-Sep-04 19:57

3-Sep-04 19:57

Hi, I'm implementing an interface method of a COM object that runs in a local EXE server. One of the arguments is a SAFEARRAY (packed in VARIANT).I found if I destroyed the SAFEARRAY after using it, the server EXE would crash mysterically after running for a while. But if I left the SAFEARRAY alone, everything would be OK. So should I destroy the SAFEARRAY or not? Will the underlying RPC do the cleanup work for me?
There is also the twin question: after a client fills a SAFEARRAY argument and then calls the method, does it need to destroy the SAFEARRAY?
Thanks a lot.

Re: Do I need to destory a SAFEARRAY that is passed in as an argument

Anonymous4-Sep-04 8:23

Anonymous

4-Sep-04 8:23

If your server allocates it, the client (that uses it) should call VariantClear on the VARIANT parameter received from the call to the server interface once it has finished with it.

Re: Do I need to destory a SAFEARRAY that is passed in as an argument

timtanbin4-Sep-04 13:32

timtanbin

4-Sep-04 13:32

the situation is

STDMETHODIMP CMyServer::AddKeywords(VARIANT eywords)
{
if (keywords.vt & VT_BSTR && keywords.vt & VT_ARRAY){
CComSafeArray<bstr> sa;
sa.Attach(keywords.parray);
...
sa.Destroy(); // sa.Detach();
}
...
}

// client code
...
CComSafeArray<bstr> sa(m_nKeywords);
...
CComVariant vKeywords(sa.Detach());
m_pServer->AddKeywords(vKeywords);
...

I suddenly had an idea: Since COM is location transparent, i can pretend the server is an in-proc server (although in fact it's a local server). Then in that case, since cient/server interact by direct pointers, the safearray should only be destroyed once (in the client). Is my understanding right? Thanks.

Re: Do I need to destory a SAFEARRAY that is passed in as an argument

peterchen4-Sep-04 15:00

peterchen

4-Sep-04 15:00

timtanbin wrote:
Is my understanding right?

For most cases, yes.

When marshalling occurs, COM takes care of any copying/deleting necessary.

if the SAFEARRAY is a [in] parameter, you just detach the CComSafeArray from it.

if it's in/out, and you can drop the oldand create a new one. In this case, you need to delete the old one

we are here to help each other get through this thing, whatever it is Vonnegut jr.

sighist || Agile Programming | doxygen

How to extract data from VARIANT?

Nirav Doshi3-Sep-04 7:41

Nirav Doshi

3-Sep-04 7:41

Hello,

I am using a third party folder view control which has a method GetSelectedFolder(). The method returns a VARIANT (VT_DISPATCH).

So:

VARIANT varFolder = m_fvFolder.GetSelectedFolder();

if(varFolder.vt == VT_DISPATCH)
{
    // What should be done here to extract the string containing the folder name?
}

Thanks a lot in advance!
Rgds,

Nirav Doshi

* Don't wish it was easier, wish you were better! *

Re: How to extract data from VARIANT?

Jörgen Sigvardsson3-Sep-04 8:33

Jörgen Sigvardsson

3-Sep-04 8:33

If it's returning a VT_DISPATCH, the contained value is an object reference to an IDispatch* object. Not knowing how your third party folder view control works, I'd suggest looking up GetSelectedFolder() in the docs. Chances are that the object is a "dual" object (vtable and dispatch interfaces) which implements IFolder something similar.

You can acquire the IDispatch interface using the pdispVal member of VARIANT. Don't forget to VariantClear() it when you are done or you will leak an object! For less error prone code, take a look at ATL's wrapper class CComVariant.

Similarly, if a VARIANT contains a VT_UNKNOWN, it holds a reference to an IUnknown* object, which you'll have to query for a usable interface. It is accessed through the punkVal member.

--
...Coca Cola, sometimes war...

Re: How to extract data from VARIANT?

Nirav Doshi3-Sep-04 8:52

Nirav Doshi

3-Sep-04 8:52

Jörgen, Thanks a lot for your reply!

Jörgen Sigvardsson wrote:
Not knowing how your third party folder view control works, I'd suggest looking up GetSelectedFolder() in the docs.
The doc only explains this with reference to VB Samples! Frown | :(

- So no use!

Jörgen Sigvardsson wrote:
Chances are that the object is a "dual" object (vtable and dispatch interfaces) which implements IFolder something similar.
Doesn't seem to be that either! Frown | :(

Jörgen Sigvardsson wrote:
You can acquire the IDispatch interface using the pdispVal member of VARIANT
Is it something like:

IDispatch *pIDisp = varFolder.pdispVal;

Had tried this earlier, but what further? Confused | :confused:

Thanks,
Rgds,
Nirav Doshi

* Don't wish it was easier, wish you were better! *

Re: How to extract data from VARIANT?

Jörgen Sigvardsson3-Sep-04 9:09

Jörgen Sigvardsson

3-Sep-04 9:09

Nirav Doshi wrote:
Had tried this earlier, but what further?

I can't help you with that, I'm afraid. You need a description of the interface(s) which the returned object exposes.

Nirav Doshi wrote:
The doc only explains this with reference to VB Samples!

That may be of good use. You could access the object using the dispatch interface using a dispatch driver such as this one[^]. Then you'd have to do something like:

XYDispDriver disp;
disp.Attach(varFolder.pdispVal);
::VariantClear(&varFolder); // Just to remind you of releasing this one ;)
VARIANT* var = disp.GetProperty(_T("PropertyName"));
UseVariant(*var);
var = disp.InvokeMethod(_T("MethodName"), arg1, arg2);
UseVariant(*var);

Please read the article for more information on how the XYDispDriver works as I'm not the author of it.

And also look at the VB samples to learn about the properties and methods which can be used. Happy coding!

--
...Coca Cola, sometimes war...

Re: How to extract data from VARIANT?

Nirav Doshi3-Sep-04 9:16

Nirav Doshi

3-Sep-04 9:16

Hello Jörgen,

Thank you very much for your reply!

I will explore more on this! Atleast now I have some pointers to start with... Smile | :)

Rgds,
Nirav

* Don't wish it was easier, wish you were better! *

ActiveX TypeLib Practices: property or method?

KFournier3-Sep-04 6:29

KFournier

3-Sep-04 6:29

I write custom ActiveX controls for an application that has been slow to support ActiveX completely. In fact, only the recent release of the software claims to support the ability to modify and save ActiveX control properties during design time. So, I plopped my custom controls on a form, but no properties.

The application developers informed me that the design tools only look for properties by scanning the "methods" section of a control's type library rather than the "properties" section. Of course, my properties are all listed on "properties" because VC++ 6.0 does this automatically when you add properties via the Class Wizard.

Example: here's what my property looks like:

dispinterface _DMyControl
{
    properties:
    [id(1)] BSTR Caption;
    
    methods:
    [id(DISPID_ABOUTBOX)] void AboutBox();
};

But, here's what the application would prefer:

dispinterface _DMyControl
{
    properties:
    
    methods:
    [id(0x00000001), propget] BSTR Caption();
    [id(0x00000001), propput] void Caption([in] BSTR lpszNewValue);
    [id(DISPID_ABOUTBOX)] void AboutBox();
};

My question is: does anyone have information or an opinion on which method is preferrable? I ask because the application developers refuse to support straight "properties" on the grounds that so few controls use this paradigm. I want to know if there is a reason I should conform to using purely methods or if I should push the company to support properties.

Kevin Fournier
SRP Computer Solutions, Inc.

Re: ActiveX TypeLib Practices: property or method?

Jörgen Sigvardsson3-Sep-04 8:40

Jörgen Sigvardsson

3-Sep-04 8:40

KFournier wrote:
does anyone have information or an opinion on which method is preferrable?

From a VB perspective, properties are nicer syntactically. From a C++ perspective, there's no difference really. Properties will be accessed as if they were functions anyway.

One significant advantage using properties I can think of right now, is that you can automate persistence rather easily. I'm mainly thinking of IPropertyBag/IPersistPropertyBag implementations. All you have to do then is to iterate through the members of an interface and persist them one by one as variants. Of course, it becomes harder if the property is indexed.

Personally, I implement properties, because I keep scripting in mind as I host a scripting engine as well. It's also benefitial for me when I write the scripts as well as I can use the "property syntax".

--
...Coca Cola, sometimes war...

Re: ActiveX TypeLib Practices: property or method?

Jörgen Sigvardsson3-Sep-04 8:41

Jörgen Sigvardsson

3-Sep-04 8:41

By the way, why are you using pure dispinterfaces if you access the objects from C++? You could do yourself a favor by making them dual instead. Then there's no need for dispatch drivers and the like. Then you just QueryInterface() and call methods as you go.

--
...Coca Cola, sometimes war...

Re: ActiveX TypeLib Practices: property or method?

KFournier3-Sep-04 9:15

KFournier

3-Sep-04 9:15

Thanks for your input. I'm glad to hear such a strong arguement for using properties.

Jörgen Sigvardsson wrote:
By the way, why are you using pure dispinterfaces if you access the objects from C++?

I'm using pure dispinterfaces simply because I'm using MFC to develop my controls and the VC++ 6.0 Class Wizard uses them. I'm just taking advantage of a little automation.

Is my client still there?

FearlessBurner2-Sep-04 6:29

FearlessBurner

2-Sep-04 6:29

I have an out-of-process exe server which was a one-to-one connection with a client. The client will start the exe server when using CoCreateInstance() in the usual way, generating an IMyInterface pointer. In normal execution, when the client process closes, Release() is called for the IMyInterface pointer, which terminates the server.

Unfortunately, there are some instabilities in the client executable over which I have no control. If the client crashes, which it does particularly during testing, then the normal IMyInterface Release() is not called, and thus the server does not get released and stays executing.

What I would like to be able to do is to test whether the client is still running. My problem is that the wizard-generated event sink code does not return an E_FAIL or similar error code, if the connection fails. I know that there are several ways in which I could address this problem, each with their own disadvantages. I would really appreciate if anyone could offer any help on this, of advise me whether I am missing something obvious.

FB

Re: Sorted :)

FearlessBurner6-Sep-04 1:50

FearlessBurner

6-Sep-04 1:50

Fixed by these changes:
A) Added a Test method to the event sink which is empty at the client method
B) When the server tries to close itself, it calls the above Test method. If an RPC error results, it is assumed that the client has broken.
C) Server shutdown is firstly achieved by calling CFrameWnd::OnClose() (as an MFC frame window). If the client has been broken, then AfxPostQuitMessage(0) is called immediately afterwards to terminate the process.

Effectively the call to AfxPostQuitMessage does an AfxOleUnlockApp() so that the server can quit gracefully. I discovered this by debugging the MFC code.

The only bad thing about this approach was the need to add another event method to the sink, and to hardwire a call to this in the server. Does anyone have a better approach to this?

Out-Process Vs In-Process COM Performnace Issue

DeepakSharma2-Sep-04 1:23

DeepakSharma

2-Sep-04 1:23

Hi I would like to have some valuable suggestion from you people.

Let me explain me my problem scenario.
I have an xml file which will serve the clients as a database. Now the situation is that this file could be accessed simultaneously from different clients, so the maintaining the state of the file becomes a serious concern. Now what we have thought is to make an out-of-process COM exe that will expose 2 interfaces to the client through which they can extract the record. As the 2 clients can call the interface at the same time we have used the critical section in each function call. In this way all the call will be serialized.

The second approach is to make an in-process dll and use some synchronization objects to handle the simultaneous calls.

Now the thing what I want to know is that which is the better approach keeping in mind the performance, maintainability and robustness.

What I think in any way as the database file is single the calls need to be serialized at any level regardless they are from the same process or different process. Also when we will use the in-process dll we need to use the mutex for synchronization purposes which itself is very heavy as compared to the critical section (out-of-process exe).

Please provide your suggestion as soon as possible as I have to face my boss tomorrow with the design issues.

Thanks

Re: Out-Process Vs In-Process COM Performnace Issue

geo_m14-Oct-04 1:55

geo_m

14-Oct-04 1:55

I would choose the in-process solution personally, not only because the out-of-process calls are quite slow (even mutex complexity is nothing compared to it) but you can drop into the problems with security settings at the specific machine.

But anyway it seems that it's a bit late for my suggestions Frown | :(

explorer bar

rolati1-Sep-04 23:45

rolati

1-Sep-04 23:45

Can anyone tell me where I can find some information on what explorer bars can contain? Can they display HTML, graphics...?

Rola

Re: explorer bar

Anonymous2-Sep-04 8:50

Anonymous

2-Sep-04 8:50

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/Shell/programmersguide/shell_adv/bands.asp

How to get the application Root Directory runtime?

Member 7436551-Sep-04 16:46

Member 743655

1-Sep-04 16:46

I've searched and can't find not way for my servicedComponents to learn about the application Root folder of the COM+ Application, the application.Manifest trick does not solve my problems, I am thinking that there should be away to access this property of COM+ in the .net framework, traverse throght the com+ catalog in he unmanaged code seems ugly,
any one can enlighten?

thanks

COM release build problem

alex.barylski31-Aug-04 20:36

alex.barylski

31-Aug-04 20:36

What's causing the following error?

I'm using VC++ 6.0 on WinXP Home???

Any takers? Smile | :)

Linking...
Creating library ReleaseMinSize/mycom.lib and object ReleaseMinSize/mycom.exp
LIBCMT.lib(wwincrt0.obj) : error LNK2001: unresolved external symbol _wWinMain@16
ReleaseMinSize/mycom.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

Thanks Wink | ;)

How do I print my voice mail?

Re: COM release build problem

Rory Solley31-Aug-04 21:30

Rory Solley

31-Aug-04 21:30

You need to provide an entry point for the executable. Goto Project settings, Linker, Output and type wWinMainCRTStartup into the "Entry-point symbol" field.

Re: COM release build problem

alex.barylski1-Sep-04 9:10

alex.barylski

1-Sep-04 9:10

Nada...

I have tried that before

And i've tried _wWinMain@16 and about a million others.

How do I print my voice mail?

Re: COM release build problem

ShaunOldale1-Sep-04 12:24

ShaunOldale

1-Sep-04 12:24

If you have not already tried this, remove _ATL_MIN_CRT from the project settings.

I had the same problem when I needed exception handling in a recent ATL project.

Cheers
Shaun

Re: COM release build problem

alex.barylski2-Sep-04 18:33

alex.barylski

2-Sep-04 18:33

Did you ever know you my hero Smile | :)

* sings like Bette Middler - Or more like that weird girl on WB superstar!!!

That worked...

Schweet!!!

Thanks you kindly!!!

How do I print my voice mail?

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.