|
Here's the answer... FINALLY!!!
http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/wininet/tutorials/options.asp
And now it all works! Thx to all who have helped out!
/Tommy
|
|
|
|
|
I have met a problem of passing a String from my ActiveX to a javascript. I have the following interface:
testFunction([in,out]BSTR* p1, [out,retval]VARIANT* p2)
and my javascript:
var p1 = "ABCDEFGH";
var p2 = "PPPPPPPP";
p2 = testFunction(p1);
alert(p1);
alert(p2);
I can get the value of p2 successfully, however, p1 cannot. How can I pass value of string by reference from my ActiveX to my javascript? Thanks.
|
|
|
|
|
Data are passed by value and not by reference. I was also looking for a way to pass data by reference to a script and so far, I was unsuccessful. But if you have more info, let me know!
VOTD:"5. The Lord loves righteousness and justice;
the Earth is full of his unfailing love. "-Psalm 33:5
|
|
|
|
|
I know Javascript can only use Object or Array to pass by reference between ActiveX and Javascript. However, I am looking for ways that use Javascript String Object to pass the parameter by reference. Do you have any ideas?? Thanks.
|
|
|
|
|
I can't seem to find any example learn how to retreive contacts from Outlook. Or if found any it's in VB 
I'm also a bit rusty in COM, so what do I need to do when a function returns an IDispatch pointer? I'm sure that I need to cast the pointer, otherwise what would the IDispatch be use for?
Like in this example:
vIndex.intVal = 2;
pFolders->Item( vIndex, &pMAPIFolder );
pMAPIFolder->get_Name( &bstr1 );
Outlook::_ContactItem* pItem;
if( pMAPIFolder->get_Items( &pItems ) )
{
long i=1;
IDispatch* pItem;
pItems->GetFirst( &pItem );
}
Thanks!
---------------
http://www.edovia.com
|
|
|
|
|
|
Dear All,
i am working in COM , and i want to implement COM server
with out COM ATL. i have the whole implementation of COM
in C++ but i want to know that
which project of visual C++ 6.0 or visual C.NET should i
use ?
|
|
|
|
|
COM without ATL, can be done in any of the projects using pure C++. e.g. an in process dll server is the easiset as long as you include the right headers - <windows.h>
If you need to host it remotely at a later date, or just out of proccess on the same machine you can use DllHost.exe or even MTS or COM+
I would recommend going for an empty dll project, and start from there, but do use MIDL if you want your COM components to be used outside of C++, as it will create the type library that will be needed by other langauges e.g. VB.
The onbe thing to watch out for here is that you will have to implement your own DllRegServer and DllUnRegisterServer, which ATL would handle for you. DllCanUnloadNow, and DllGetClassObject as well thinking about it, but they are much less messy.
And you will need to implement IUnknown, and IClassFactory yourself too, but thats quite straight forward.
Does this make sense or have I missed the point? Thinking about it, you save you have implemented it, but you wnat to put it in a new project? Sounds like the easy bit.
|
|
|
|
|
There is no devstudio wizard for doing COM without ATL.
You'll get full low-level COM samples from the /Samples directory of Devstudio 5.0 or Devstudio 6.0 CDROM.
|
|
|
|
|
I have a COM smart ptr (IMessagePtr) and I would like to keep a vector of them. Is it advisable to make a vector<IMessagePtr>?
I am a bit weary of STL with smart pointers. Does anyone know of any issues with the above vector?
Jeremy.
"Hey man, Taliban, Tali me Banana."
|
|
|
|
|
CComUnkArrary detail in the ATL headers, I've used as a container for all kinds of Com pointers, works
Normski. - the next bit of code is self modifying ... jmp 0xCODE
|
|
|
|
|
You are perfectly fine to use smart pointers in the STL containers. The only caveat is that you should wrap these smart pointers in the CAdapt object like this:
vector<cadapt<imessageptr> >
This is because smart pointers implement the operator& which is needed by STL to refernce the object that is contained with in the containers. The SmartPointers user the operator& to access the interface instead. The CAdapt class will allow you to get around that problem and use the smart pointers safely.
If you have "ATL internals" by Rector and Sells, there is a good section on this in the chapter about containers.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
