I have a problem :
I am using a dll that I wrote that performs some async task.
I am using this dll from an mfc app.
on the mfc app I create a UI thread and overwrite the preTranslateMessage function to handle the event of the dll finishing his task and then i provoke a function from a this pointer given to the UI thread.
when I create the dll I pass to it the threadID of the waiting thread, and when the task is completed in the dll the dll uses PostThreadMessage with the given thread id.
the messages passes just fine and everything was working ok until I inserted a simple .ocx component (just a simple better looking slider) and when the dll signal the mfc app waiting UIThread I provoke a function from the ocx. (using standard vc invokeHelper)
when I do that, I get an Access Violation and the app crash.
if I use functions of the ocx not when the message comes from the dll it works fine. (before or after a message is sent but not as response to the message, then it crash)
While I was exploring the problem I was able to make it work like that (I don't like this solution):
I pass to the dll the mfc app m_hWnd, I overwrite the PreTranslateMessage of the dialog (of the app)20.and I am using in the dll the PostMessage with the Handle and the message.
when I use it like that the message passes and the .ocx component doesn't crash, but OOP speaking there is NO reason what so ever that the dll will hold a handle to the dialog of the app, and I don't want to overwrite the PreTranslateMessage of the dialog, it got better things to do, I want my own thread handling the messages from the dll.
does anyone knows why this strange phenomenon happens ?
what does PostMessage(...) and PostThreadMessage(....) differ all that much ?
what does the .ocx writen in VB got to do with any of it ???
why does evil people exist ? (just kidding I know the answer to that one....(-:)
thanks in advance.