|
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
|
|
|
|
|
Dear all, i'm developing an activex component to use in a web application. my task requires using a dll to do some work...
When i try to add it to the references of the project i get the message of "can't add a reference to the specified file"
I'm using Visual Studio 6 and vb6 as a language
Any help or hints would be appreciated
Thanks in advance 
Best Regards
3ala2 
|
|
|
|
|
just3ala2 wrote: Dear all, i'm developing an activex component to use in a web application. my task requires using a dll to do some work...
When i try to add it to the references of the project i get the message of "can't add a reference to the specified file"
I'm using Visual Studio 6 and vb6 as a language
It sounds like you are trying to add a reference to a dll that isn't a COM dll. VB6 does provide a way to access them, but it involves creating a module file and writing code to import all the functions that you need to call in the dll.
Nathan
|
|
|
|
|
I c
Thanx nathan, i found another dll that does the same job and can be added as a reference 
Best Regards
3ala2
|
|
|
|
|
Hey ,
Can you please explain the diffrence between .idl and .h file?
Also How to create a new .idl file in VC6?
Thanks,
Ash.
|
|
|
|
|
The idl-File is the input for the midl-compiler which creates an _i.c and .h file for further use. See MIDL-Compiler for more information. For creation of an idl-file use the ATLCOM-wizard in the VS.
|
|
|
|
|
I am learning COM. And has come to know about one of the Advantages of the COM over .dll file. That
It extends the functionality of (client)application without rebuilding.
I.e. If you make the changes in function of .Dll File which client application is using you need to recompile the application. But if you are using the COM you dont need to do recompilation of client application
But How ?? afterall the COM ( inprocess COM) is also a .dll
|
|
|
|
|
Well you don't necessarily have to rebuild the entire app that is using a dll when it changes. Think about how Microsoft provides patches or updates to DLLs. Do you need to rebuild your OS to use the new DLLS
As long at the function interface does not change you don't need to worry about rebuilding the app that uses the DLL.
COM provides interfaces that other app use. As long as the interface is not changed everything will be fine if the COM object has some code changes.
Let's say a code of a COM interface was modify like a bug fix, then the app using the old COM object will be able to use the new COM object because all it needs to do is CoCreate the COM object and Query for it's interface. This part remains the same in the app, so the app doesn't need to be changed.
|
|
|
|
|
I m thinking to learn COM but not getting from where to start ?. If u know about any good book please tell. If you can provide the link to the Ebook it will be gr8 HELP!.
Thnx in Advance.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
