Re: default properties on COM interfaces - COM Discussion Boards

Dave Bryant1-Jul-03 16:26

1-Jul-03 16:26

I've encountered a probably setting a default property on a COM interface I am generating. This interface, IField, is generating dynamically from my application, and extends another of my interfaces, IMessageComponent (also generated dynamically, which inherits from IDispatch). I want to make the Value property (which is read/write) the default of the IField interface, so i've the the ID to zero.

When using it from VB6, it sometimes works. It always works if I am reading the value from the default property.
e.g. str = msg.Segment.Field This always works

However, when setting the value it does not work if there the object is set indirectly. For example:
Dim fld As Test.Field
fld = msg.Segment.Field
fld = "blah" This always works

msg.Segment.Field = "blah" This never works works - VB always gives a compile-time type mismatch error.

Has anyone encountered this previously and know of a workaround?

Cheers

Dave
http://www.cloudsofheaven.org

Re: default properties on COM interfaces

Mil101-Jul-03 18:59

Mil10

1-Jul-03 18:59

Hi Dave,

Dim fld As Test.Field<br />
fld = msg.Segment.Field<br />
fld = "blah" This always works

I couldn't understand how the code above works without error.
Because 'fld' is just a variable of type IField, not an instance of IField. So the statement 'fld = msg.Segment.Field' shouldn't work. Even if u r calling

CComObject<CField>* pFld;<br />
       hRes = CComObject<CField>::CreateInstance(&pFld);

in Segment, that line should be set fld = msg.Segment.Field. Then fld = "blah" is ok. Because now field is refering to an active instance of IField in 'msg.Segment'

Sameway if msg.Segment.Field = "blahh" gives a type mismatch error, then msg.Segment.Field might not be an active instance, make sure u had called hRes = CComObject<CField>::CreateInstance(&pFld);

does this make sense...?

best wishes ... mil10.

Re: default properties on COM interfaces

Dave Bryant2-Jul-03 10:35

Dave Bryant

2-Jul-03 10:35

You're right, the line should be "set fld = msg.Segment.Field" - it was that in my VB code, but as I am a C++ programmer, not a VB 'programmer', i forgot it when i wrote that message.

However, i can guarrantee that the object does always exist - that's why I don't understand why it doesn't work...

Anyway, I'm just looking for ideas...

Dave
http://www.cloudsofheaven.org

Re: default properties on COM interfaces

Mil102-Jul-03 18:46

Mil10

2-Jul-03 18:46

Try to debug into CField::put_Value from vb exe and see what is happening inside CField::put_Value . Since u r not a vb prgmr , i donno whether u familier with debugging into an atl dll from vb.
anyway FYI -
Just create the vb app with the code msg.Segment.Field = "blahh" into an EXE.
Then change ATL project build setting to Win32Debug
Goto "Project->Settings->Debug->Executable for debug session:" and browse the VB exe path into the text field.
Put break point in CField::put_Value , then run the ATL project by F5.

best wishes..mil10

Re: default properties on COM interfaces

Dave Bryant2-Jul-03 18:49

Dave Bryant

2-Jul-03 18:49

I do know how to debug from VB, but unfortunately it's not going to help here. It's a compile error, not a runtime error.

Dave
http://www.cloudsofheaven.org

Re: default properties on COM interfaces

Mil102-Jul-03 21:56

Mil10

2-Jul-03 21:56

Seems very strange..if u mind to send me the source code I am ok to debug. otherwise try unregister/reregister or more safely try on another mechine. Because I had faced almost simialr prblm early. Initialy the DISP_ID was 1. After registration with 1, I changed it to 0 to set it as default. Again registred the component but, showed err in my mechine but worked fine in another mechine( with fresh registry entries).

best wishes..mil10

Re: default properties on COM interfaces

Dave Bryant3-Jul-03 8:55

Dave Bryant

3-Jul-03 8:55

Thanks for the offer, but don't worry about it. I'll give it a go on a clean machine and see what happens. If that doesn't work, then i'll just leave it as is - the default property would be a nice extra to have, but it can still be used fine without it.

Thanks a lot for your help.

Dave
http://www.cloudsofheaven.org

Re: default properties on COM interfaces

Vi23-Jul-03 21:43

Vi2

3-Jul-03 21:43

Because "Field" property gives an object (some interface like IField or IDispatch), the VB makes some additional action.

fld = "blah"

This always works because the VB cannot assign the string value to the object variable. He should call some method(property) for this. And this action is a calling of property-by-default (with dispid=0) if this property is presented by the object.

msg.Segment.Field = "blah"

This never works because the VB will call the "Field" property of msg.Segment object with parameter which equals to "blah". It gives the compilation error because probably the "Field" property does not have the parameters.

Try the following construction

msg.Segment.Field() = "blah"

With best wishes,
Vita

Sending events

act_x30-Jun-03 4:42

act_x

30-Jun-03 4:42

I am working in a framework in my COM server where I have a thread . From this thread I need to send events out of the Server which I am not able to do normally . What should I be doing in order to be able to send out events !

Related article in MSDN is

Events and threads
The good doctor alluded to problems he was having with events and threads earlier.

Here's the basic rule: Unless you do something special (more on this later), you always have to fire your events from the same thread that called IConnectionPoint::Advise. You may not normally start another thread and fire events from that thread. Why? Well, to fire an event means that you call into another object using an interface pointer.

But, in COM, you are never allowed to pass interface pointers between threads; you must marshall them instead. This is not terribly difficult to do, even though it involves calling the API with the world's longest name: CoMarshalInterThreadInterfaceInStream. (Perhaps it's named for a small town in Wales.)

You pass the stream pointer to the other thread (guaranteed to work in this special case) and call CoGetInterfaceAndReleaseStream in the new thread to get a marshalled interface pointer. Unfortunately, ATL's event firing implementation doesn't marshall the interface pointers, so it'll take some work to fire events from another thread.

In two common cases, this isn't an issue. If you're firing the event in response to a Windows message, such as a mouse button down message, you'll be okay. You'll be running on the same thread you were created on when you received the message.

Or, in our example, we fire an event in response to a method call. Again, this is safe, because the method will be called on the same thread you were created on.

It's only when you explicitly create a thread yourself (such as to sleep, or do some background processing) that firing events from the newly created thread becomes difficult.

So Do I have to Marshall the Interface to the COM server or all the IConnectionPoint Interfaces ?

When whould this occur?...

CherezZaboro30-Jun-03 3:37

CherezZaboro

30-Jun-03 3:37

CLSIDFromProgID returns CLSID successfuly but CoCreateInstance fails saying that that class is NOT registered? WTF | :WTF:

Re: When whould this occur?...

Vi230-Jun-03 4:34

Vi2

30-Jun-03 4:34

CLSIDFromProgID and CoCreateInstance use the different branches of Registry.

Also, you can ask the other context for the object in CoCreateInstance. For example, CLSCTX_INPROC_SERVER for out-proc server (EXE server).

With best wishes,
Vita

Re: When whould this occur?...

CherezZaboro30-Jun-03 5:48

CherezZaboro

30-Jun-03 5:48

Hmm. Ok. But I already call CoCreateInstance with CLSCTX_INPROC_SERVER to call out-proc server. How did you know? Smile | :)

Are you saying that I should try different one?
Could there be something wrong with my out-proc server?

Re: When whould this occur?...

Vi21-Jul-03 1:51

Vi2

1-Jul-03 1:51

Try to use CLSCTX_LOCAL_SERVER instead.

With best wishes,
Vita

OleCreateFromFile and OleCreatePictureIndirect

Florin Ochiana28-Jun-03 22:12

Florin Ochiana

28-Jun-03 22:12

Hi,

I use OleCreateFromFile to create some ole bitmaps at the start of my program. This bitmaps are embeded in some richeditctrl's. The problem is the more bitmaps I have, the longer it takes for my program to load (because it reads the files from the disc).

I want to use OleCreatePictureIndirect which creates ole's from HBITMAPS that I can build from my resource bitmaps, reducing in this way the loading time. But I dont seem to get this function in vc7.0. Can you help me with this, please?

Thanks

-----
We are what we repeatedly do. Excellence, then, is not an act, but a habit.

Excel COM Add-In

Anonymous27-Jun-03 13:09

Anonymous

27-Jun-03 13:09

Hi,

I intend to write a permanent MS Excel COM Add-In (dll) for experimental data analysis in VC++. Though, the registration in Win2k registry works fine, I can’t add the generated dll to Excel using Extras->COM Add-Ins->Add in the Excel menu. The file don’t occurs in the dialogs list view after click on the add-button from the open-dialog.

I’ve been trying to get a clue following the chapter “Building a minimal COM addin” from Amit Dey’s excellent article “Building an Office2K COM addin with VC++/ATL” as well as several other MSDN-articles, however without success. It works fine with Outlook2k but won’t with Excel2k. What’s my mistake? Any ideas?

Thanks in advance for any respond.

Confused | :confused:

Mike

variant data type..

safee ullah26-Jun-03 19:46

safee ullah

26-Jun-03 19:46

hi there

i wanted to know what is the variant data type (VT) for a LONG POINTER?

ie for long it is VT_I4 but what about a long *??

thanks
regards

Re: variant data type..

Fredrik Skog26-Jun-03 20:19

Fredrik Skog

26-Jun-03 20:19

You cannot pass pointers between COM-objects.

Cheers,
Fredrik

"Felix qui potuit rerum cognoscere causas."

Re: variant data type..

Vi227-Jun-03 0:56

Vi2

27-Jun-03 0:56

The variant, which contains the pointer to long value, has .vt==VT_BYREF|VT_I4 and .plVal==&long_variable.

long i = 77;
VARIANT vi;
  vi.vt = VT_BYREF | VT_I4;
  vi.plVal = &i;

With best wishes,
Vita

COM/ASP

Kant26-Jun-03 5:12

Kant

26-Jun-03 5:12

We got old COM component and it's used to retrieve ASP built-in objects. The COM component is using IScriptingContext interface. As per MSDN, it's an obsolete[^] interface and it suggest to use the IObjectContext interface.

Anybody know more about this. In meanwhile I will continue my search on MSDN. Wink | ;)

I haven't worked with ASP objects so far and the guy who wrote left the company.

"...if you don't want to hear things that piss you off don't piss off other people. SIMPLE." - Steven Hicks
This signature was created by "Code Project Quoter".

Re: COM/ASP

Mil1030-Jun-03 20:38

Mil10

30-Jun-03 20:38

Hi,

Yes u r right. IScriptingContext interface - as per MSDN, it's an obsolete interface. But , still u can use it. Because it is working even in IIS6.0
U can also use IObjectContext if your component need com+ transaction support. Otherwise IScriptingContext is enough. (But use at ur risk Wink | ;)

. Because future versions of IIS may stop supporting IScriptingContext). U can use microsoft provided wrapper class Context.cpp and Context.h to get the ASP objects from IObjectContext.

best wishes...take care ..bi..mil10

converting an idl file to .h

si_6926-Jun-03 0:47

si_69

26-Jun-03 0:47

Hi,

I am trying to generate a .h file from an idl file.
For this I am using Microsoft's MIDL Compiler.

I gave the following command:

midl myIDl.idl /h myidl.h

But when I run the command line exe, it gives me an error message saying:

midl : command line error MIDL1001 : cannot open input file oaidl.idl

can ne1 help

thanks

simon

Re: converting an idl file to .h

valikac26-Jun-03 5:30

valikac

26-Jun-03 5:30

Import oaidl.idl in the IDL interface file.

Kuphryn

Re: converting an idl file to .h

Vi227-Jun-03 1:24

Vi2

27-Jun-03 1:24

You should provide the path where oaidl.idl is placed.

PS
You can include your IDL-file to any your Studio project (temporary) or make the small project for this.

And use Settings... for IDL-file to set necessary options. And compile it.

With best wishes,
Vita

Problem in passing structure pointer via Interface

mpb24-Jun-03 20:48

mpb

24-Jun-03 20:48

Hi,

I have created COM EXE server and it has lot of structures in it. I have defined all the structures in IDL file. Now I am developing one method which passed the Structure data to client through structure pointer in the method. Only this method in not working. Other methods, which passes BSTR are working OK. What is the problem ?

Shall I need marshalling here? I gone through lot of material but I am not able to find sample code for marshalling. Can some body help me in this regard also ?

Regards,
MP

Re: Problem in passing structure pointer via Interface

Aravinthan25-Jun-03 3:03

Aravinthan

25-Jun-03 3:03

Create your proxies again using nmake.exe utility.. it shall work fine..

<hr>
Visit me:
http://www2.domaindlx.com/earavi/
When you know something.. its meant to share with others :-) for otherwise that knowledge has no worth:-)
mail me:
aravinthan@rediffmail.com
<hr>

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