|
Per MSDN:
Smart pointers are created when you use the new #import directive to "import" a type library. When you use #import , the Visual C++ compiler reads the type library from the file you specify.
All you really need to do is to use #import and use the smart pointer types it creates for you.
Visual C++ then creates two files which it automagically #includes in your compilation. They're stored in your output directory and are named with the same base name as the type library with the extensions ".TLH" and ".TLI." For instance, our program has the #import :
#import "..\NonATLObject.tlb" and it generates two files in the output directory (DEBUG for debug builds), NonATLObject.TLH and NonATLObject.TLI.
Read more here.
While I don't provide a definition, see a small example here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I have an MFC .exe that makes calls into a non-MFC .dll
There is one call that i make that returns an int, but i have some COM interface error when i return.
.dll
__declspec(dllexport) int GetXMLRESPONSE()
{
int NUM = 0;
// Create XMLDOMDocument
hr = CoInitialize(NULL);
hr = pDocument.CreateInstance("Msxml2.DOMDocument.4.0");
//I do some document parsing etc here,
//Then at the end before i return i do a CoUninitialize();
CoUninitialize();
//Function blows up when i execute the return
return Num;
}
If i were to take all the COM stuf out, it returns fine. Is there something i should be doing or not doing?
|
|
|
|
|
Try just AfxOleInit instead CoInitialize/CoUnInitialize
also check S_OK == hr to find problem
|
|
|
|
|
1. It's not good for a DLL to call CoInit() - that should be the responsibility of the caller. If your function is called from a thread that is already in an apartment, your CoInit() will do nothing.
2. I'm guessing pDocument is a smart pointer. You're probably not calling Release() on it before CoUninitialize() .
--Mike--
Visual C++ MVP
LINKS~! Ericahist | 1ClickPicGrabber | NEW~! CP SearchBar v3.0 | C++ Forum FAQ
Shots do not hurt other players... yet
|
|
|
|
|
How can I get status of the queue from another thread?
I have one worker thread A and UI thread B.
Now I need in A find status of message queue of B.
Thanks.
|
|
|
|
|
Ideally, thread A should post a message to thread B asking about it's queue status. Thread B should then respond by posting a message back to thread A with the status. Make sense?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
If B freeze or busy I will overwhelm its queue which could at that moment already full. I am trying to minimize any message exchange. David BTW do you know how exception mechanizm colapsing/destroing stack up to the first catch? I think it could help me to solve problem.
Thanks.
|
|
|
|
|
Alex_Y wrote:
If B freeze or busy I will overwhelm its queue which could at that moment already full.
While message queues do have an upper limit (10,000 per MSDN), I've never heard of one being filled up, unless it had underlying problems. In any case, PostMessage() will return FALSE if the queue is indeed full.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I know for sure that there is underlying problem. I want do the work around because one of the ocx controls in UI thread freezing. I already subclass windproc, but I never know on what message third party control will freez. Messages which is comming from message loop is "peace of cake". I can skip them if I already know from subclassing that control is busy, but most hassel is Send messages which is comming from parent/Windows which goes directly to the
WindProc. I never know how log that particular message will spend in ocx control. I find that send/post message don't improves situation if control already stuck. Even if you send WM_NULL just to make sure that message loop in still alive.
Thanks.
P.S. Sometimes sharing with somebody is giving feeleng that you solve half of problem.
|
|
|
|
|
Is SendMessageTimeout() of any help?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I was trying to resend to myself message by SendMessageTimeOut and it never expired. I found on msdn that timeout is disabled if you doing within the same thread.
Remarks
The function calls the window procedure for the specified window and, if the specified window belongs to a different thread, does not return until the window procedure has processed the message or the specified time-out period has elapsed.
!!!
If the window receiving the message belongs to the same queue as the current thread, the window procedure is called directly—the time-out value is ignored.
!!!
Thanks.
|
|
|
|
|
Hi,
I was using the article from Mike O. http://www.codeproject.com/internet/SocketFileTransfer.asp[^]
Everything works fine unless I have a firewall.
It looks like if the computer that needs to listen has firewall on it, the connection from the other computer will be filtered. When I use a PC w/o a firewall, everything works fine.
Is there a way to make sure the PC with firewall will accept calls from the other PC using the sockets ?
|
|
|
|
|
Yes, open the port you're using in the firewall settings on the PC with the firewall :p
|
|
|
|
|
Thanks for the reply but what does "firewall :p" means ?
Is it an MFC function or DOS ?
I tried running the command firewall in DOS and it showed nothing....
Thanks again,
Shay
|
|
|
|
|
I'm sorry for being unclear, what I mean is this:
A firewall's purpose is to prevent a PC from listening on any unopened ports. There is no way to programmatically get past a firewall that has a port closed; that's what firewalls are for, that's what they do, they do not let you host a connection on an unopened port. Your PC can't listen on a port blocked by a firewall? Good. That's the way it's supposed to be, if it COULD host a connection, it would mean your firewall was not functional.
To get your program to work from a computer with a firewall, you need to either open the port you're using in the firewall settings on that computer, or you need to run another instance of your program on a separate computer as a proxy, and use that as a server.
|
|
|
|
|
I have a DLL which was written as an MFC Extension DLL -- no CWinApp-derived class, and a DllMain function. I'm making changes to the DLL and would like to convert it over, and give it a CWinApp. What do I need to do besides moving the DllMain code into the InitInstance and ExitInstance overrides, and removing the _AFXEXT preprocessor define? I did those things, and the DLL builds fine; but when I attempt to load it in an application, an assert statement fails inside the CWinApp constructor -- the assert is,
ASSERT(AfxGetThread() == NULL);
-- AfxGetThread() is returning a pointer to theApp, which is the globally defined instance of the class I derived from CWinApp. Who modifies the module state before the CWinApp constructor is called?
|
|
|
|
|
Do you call AFX_MANAGE_STATE before call dll?
|
|
|
|
|
No -- this crash is occuring before any calls, when the DLL is loaded.
|
|
|
|
|
Sorry -- a misstatement. The crash occurs when the main application's CWinApp is being constructed, because the module state is already pointing to the DLL's CWinApp object.
|
|
|
|
|
My addvice don't try to figure out what the difference in the keys between the MFC ext and regular MFC dll. If you will do two empty projects one with MFC ext another regular MFC dll and take a look in Windiff what is the differences you will see that there is lot of stuff is different in dsp/vcproj
Better create new MFC regular dll move your code there and don't and keep CWinApp derived class untouched after wizard.
It is possible that you missing one of some precompile defenitions, but again figuring out could take a lot of time.
|
|
|
|
|
And the answer is: Not only do you need to remove the _AFXEXT define, you also need to add a _USRDLL define. Do those two things and it will work fine.
Bonus hint, regarding AFX_MANAGE_STATE: you apparently need to invoke this not only at the top of your exported functions, but also at the entry point of any worker threads you create that will use MFC functionality.
|
|
|
|
|
Hi,
A worker thread is running the threadproc. While it is running i want to send some data to it from main thread. How to do this?
Thanks in advance.
jagadeesh
|
|
|
|
|
|
There are several methods to do this:
1) Use a global variable that stores the data you want to send to the worker thread;
2) Use a singleton;
3) Use files;
I'd go with a singleton, that seems the be the most 'clean'. Remember to synchronise your data, since it will most likely be accessed by multiple threads (avoid corrupt data!).
There are probably some other methods you can use.
Er zit een korstje op mijn aars.
|
|
|
|
|
using Global variabe works simply.....
v
|
|
|
|