|
Communicating with Excel.Application requires that excel be started. If your issue is that this application is visible, then you can probabaly find a visibility method in excel itself.
It should be something like m_pApp->SetVisible(false), althought i'm pretty sure my syntax isnt the right one.
Other than that, there is a package that is being sold that allows to manipulate excel at the file level but its not free. Can't remember the package name thought.
|
|
|
|
|
Hi darkbyte,
thx for reply!!!
Your code is totaly correct ->SetVisible(true)
If i dont use:
->SetVisible(false)
Excel is hidden and not visible @ the Taskbar but i can
see it in the Taskmanager as an active process.
If i use:
->SetVisible(true)
Excel appears in the Taskbar and is started as proccess and application
in Taskmanager.
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.
Thx darkbyte maybe anybody else can help too.
|
|
|
|
|
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.
|
|
|
|
|
As it is possible to
"Add to Favorites" using the IShellUIHelper,
is it possible to
set the homepage using IShellUIHelper?
|
|
|
|
|
Nope, it is not possible.
But you could always try and find which registry key keeps this information.
|
|
|
|
|
Hi,
How do I connect to my COM server, written with VS C++ 7.1 (2003). I have been writing COM servers and clients for about 5 years now. For the past 3 or 4 years, I have used the #import statement and the __uuidof operator with smart pointers to connect to my servers with no problem. Now when I try to use __uuidof() in a VS 7.1 client, it throws an exception "Class not registered" when it clearly is registered. Anyone know what's going on?
Thanks,
Royce
|
|
|
|
|
A better and safe way other than smart pointers is invoking the COM runtime and obtaining interface explicitly. Compile the IDL file to get a '.h' and '.c' file. Using CoCreateInstance and QueryInterface methods you can get interface without breaking the code in VC++ 6.0 as well as 7.0. If you are hardcore C++ programmer I suggest you use this method rather than smart pointers. If the same problem persists with this method then it really is a problem I can get with. You can get lotsa tuts on codeproject to using COM without smart pointers. If u need the code lemme know, I hav efunctional client-server code running. May ur problem be solved with this!!!
--:: VANDE MATARAM ::--
|
|
|
|
|
Vande,
Thanks - I'll try your suggestion.
Royce
|
|
|
|
|
Mayur,
Yes, please post your code. I have never tried what you are talking about.
Thanks,
Royce
|
|
|
|
|
Mayur Mahajan wrote:
A better and safe way other than smart pointers is invoking the COM runtime and obtaining interface explicitly.
How is that safer?  Raw interface pointers are almost always the source of memory leaks when dealing with COM. Raw interface pointers are for C programmers only, IMO.
Heck, COM is hard even with smart pointers. Why make it harder by using raw pointers? 
--
...Coca Cola, sometimes war...
|
|
|
|
|
I know COM is hard. And pointers in C++ is something people like to stay away  But I'm a c++ fan and like to get things done the hard way! Also using smart pointers is something like setting references in VB and too 'unornamented'  method to understand the workings of COM. /* And memory is sure to leak out of most progs unless u code with a cool head be it COM or C++ objects */
coding n debugging; two sides of same coin
|
|
|
|
|
Are you an error handling fetishist? 
--
...Coca Cola, sometimes war...
|
|
|
|
|
Maybe because I create a lot of errors in code and spend twice the time hunting for it
|
|
|
|
|
RFickling wrote:
Now when I try to use __uuidof() in a VS 7.1 client, it throws an exception "Class not registered" when it clearly is registered.
Uh.. __uuidof doesn't throw anything.
--
...Coca Cola, sometimes war...
|
|
|
|
|
No, but it indirectly invokes CreateInstance() which throws.
|
|
|
|
|
There is nothing wrong in using smart pointers and __uuidof for accessing com object in vc7. it shud work fine. there shud be something else is wrong.
u created the com as a vc7 atl project and what type of .net project was ur client app?
rgds..mil10
|
|
|
|
|
Yes, this project was created using VS 7.1. Using the project wizard, I created an ATL project, Attributed = false, Support MFC = true, Support COM+ = true, and Support Component Registrar = true. Using the Add Class wizard, I then added a ATL Simple Object with defaults. I don't see anything wrong with what I did.
Royce
|
|
|
|
|
thats fine.. what type of project was ur client app? whether it is a Console App(.net), win32 console app or an MFC appwizard exe?
|
|
|
|
|
The client is a MFC App wizard dialog-type application. My code is below.
I use the #import statement:
#import "ComServer.dll"
I define a member variable to hold a pointer to the interface in my dialog's header:
ComServerLib::IMakeKeyPtr m_ptrMakeKey;
This statement fails with a 80040154 error code: "Class not registered"
m_ptrMakeKey = ComServerLib::IMakeKeyPtr(__uuidof(ComServerLib::IMakeKey));
I have used this method of connecting to COM objects for years. I have no clue as to why it is failing. My registry shows the following keys:
The following registry keys show that the required registration has been done. These
keys were copied from the registry immediately after a successful build of the COM server.
The 'MakeKey Class' is registered:
HKEY_CLASSES_ROOT\CLSID\{1BB2A094-1C9E-4B3B-99CF-A92CD5E762A3}
The ComServer 1.0 Type Library is registered:
HKEY_CLASSES_ROOT\TypeLib\{2748E284-3101-4CB7-AF16-C52E02E2A71A}
The IMakeKey Interface is registered:
HKEY_CLASSES_ROOT\Interface\{1B68E9F2-D8F6-42C0-9D12-90255695E6DE}
|
|
|
|
|
Royce Fickling wrote:
uuidof(ComServerLib::IMakeKey);
Dude, you should be using __uuidof(<class name here>). You are using the interface name, and hence you are trying to create a COM object using an IID. It's the CLSID you want...
--
...Coca Cola, sometimes war...
|
|
|
|
|
Royce Fickling wrote:
uuidof(ComServerLib::IMakeKey);
U asked Royce to use __uuidof(<classname>) instead of IID; Does this return the default interface? By this technique how can I query other interfaces of my COM object?
Fortune favours the naive
|
|
|
|
|
Mayur Mahajan wrote:
Does this return the default interface?
No. In the microsoft compilers, structs and classes can be given compile time attributes. One of these compile time attributes is GUIDs. To interfaces, the IID is set as attribute. So __uuidof(IInterface) is equivalent to IID_IInterface.
Mayur Mahajan wrote:
By this technique how can I query other interfaces of my COM object?
pUnk->QueryInterface(__uuidof(IInterface), (void**)&pInterface);
It's not portable, but hey, who cares? I don't do COM development for anything but windows, and my compiler of choice for the windows platform is the one that comes from Redmond.
--
...Coca Cola, sometimes war...
|
|
|
|
|
An addition to Jörgen Sigvardsson's reply:
chk the .tlh and and the implimentation file .tli for any detailed info.
these files will be there in ur debug folder.
|
|
|
|
|
Hi Royce.. as Jörgen Sigvardsson already posted u shud have used the CoClass name instead of an Interface name in ComServerLib::IMakeKeyPtr(__uuidof(ComServerLib::IMakeKey));. Here replace IMakeKey with ur coclass name. chk idl for the coclass name.
rgds...mil10
|
|
|
|
|
I've been working on a COM Service project for about 2 months and early in the development process, i had to generate Proxy/Stub dll.
Today, after having a very evolved project, i try to figure out which data type prevents me from using the standard marshalling libraries. I've been browsing thru the net for about 1 hour and a half, trying to find which data type was 'forcing' me to have my own Proxy/Stub dll.
Then, i figure i'll unregister my Proxy/Stub dll and see if i can still acces my COM Service. Well, it works 
I guess during the growth of my project i changed whatever required that proxy/stub code and am now fully automation compliant 
Just needed to share this as this is not a question, but it sure feels good to know my project is full automation compliant.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
