|
Hi!
Is it possible to implement IShellView (need support for IShellBrowser) into an excisting shell extension without creating an explorer namspace extension or at least without creating a vissible namspace extension?
As far as I know you´ll have to use the interface IShellView to access IShellBrowser, am I right?
/Jii
|
|
|
|
|
I have a method in a activeX dll ( created in VB)
My program is in VC6:
I used #import to link with the DLL.
virtual HRESULT __stdcall TimeZone (<br />
BSTR mstrPlant,<br />
long mlngTime,<br />
long * mlngTimeDifference,<br />
enum ConneBD enmConneBD,<br />
struct _clsErr * * _arg5 ) = 0;
It is declared like that in .tlh
I call it this way:
time_t *ltime;<br />
long * timeDiff;<br />
ltime = new time_t();<br />
timeDiff = new long();<br />
*ltime = 0;<br />
*timeDiff = 0;<br />
time( ltime );<br />
struct _clsErr *m_E;<br />
hresult = m_t->TimeZone(OLESTR"01"),*ltime,timeDiff,BD_OR,&m_E);
hresult tells me that every thing worked fine but timeDiff return empty.
I get "type dismatch" from the struc _clsErr..
My parameter's types seem ok..
Can somebody see what I'm doing wrong?
thanks,
Lily
|
|
|
|
|
time_t is not automation compatible, I think. try a DATE or a VARIANT(VT_DATE) instead of time_t.
|
|
|
|
|
Might seem like a dumb question but i cannot get Copy to work from my app to explorer. I would appreciate any little nudge in the right direction.
I'm new to the shell so go easy.
|
|
|
|
|
For those interested you have to add this item to the clipboard yourself. For any kind of a decent solution you must implement IDataObject. Trivial once you know what to do.
|
|
|
|
|
Hi Guys,
I have no idea what to do else with the implementation of CoInitializeEx( NULL, COINIT_MULTITHREADED) if I use it in the same process with MS DAO library. The problem appears when the CoInitializeEx(..) is already called and I try to open a database file using DAO functions. In that case that file is not going to open. But if I replace CoInitializeEx(..) by CoInitialize(0) it works fine and database file is opened.
Best Regards,
Jawid
|
|
|
|
|
You can't call CoInitializeEx with COINIT_MULTITHREADED if it's already been called with a different threading model specified. I don't believe the DAO library is thread safe. In order to access DAO from multiple threads, you'll have to create your own free threaded object wrapping whatever DAO calls you need, and syncronizing access to the DAO library.
Mark
|
|
|
|
|
Hey Gang,
I am on the verge of panic today because I need to quickly develop a solution for a distributed analysis program. Thanks for taking the time to respond if you get a chance.
I have an exe that uses an XML DOM to represent the status of a system. The DOM is wrapped in an ATL interface that provides some convenience routines for manipulating the data in the DOM. For discussion I am going to refer to the ATL interface as the CurrentStateInterface.
I would like to share access across computers to an instance of the CurrentStateInterface. Ideally remote systems would be able to connect to the server application through an ATL interface and request the CurrentStateInterface. Once the interface is marshalled to the remote system, the remote system could make calls to the CurrentStateInterface which would manipulate the data in the DOM on the server.
I have read a few articles from the MSDN. One article suggested several possible solutions: Singleton objects, File monikers, CoMarshlInterface/CoUnMarshalInteface, Custom class objects, Custom monikers. I know some of these would work better than others. From what I have read, the file monikers look like an appropriate solution but I would look to someone with more experience for guidance.
I am hoping that someone has done something similar and can share his/her knowledge and experience. Any good suggested reading would be appreciated also.
Thanks very much for your time!
Hawk
|
|
|
|
|
Hawk,
You did not mention whether or not the existing interface is free threaded or not. If it is free threaded, I would think you could create a service executable that would run as an ATL server. I think you would have to implement it as a singleton object (so that every instance was the same instance). Access across a network would then be possible by specifying what machine to create the instance on. If the interface is apartment threaded, I would create a batch of worker threads, create one instance of the CurrentStateInterface in the main thread, then upon thread initialization, marshal the interface across, and make sure all access to the object (in any thread) is protected through a global critical section. Your main thread would be dispatching messages to your worker thread, which would do the core of the processing, returning the results from the CurrentStateInterface and maintaining state information across different sessions.
If the CurrentStateInterface is apartment threaded, I think you have a bit of work ahead of you, if it is free threaded, I'm pretty sure it'll be a straight forward thing (make sure your using the free threaded version of the XML DOM!).
Hope that helps.
Mark
|
|
|
|
|
Mark,
Thanks for the great response. I will work in the direction you have suggested. I am kind of weak in the COM thread model details. I have created my CurrentStateInterface with the VC++ default attributes which is apartment. Do I need to reimplement the interface through class wizard as free threaded or is there an easier way to change the threading model? It seems fairly trivial to make a singleton object and to instantiate the free threaded version of the XML DOM.
Do you know of any example code that is implemented like you have laid out, with a singleton object?
Thanks again for the great information!
|
|
|
|
|
You do not need to rerun the class wizard to change the threading model from apartment to free threaded. I believe you can find this under registry resource for your project (just change where it says 'apartment' or 'both' to 'free'), after you make the change be sure to re-register the interface. As far as creating a singleton object is concerned, there is an ATL macro 'DECLARE_CLASSFACTORY_SINGLETON' which should do the trick for you, the macro basically specifies that the class CComClassFactorySingleton will be the object which is queried upon every call to CreateInstance allowing a single instance to be passed for each call.
The only caveat is that you must make sure that the CurrentStateInterface is thread safe. This means protecting access to any shared objects or data (by shared, I mean objects that may be modified across threads). If everything is strictly read only, I don't think you have anything to worry about, but if you are modifying data, you must make sure you wrap these parts of the program in critical sections to correctly synchronize access these to objects.
Unfortunately, I don't have any code which I am able to share with you implementing singleton objects. There should be many examples however in MSDN. Do a search on the DECLARE_CLASSFACTORY_SINGLETON macro and see what you come up with.
Cheers!
|
|
|
|
|
I have a small & simple COM Server DLL (in straight C++). At the moment I'm not using ATL or MFC. It's all "pure" C++.
Now I want to add a dialog, and that dialog is going to use a List control within. The easiest (and perhaps only?) way to do this is via MFC.
What's the *minimal* amount of work I'd have to do in order to get enough MFC stuffed in to use CDialog and basic Common Control stuff in my DLL?
One obvious option is to have another .DLL using MFC and have my COM server call into that, which I'll do if that's much easier. But maybe there's something better.
Suggestions?
|
|
|
|
|
You can also use ATL windowing classes to do just this. Checkout CDialogImpl<> classes for dialogbox support. Similarly Listboxes and other common controls are also supported by ATL common control wrappers. You might even find ATL windowing a tad easier than rigging MFC support to your COM project at this stage.
|
|
|
|
|
I really should knuckle down and learn the ATL basics. Maybe this is the excuse I need. How easy is it to retrofit minimal ATL support?
I'm kinda "old school" in that I dislike over-use of "libraries" that hide too much stuff from me. But I'm willing to trade that off for *some* convenience. If you were around me in the early days of MFC when half my time was spent fixing *their* bugs, usually in non-overridable MFC code, you'd understand. 
|
|
|
|
|
|
I'm trying to write a function which returns a pointer to itself from my ATL C++ code to a VB application. My ATL object uses dispinterfaces to be compatible with VB. In my IDL, I declare the my function:
[id(1)] HRESULT GetComponent ([out, retval] IDispatch *pRetval);
I implement the function OK and return a pointer to IDispatch that I've obtained with QueryInterface. Oh, this interface is part of a coclass alled "MyControl". So GetComponent basically returns QueryInterface on "this". (And it works, too )
I declare the interface as "oleautomation". Now using the Visual Basic object browser, I can see my GetComponent method and it's returning an "object". Now, I can set it OK if I set it as an object:
Dim Test as Object
Set Test = oControl.GetComponent ' oControl is type MyControl
However, if I declare "Test" as type "MyControl", I get a type mismatch:
Dim Test as MyControl
set Test = oControl.GetComponent ' Causes a type mismatch
Help! I just cannot get this to work. Is there something i must mark the IDL with, or is this a Visual Basic issue?
Thanks in advance
Jon
|
|
|
|
|
You should specify pointer to interface pointer to return your object.
[id(1)] HRESULT GetComponent ([out, retval] IDispatch* *pRetval);
Sure to call AddRef() on it before the function's exit.
With best wishes,
Vita
|
|
|
|
|
hello sir ..
I require some help from the programmers. I want to have a program which could scan all the HDD present in the network with thier Volume Serial Number ....since Volume Serial Number is the only way to uniquely identify a HDD
and store the output to a Microsoft Access Database file.
At a particular amount of time it should tell that a particular HDD with this volume serial number is connected or not?
somone told me that this can be done with WMI and the output can be taken in access file...
plzz help me
--thnx
waiting for a quick reply...
|
|
|
|
|
Hi,
I want to subscribe to events from an in process ATL COM object. This object is instantiated in a seperate process. I know the code I'm using to generate the events is working properly, but I don't know how to 'grab' the correct instance of the COM component so I can receive these events. If I call CoCreateInstance, I'm creating a new seperate instance of the same object. How do I retrieve the running instance of an inprocess COM object ? Is this possible ? Is there some example code I can look at ?
Mark
|
|
|
|
|
I know only one way how to solve your problem here. You have a choise to create an out-of-process COM object and make just a single instance of it in the memory. That means by any calling of CoCreateInstance(..) you connect just to that single instance of your COM object.
For creation of a single instance in Visual C++ ATL you can use a macro:
DECLARE_CLASSFACTORY_SINGLETON( CMyCass )
Jawid
|
|
|
|
|
Your in-proc object must register yourself in ROT by RegisterActiveObject(). Then any client can retrieve it by GetActiveObject() and subscribe to events.
With best wishes,
Vita
|
|
|
|
|
i have created two com classes in ATL A and B.The class B
also fires event . if i declare an object of class B in
visual basic using WithEvents keyword and then create its
object using NEW keyword,evenrything runs fine and i can receive events in vb client.
But the problem is ,i dont want to create the Class B object in Visual basic ,instead i have method in CLass A
which creates the object and returns the interface to
vb client,now when Object B fires event the com server crashes.
can anybody help me how to solve this problem.
|
|
|
|
|
There is no real problem.
Dim WithEvents bb As B
...
Set bb = New B
or
Set bb = a.CreateBObject
are equal to receive the B events.
With best wishes,
Vita
|
|
|
|
|
I am craeted a ComAddin for Excel using MFC;And I created a ExcelAddin(Save work book as a addin).
in the ComAddin I wont to access ExcelAddin's sheet.
How to access objects of ExcelAddin?
|
|
|
|
|
Hi, all
Some problems about ATL Com:
1.I have create two ATL Object: CStudent and CTeacher .
The simple source code listed as follow: (some code auto generated by ATL have been skiped)
class CStudent
{
private:
long m_age;
public:
CStudent():m_age(10)
{
}
//...other code auto generated by ATL
};
class CTeacher
{
private:
IStudent* m_aStudent;
public:
CTeacher()
{
//create an instance of the com
CoCreateInstance(CLSID_Student,NULL,CLSCTX_ALL,IID_IStudent, (void**)&m_aStudent);
}
//...other code auto generated by ATL
}
2.Then I add a "IStudent * OneStudent" property for ITeacher ,to access the m_aStudent.
The implemention of the property are listed as below:
STDMETHODIMP CTeacher::get_OneStudent(IStudent *pVal)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState())
// TODO: Add your implementation code here
*pVal = * m_aStudent;
return S_OK;
}
STDMETHODIMP CTeacher::put_OneStudent(IStudent *newVal)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState())
// TODO: Add your implementation code here
*m_aStudent = *newVal ;
return S_OK;
}
3.Now I type some VB code to test the com ,but some compiler errors occurrs.
VB Code:
Dim s As Student
Dim t As New Teacher
s = t.OneStudent
the last sentence "s = t.OneStudent" have compiler errors.
Errors:function or interface marked as restricted ,or the function use an Automation type not supported in Visual Basic
I guess the errors caused by the type dismatch between IStudnet and CStudent.But I did not know how to resolve it .
So who can tell me how to return the m_aStudent that can be supproted in vb??
thx.
Regards.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
