|
donguy76 wrote: I try to call a function inside a aggregated interface IMyInterface
and it pops up this error ->
Run-Time Check Failure #0 - The value of ESP was not properly saved
across a function call. This is usually a result of calling a
function declared with one calling convention with a function pointer
declared with a different calling convention.
I only have the obvious ideas. What calling convention is GetValue declared as?
Nathan
|
|
|
|
|
i am trying to use dll created in VC++ in ASP.Net but it gives an error of Security i have try caspol but still it gives an error.
Waiting for solution
Best Regards,
Chetan Patel
|
|
|
|
|
Does anyone know how the Groove 'Folder Sync' button is added to the standard Windows Explorer toolbar?
|
|
|
|
|
Hi,
Why we need COM. I know i have asked this question already, but i need direct answer in line or two
Thanks
|
|
|
|
|
Nandu_77b wrote: Why we need COM. I know i have asked this question already, but i need direct answer in line or two
We need it as a binary standard for program modules to communicate. This can make upgrading modules easier if everyone follows the rules.
Nathan
|
|
|
|
|
|
If you are interested in a clear but complex explanation of what the original motivatations were for creating COM, try to find a copy of "Essential COM", by Don Box. That book will also describe the basic structural layout of the binary components.
|
|
|
|
|
Hello Friends,
I've a problem with some com+ components developed in vc++, and running on w2003 sp2, the problems is simple, when an error happend in the component (yes it can happend on best families with big loads  ), the component manager must close this component and recycle it, but some times, the system thows a message to the OS console, this message it's the well known:
dllhost - Application Error
The instruction at "0x1002650d" referenced memory at "0x0000000". The memory could not be "written".
Asking the user to continue or debug.... opsss user interaction on a service is not a good idea 
Sometimes this is easy to solve, will you think, just correct your code, but other times, this only ocurr with high load, or networks errors that make your program fail, and the component manager must do his job 
When a small number of this messages (20/30) are in the console, the component manager fail and doesn't do his job, at this moment the component manager it's down and you will manualy kill dllhosts or interact with the console  !!
¿Does any body knows how to solve this kind of problem, preventing component manager to ask for user interaction on an error?
Regards,
Vider
-- modified at 8:00 Tuesday 18th September, 2007
|
|
|
|
|
Hi,
Actually i have 2 questions!
Somehow related.
I have a dll,lets call it database.dll,it reads a very big file when it is loaded,and with some procedures expoerted,i can access that data.
I was wondering if 2 or 3 applications that use that dll,does loading from file happen 2-3 times or only once?
i mean is those database datas global between dlls or not?
And,
I have a com server,in a dll file,that exposes 2 interfaces,for 2 different jobs.And also there are some global classes and functions that both of them use.
But both of them rely on procedures from my database.dll,again,should i forexample call 2 times loadlibrary,and initialize my database,or simply once is enough?(i load dll by loadlibrary,abd getprocaddress)
and if yes,is there any way i can prevent it?becouse loading that file takes around 20-30seconds which i dont want it to happen twice...
regards,
roozbeh
|
|
|
|
|
rozbeh wrote: I have a dll,lets call it database.dll,it reads a very big file when it is loaded,and with some procedures expoerted,i can access that data.
I was wondering if 2 or 3 applications that use that dll,does loading from file happen 2-3 times or only once?
i mean is those database datas global between dlls or not?
In this case, the file would be loaded 2 or 3 times. There are techniques like shared memory blocks that could allow you to load the file just once, but they will make things more complicated.
rozbeh wrote: I have a com server,in a dll file,that exposes 2 interfaces,for 2 different jobs.And also there are some global classes and functions that both of them use.
But both of them rely on procedures from my database.dll,again,should i forexample call 2 times loadlibrary,and initialize my database,or simply once is enough?(i load dll by loadlibrary,abd getprocaddress)
and if yes,is there any way i can prevent it?becouse loading that file takes around 20-30seconds which i dont want it to happen twice...
If a single application loads a dll twice, LoadLibrary will return the same instance of the dll both times, so loading only once should be relatively easy.
Nathan
|
|
|
|
|
Hy vokes!
How is it going.
My problem I should access a Interface over a Network with Malab. But when I tried it failed. A other Interface is no problem. I saw also Codes where this interface where used.
So here is what I am searching for:
Is there a possibility to get the Information, what COM Processes are activated over the Network?
And of course which command is it?
I hope someone can help cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|
|
Hi,
Right now I am developing a COM wrapper for some native C++ classes. Those native C++ class vastly use STL containers for their inputs and outputs. I provided COM interfaces for each of those containers in COM wrapper side. But when I want to pass in the collection of values from COM wrapper side to native C++ side, I am extracting the internal object (ex. a vector/list/map/set) in the COM wrapper side which holds the values.
For extracting the internal object (a STL container), I type casted the whole STL container to void ** and returning the value. Again, In my client side, i am retype casting to get the required STL container.
But for me, this typecasting is not working all the time. what is the best way to extract the internal object?
An example scenario:
in Native C++, the following code is working fine.
vector<int>* pV = new vector<int>
pV->push_back(10);
pV->push_back(20);
pV->push_back(30);
void *pVoid = (void*) pV;
vector<int>* oV = (vector<int>*)pVoid;
the above code is working fine, if it is native C++ side.
when it comes to COM,
ISomeCollection *pColl;
void *pV = NULL;
pColl->InternalObject(&pV);//signature is InternalObject (void**)
vector<int>* pVec = (vector<int>*) pV;
the above code is not working all the times.
Any suggestions for this code is highly appreciated.
thanks
Ng
|
|
|
|
|
true627 wrote: when it comes to COM,
ISomeCollection *pColl;
void *pV = NULL;
pColl->InternalObject(&pV);
vector* pVec = (vector*) pV;
the above code is not working all the times.
Any suggestions for this code is highly appreciated.
I don't think you're supposed pass things like pointers to STL objects in COM, because you're supposed to not make clients depend on implementation details of your class. In particular, a process called "marshalling" depends on things being spelled out in .idl files in ways that STL doesn't guarentee. I think it would be more appropriate to provide "Item" for accessing specific items of the vector, and "Count" for finding the vector's size. If you need more access than that, you can write a "Contents" method which returns a pointer to the vector's contents and the number of elements, which can be described in IDL enough to be marshalled properly.
Nathan
|
|
|
|
|
Hi Nathan,
Thanks for your suggestion.when I want to provide a pointer to my vector contents inside my COM object, what would be the best way to expose the pointer to the client other than void*? For my case, assume that vector item will be of any data item? I also have restrictions in using VARIANT in my interfaces.
thanks once again,
Ng
|
|
|
|
|
tictactoer wrote: Thanks for your suggestion.when I want to provide a pointer to my vector contents inside my COM object, what would be the best way to expose the pointer to the client other than void*? For my case, assume that vector item will be of any data item? I also have restrictions in using VARIANT in my interfaces.
Why can't you use VARIANT? The reasons I can think of not to use it would apply doubly to void **.
The usual ways to provide access to an array in COM are to use SAFEARRAY, or to use an interface which provides Item and Count properties. I think just returning a pointer of the sort you describe is discouraged because of problems when the client is in a different process, or a different computer.
Nathan
|
|
|
|
|
Hi,
I have dll which exposes 3-4 Interfaces(COM) . In one of the Interfaces I have added a new function say foo. I have modified the .odl file (for type library) , the .hpp file (which has the composition of the interface) and the .cpp file (for the definition of the function). I am able to build my dll and its working fine if I replace the new dll and .tlb file in the installation. But its not recognizing the new function when I am calling that function from a VB application. The old function( pre existing) are working properly. My new function takes 1 parameter. When I try to pass 2 parameters to this from the VB App the IDE tells that the function prototype doen't allow 2 parameters. This means the VB App is able to recognize the function (new one) 's prototype but it doesn't do the work the function is suppose to do. The control is not at all going to the new function.
It gives an telling the new function is an "Invalid Callee" (when I make a proper call with 1 parameter).
The registry entries are made when the product is installed. So I am not able to modify the registry entry for this particulat Interface. I am a beginner in COM and automation.
Please try to help
Thanks
|
|
|
|
|
 Slumberger wrote: I have dll which exposes 3-4 Interfaces(COM) . In one of the Interfaces I have added a new function say foo. I have modified the .odl file (for type library) , the .hpp file (which has the composition of the interface) and the .cpp file (for the definition of the function). I am able to build my dll and its working fine if I replace the new dll and .tlb file in the installation. But its not recognizing the new function when I am calling that function from a VB application. The old function( pre existing) are working properly. My new function takes 1 parameter. When I try to pass 2 parameters to this from the VB App the IDE tells that the function prototype doen't allow 2 parameters. This means the VB App is able to recognize the function (new one) 's prototype but it doesn't do the work the function is suppose to do. The control is not at all going to the new function.
It gives an telling the new function is an "Invalid Callee" (when I make a proper call with 1 parameter).
The registry entries are made when the product is installed. So I am not able to modify the registry entry for this particulat Interface. I am a beginner in COM and automation.
I think that what you're supposed to do here is create a new interface with the extra function. If you are implementing the object in C++, you can make the new interface a subclass of the old one, and make QueryInterface return the appropriate interface for both IIDs. Then to acces the new method in VB6, you will want to specify the new interface as the object type. If you are implementing the object in Visual Basic 6, things get more dificult.
Nathan
|
|
|
|
|
Nathan thanks for your response. But my dll is part of an existing product. Over the years according to new requirements new functions have been added to existing Interfaces. From the change history I did the same changes for a new function but got the error.
MSDN says that Interfaces are immutable, but we can modify them if version of ur dll doenst change.
I wrote an MFC COM server(an exe) which registers it self when invoked. I was able to add new functions to existing Interface.
Thanks again!
|
|
|
|
|
Slumberger wrote: Nathan thanks for your response. But my dll is part of an existing product. Over the years according to new requirements new functions have been added to existing Interfaces. From the change history I did the same changes for a new function but got the error.
By adding a new interface, I don't mean remove the old one. The idea is to not break existing clients. It's interesting that you were able to get away with this sort of thing before. (Perhaps I misunderstand what you were doing.) However, I know from experience that VB6 is not reliable about handling changes. I've often had trouble getting VB to use new objects and interfaces instead of old ones.
Slumberger wrote: MSDN says that Interfaces are immutable, but we can modify them if version of ur dll doenst change.
Do you mean the server dll, or the client dll? It's certainly not too bad if existing client dlls don't need to be changed, but VB6 is particularly bad about adapting to these changes. The main danger of modifying an interface that way is that someone might try to run a new client dll with an older server, in which the first sign that something is wrong could be when the nonexistant function is called, (and possibly not even then).
Slumberger wrote: I wrote an MFC COM server(an exe) which registers it self when invoked. I was able to add new functions to existing Interface.
I'd expect things to work better with a .exe because of the self registering behavior. Dlls are a bit harder in that it's easy to miss registering them, and Tlbs are even worse, since it's so difficult to register them. VB6 can register a type library provided that the type library isn't already registered. This could have something to do with your problem.
Nathan
|
|
|
|
|
So if I add a function to an interface(existing) and get a new build and package for my product and then install it in a new machine then the new function should work?
If registering is the issue then I guess above should work.
Please correct if I am wrong anywhere.
See my problem is like this. We have a product and this dll (com server) which exposes the intefaces get registered only when the product is installed and get unregistered if we uninstall the product. So if we modify an existing interface, build the com server dll containing that interface and then prepare a fresh package for install and then install it on a new nachine then the change(adding a new function to exiting interface) should work.
thanks in advance
|
|
|
|
|
Slumberger wrote: So if I add a function to an interface(existing) and get a new build and package for my product and then install it in a new machine then the new function should work?
Yes, it should work. However, if you are developing the dll in VB6, it is likely that VB changed a class ID or an interface ID when you added the new member, and that would defeat even the reinstall.
Nathan
|
|
|
|
|
Hi,
I am new to this COM stuff,but as i have gone through many documents would like to put some light on re-usability of Components.
as Interfaces are Immutable , you can create new Interface with additional methods you wants to add and implement Aggregation relationship with Original Interface.
Perry
|
|
|
|
|
Here is a snippet of my .h file
[
coclass,
noncreatable,
threading(apartment),
support_error_info("IAttachment"),
vi_progid("RMMAPIParserLib.Attachment"),
progid("RMMAPIParserLib.Attachment.1"),
version(1.0),
uuid("32ECA67C-0B5F-4489-B163-85C6CEDDB746"),
helpstring("Attachment Class")
]
class ATL_NO_VTABLE Attachment :
public IAttachment
{
.....
STDMETHOD(GetPropUNICODE)(LONG PropertyID, BSTR* pRetVal);
.....
}
and here is the function
STDMETHODIMP Attachment::GetPropUNICODE(LONG PropertyID, BSTR* pRetVal)
{
if ((PROP_TYPE_MASK & PropertyID) != PT_UNICODE)
{
return E_FAIL;
}
redmap::mapi::FoundProperty prop
= m_Attachment->FindProperty(PropertyID);
if (prop.second)
{
ATL::CComBSTR bstr (prop.first.lpszW);
return bstr.CopyTo(pRetVal);
}
else
{
ATL::CComBSTR bstr (L"");
return bstr.CopyTo(pRetVal);
}
}
Now my problem is I am getting the support_error_info error, what is wrong with the code?
Thanks
Jj
|
|
|
|
|
I think for the "support error info" to work, you class has to implement ISupportErrorInfo, which allows a caller to request extra information about the last error.
Nathan
|
|
|
|
|
Hi,
it hapend something very strange to me, when i call 'this' from inside the activeX control class, when i debug project with 'activex test container', it work fine, but when i start the release with iexplorer, when call 'this' it seems to get not activex control pointer to DC, but pointer to desktop DC. Because when iexplorer is not maximized, in the center of screen, when call 'this', it starts to write on the top left corner on the desktop, outside of iexplorer.
I get this pointer and then construct CClientDC dc(this); I tought that maybe this is null and get desktop dc, but when put condition if(){}, this is not null and enter int brckets.
Thanks.
-- modified at 2:17 Monday 17th September, 2007
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
