|
Walking Hell wrote: so how can i solve this?
Find out where these functions or objects should be defined and check that the relevant libraries exist and their paths are included in the Visual Studio linker parameters, for this project. If you are not sure which libraries to include then check the documentation for the functions in question.
The best things in life are not things.
|
|
|
|
|
well, when i compile in 32x it was not problem, so now i have to find libs that need to be included for 64x? roger.. i will beter start go looking if i have the libs in my folders..
|
|
|
|
|
well, could you give me a example how to do this? becourse i don't really understand where to define them since i think i got in general linkers my lib folder.
and even when i see this line
1>weapons.obj : error LNK2001: unresolved external symbol lua_pushnumber
i do right click and 'go to location' it says the system can not find the file specified.
|
|
|
|
|
Walking Hell wrote: well, could you give me a example how to do this?
How on earth can you be developing an application if you don't know the basics of the tools you are working with? Use the Project Properties in Visual Studio.
The best things in life are not things.
|
|
|
|
|
Hi all,
I've been experimenting with the converter DLLs of Microsoft Office (under HKLM\Software\Microsoft\Shared Tools\Text Converters\Import). In a single-threaded environment, everything runs ok. But I'm running into difficulties when calling the exported conversion functions like ForeignToRtf32 in the multi-threaded version of my program, even if the libraries are loaded within the context of the calling thread. Does anyone know about the thread safety of these converters?
|
|
|
|
|
Mattias G wrote: I'm running into difficulties when calling the exported conversion functions like ForeignToRtf32 in the multi-threaded version of my program, even if the libraries are loaded within the context of the calling thread. Does anyone know about the thread safety of these converters?
If I understand your question/problem correctly, this has nothing to do with the converter DLLs.
What do you mean by "loaded within the context of the calling thread"?
I suspect you mean that you call ::LoadLibrary() for each thread that uses the library and you assume that it somehow will make calls to the DLL thread safe.
Calling ::LoadLibrary() will load the desired DLL and map into the address space of the process the first time it is called. Subsequent calls to ::LoadLibrary() will only increment the reference count for the DLL in the process, which means that the code and variables will be shared among the calling threads. Calling ::FreeLibrary() will decrement the reference count.
Read more here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
No, I wasn't hoping that calling LoadLibrary from within the thread (that later will call ForeignToRtf32) would in some magical way make the DLLs thread safe.
Did put some more effort into this, but couldn't find any real pattern. Did get rid of one exception type by balancing the calls to OleInitialize and OleUninitialize more carefully for each thread. Still getting a lot of exceptions of types 0x800401FD CO_E_OBJNOTCONNECTED and 0x8001010E RPC_E_WRONG_THREAD (though I'm not using any COM interfaces explicitly in my application).
So back to my original question: Does anyone know anything about the thread safety of these libraries?
Thanks
|
|
|
|
|
Mattias G wrote: No, I wasn't hoping that calling LoadLibrary from within the thread (that later will call ForeignToRtf32) would in some magical way make the DLLs thread safe.
Ok, I just couldn't find any other explanation to what you meant by "loading a DLL within the context of a thread". I interpreted your text as, whatever you meant by it, you thought it would prevent the problems you got when trying to use multiple threads when accessing the converter DLLs.
But never mind. The only thing important is that you only need to call ::LoadLibrary() once for any DLL, subsequent calls will do nothing in practice.
I have never used the DLLs you are trying to use, nor have I found anything useful trying to google it.
So I have no idea what kind of functionality the DLLs expose, how to use them or what their function prototypes may look like.
But that may not be necessary....
Mattias G wrote: Still getting a lot of exceptions of types 0x800401FD CO_E_OBJNOTCONNECTED and 0x8001010E RPC_E_WRONG_THREAD (though I'm not using any COM interfaces explicitly in my application).
Ok, so that means the DLLs uses COM in order to perform its ForeignToRtf32().
When you use COM from different threads you have to initialize COM for every thread that makes use of the COM library by calling e.g. ::CoInitialize() or one of its equivalents. Failure to do so may seem to work, but will cause unpredictable errors being very hard to realize that they originate from not initializing COM. In addition you have to have a message pump for every thread that creates a COM server.
Initializing COM for a thread is called setting up an "apartment" and COM interfaces are not allowed to cross apartment boundaries without being properly marshalled by using e.g. ::CoMarshalInterThreadInterfaceInStream() or the GlobalInterfaceTable(GIT). Using a COM interface from an apartment without proper marshalling will result in the error RPC_E_WRONG_THREAD.
Since you do not use any COM interfaces in your application I assume that the converter DLLs create the necessary COM servers "under the hood".
This probably means that you cannot possibly marshal any COM interface to any other thread than the one you have used to do whatever initialization needed for the converter DLLs, which should be exposed via its C-compatible interface functions.
Unless the converter DLLs expose functionality for explicitly registering different threads, it would be reasonable to assume that the converter DLLs have no means to marshal internal COM interfaces between threads originating from the client. I also think you would have tried that if such functionality was exposed by the DLLs.
My conclusion is that you can only use the converter DLLs from one thread and I would expect that thread to be forced to have a message pump. If you're up to it you can try using the converter DLLs from a worker thread without a message pump and see if it works. But I suspect there is some RPC going on between some proxy/stub pairs that will break without a message pump, causing your calls that are forwarded to any COM servers never to return.
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
A great step forward was to call CoUnitialize for each thread.
Tried both with and without a message pump (with MsgWaitForMultipleObjects), the message pump version produced less exceptions, but the actual result of the conversion is the same. I'm really close to giving up on this, the combination of a under-documented API and multi-threading is a bit much 
Currently, I have a pool of 4 threads for different converters (not only the Office ones, but for HTML and various other formats who are unproblematic). In case of the Office DLL converters, each thread in the pool kicks off another separate thread doing the actual conversion (the only way I could figure out to put a message pump there, and this is how it's done in the MFC/ole/Wordpad sample of MSVC). Everything works fine (with no exceptions at all and correct conversion results) if I block reentry at the call to ForeignToRtf32 with a CRITICAL_SECTION mutex. So if the application should do something with let's say *.docx files only, the performance boost from multi-threading is ... exactly zero (!) Functional, but what a waste of effort...
Thanks anyhow for the interesting reading of marshalling!
|
|
|
|
|
hello friends,
i am an engg. student.
i ma building an data encrypter and decrypter application in c. I want to use some algo. .
after searching on net i came to know about AES algo. I tried to learn from net but i just can't get i bit in y mind.
please help me friends . can anyone tell me how aes works using some example in a simple way.
please let me know if there are other algo present for text file encryption and decryption.
|
|
|
|
|
|
Hi
I am trying to send a Message to my Internet Explorer Window.I got the handle and able to maximize the window but unable to send message.
Can anyone tell me if something is wrong in SendMessage call below?Is the message queued?Send message should wait until the message is processed right?
int _tmain(int argc, _TCHAR* argv[])
{
HWND hwnd=FindWindow(L"IEFrame",NULL);
if(NULL != hwnd)
{
printf("\n Retrieved the window handle \n");
ShowWindow(hwnd,SW_MAXIMIZE);
LRESULT lr=SendMessage(hwnd,WM_RBUTTONDOWN,NULL,NULL);
if(lr == 0)
{
printf(" \n Message Sent \n");
}
else
{
printf("\n Failed to send message \n");
}
}
else
{
printf("\n Failed to retrieve handle \n");
}
return 0;
}
"Every morning I go through Forbes list of 40 richest people in the world. If my name is not in there, I go to work..!!!"
|
|
|
|
|
It might be that MSIE doesn't respond to WM_RBUTTONDOWN the way you hope. For all we know, it could be hooking in to some interrupt table or using a proprietary driver or ... Chances are that the handling of WM_RBUTTONDOWN is guarded by if(GetFocus() != this->m_hWnd) ... or similar.
[EDIT] I just assumed that you've already tried with complete arguments (WPARAM/LPARAM) to the message?
modified on Thursday, April 21, 2011 7:47 AM
|
|
|
|
|
You're probably sending the message to the wrong window handle.
IE's window hierarchy is quite complex.
Use spy to get handles of the child windows and try sending the message to the child windows to figure out which window responds as you expect.
As for SendMessage waiting till the message is processed, an application can use ReplyMessage to override this.
|
|
|
|
|
«_Superman_» wrote: Use spy to get handles of the child windows and try sending the message to the child windows to figure out which window responds as you expect.
Yes,I used Spy++ to get the handle of window.The window is being maximized when using ShowWindow but looks like no messages are being posted.
Also as replied by "Mattias G" above this reply, i gave coordinates in WPARAM/LPRAM - SendMessage(hwnd,WM_RBUTTONDOWN,100,100) but to no avail.
I will try to send messages to child windows (Maybe webpage inside browser) and verify.
Thanks for the reply !
"Every morning I go through Forbes list of 40 richest people in the world. If my name is not in there, I go to work..!!!"
|
|
|
|
|
Probably you need to get IWebBrowser2 [^] Interface and then from there you need to figure it out how to get window handle you are looking for.
I hope there is only one "IFrame" Window in the Spy++.
|
|
|
|
|
i want to drag and drop image in single list control
|
|
|
|
|
|
hai all,
void test() {
RSA * rsa = RSA_new();
}
Am try to build a sample openssl code, using rsa.h in MSVS2008, when i build a project i get a following link error.
Error 11 error LNK2019: unresolved external symbol RSA_new referenced in function "public: int __cdecl .......................
Note:
I have already added the libraries libeay32.lib and ssleay32.lib, but still i getting the link error.
any help pls....
Best Regard's
Mathy's
|
|
|
|
|
|
Hai venkatmakam,
Thankx for your response, i try this link and use it the win32 openssl and install it my PC.
it is compiled without error on a win32 project , if i using the same way in windows mobile application am getting the same LNK error.
any other way is there.....
Best Regard's
Mathy's
|
|
|
|
|
SHFILEINFO sInfo;
ZeroMemory(&sInfo,sizeof(sInfo));
SHGetFileInfo(csFileType, FILE_ATTRIBUTE_NORMAL, &sfi, sizeof(sfi), SHGFI_USEFILEATTRIBUTES | SHGFI_ICON);
if (sInfo.hIcon)
DestroyIcon(sInfo.hIcon);
the value of csFileType is .zip .bak .txt or other file type. I debug the program, the value of sInfo.iIcon is 5, 4, or 7
If use this API SHGetFileInfo, need it do any initialize operation ?
|
|
|
|
|
First thing that strike me is that your SHFILEINFO is sInfo and you pass sfi. How did you get the value of sInfo ??
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
The sfi should be sInfo. I wrong modify it when paste the code to codeproject.
|
|
|
|
|
Hi all,
I have transferred development of an old VC++6 program on an XP machine to VS2005 on a Windows 7 64-bit machine, and the program now falls over when loading files saved on a shared network drive. I have tracked it down to a call to GetVolumeInformation() during the file open procedure when clicking on an entry in the MRU list. This works fine if I call it manually with a UNC path but not if I use a path containing the network drive letter.
Any suggestions how to overcome this so that it works with a network drive letter as well?
The network drive letter was set up manually on my machine, might it need setting up through Group Policy instead?
TIA.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
