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.
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.
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".
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.
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.
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?
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.
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
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?
i wrote an application which can communicate with excel.
I have build an dialog based project with automation.
The next step was including the classes from a Type Library (Excel.exe).
Now i can start excel via
and select Ranges and Fill Cells.
My Question is:
How to communicate with excel without starting excel.exe (in Taskmanager as an proccess).
Is it possible to do this.
I heard a lot of COM i always thought automation means COM.
My C++ Skills are not the best.
I won´t use ActiveX elements in my Project.
Is there any tutorial or can anybody help me to communicate with excel
without starting a excel.exe proccess.
Thx in advance.
Sorry for bad english.
thx for reply!!!
Your code is totaly correct ->SetVisible(true)
If i dont use:
Excel is hidden and not visible @ the Taskbar but i can
see it in the Taskmanager as an active process.
If i use:
Excel appears in the Taskbar and is started as proccess and application
My Question is:
Is it possible to communicate with excel without having an running excel.exe proccess?
I thought COM doesnt need an active procces to communicate.
Most Automation Application will be running when you create an instance of them in your application.
The reason being that for most operations to be performed, excel need to be running. This makes things a little complex sometimes. Like trying to do something that pops a dialog box only when certain conditions are met. Then the excel application seems like it is stale, but its waiting for a user to click on the "OK" button of the dialog it just popped.
Same applies to most members of MS Office family.
So, its a definitive NO, you cannot communicate with Excel without having a running excel.exe
COM Automation does require to have an active process.
This of it this way: if you start your program 3 times, you will have 3 different Excel applications running, and this is a good thing. You dont want a process intensive task to prevent your 2 other programs to wait when all they do is a simple task each.