|
Assuming you're getting non-NULL return values from LoadLibrary() and GetProcAddress(), I'd say
the problem is in calling FreeLibrary(). Don't you want to keep the DLL loaded?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the letter Z
|
|
|
|
|
Download a tool called "Dependency Walker". If you don't have a .def file being used by the linker, you'll see underscores '_' preceding each exported function name. To fix this, add a .def file to your project and then modify the linker properties to use the .def file (Definition file). Edit the .def file to have an EXPORTS section:
EXPORTS
FirstFunctionToExport
SecondFunctionToExport
ThirdFunctionToExport
....
You get the idea.
Also, as already mentioned, don't call FreeLibrary() until you are actually done with the DLL.
If this solves your problem, take some time to try to figure out mine above. I've already dumped a couple hours into it (mostly research - maybe 45 minutes of actual coding).
|
|
|
|
|
How do you declare MGetPixel?
|
|
|
|
|
The DLL is not causing the problem, I believe it is my declaration. The maker of the DLL said to
LINK WITH GETPROCADDRESS
CALL THEM LIKE REGULER WINAPI (same params)
So MGetPixel should have the same parameters as GetPixel.
|
|
|
|
|
Even if the function declaration is correct, it's not going to work if you call
FreeLibrary(hinstLib) after GetProcAddress(...).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the letter Z
|
|
|
|
|
Ok, I found my problem, Im defining my import wrong. I actually read the runtime error and it said I'm defining my function one way and the actual function is defined in a different way. How would I define a GetPixel function. HE said to declare it as any other WINAPI.
|
|
|
|
|
vegito616 wrote: How would I define a GetPixel function. HE said to declare it as any other WINAPI.
What you had was fine for getting a pixel value from a source DC.
Windows APIs use the WINAPI calling convention:
typedef COLORREF WINAPI (*MYPROC)(HDC, int, int);
where WINAPI == __stdcall
Mark
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the letter Z
|
|
|
|
|
Hello,
Here's my problem:
I have an ActiveX control which has the functionality of a video player. After integrating it in my MFC dialog, when I play the video, if I drag the dialog out from the screen, or maximize it, or drag some other dialog over it, the ActiveX control doesn't redraw its child windows properly.
More exactly, it's about two DirectX child windows which are created for playing the video. One is a DirectX output window and one is the video overlay. Instead redrawing them corectly (video frames playing) I get the area filled with the MFC dialog's background. Setting Clip Siblings to true in the MFC dialog's properties doesn't help much. Indeed, I don't have the area filled with the background but the redraw of the ActiveX windows isn't still made properly (it's a mess .. background mixed with video or something else.. )
I managed to get the handles of the two DirectX windows and tried various solutions starting from calling Invalidate for the entire control to WinAPI calls to RedrawWindow on the handles (and others). Nothing seems to make the video output windows repaint themselves after being covered with something else.
I need to mention that I don't have any experience with DirectX or with ActiveX/COM besides using controls.
If someone can give me a hint for a solution many many thanks in advance.
|
|
|
|
|
Is the ActiveX control written by you?
My first try would be to disable the erase background and paint events in the MFC dialog, and see if the control draws properly... even that your MFC dialog will look horrible. If the problem was that your dialog ruins the video playing, then you can try to set the flag for clip children (not clip siblings).
Can you tell us if the ActiveX control is using DirectX overlay for playing video?
Regards,
|
|
|
|
|
No, the ActiveX isn't written by me.
I have already tried to disable the WM_ERASEBKGND message for the dialog and the only thing changed is indeed that the dialog looks horrible. The ActiveX control has the same problem. Adding the disabling WM_PAINT makes the dialog fully transparent - and still no proper redraw in the video control. (I've let only the control at this moment on the dialog, which is a modeless one launched from the main application dialog)
My mistake, sorry, I wrote the first post in a hurry, the Clip Children was the property I set and doesn't make much difference, not the Clip Siblings.
Finally, yes, the control is using DirectX overlay, is the problem there ?
Thank you for your interest
|
|
|
|
|
Have you tried to see if other applications using DirectX overlay have a similar problem? Could be a graphics card / driver / driver settings problem.
I could try the ActiveX control if you send me a copy and if it doesn't have some licensing issue. For now, I can't think of a specific reason for your problem. It would be much easier to try it myself.
Best wishes,
|
|
|
|
|
The control is open source, so I don't see any licensing problems. I know almost nothing about COM/ActiveX development like I said in the first post. If I did I would have taken a look myself inside it's code.
I'll mail it to you on the address specified in the link in your signature if it is ok (please let me know). As far as I know, I think there are video players that use DirectX overlay. I don't know one exactly but I don't remember seeing any player to "behave" in this way.
Again, many thanks for the answer.
|
|
|
|
|
Yes, you can use that email address. If you'd like you can simply send the location where I can find the open-source code for the control. I'll create a sample test project and try to reproduce the behaviour you've been describing.
Regards,
|
|
|
|
|
Can someone provide links to Windbg apart from microsoft documentation?
|
|
|
|
|
|
Thanks for telling me that. But i'm looking for links which provide more info on it in terms of hand on.
|
|
|
|
|
|
That link was provided to him several days ago here. He's apparently not interested in help.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
"Debugging Applications for .NET and Windows" by John Robbins, published by Microsoft Press.
|
|
|
|
|
MSDN states that sending a message is done directly to a message windows procedure rather than message queue. If that is true then is it true that GetMessage/PeekMessage is valid only for messages that are placed into message queue by postmessage.
Also if we want to direct a message to another process will both PostMessage/SendMessage work. What is the difference?
|
|
|
|
|
from MSDN:
The SendMessage function sends the specified message to a window or windows. It calls the window procedure for the specified window and does not return until the window procedure has processed the message.
The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window and returns without waiting for the thread to process the message.
The WindowProc function is an application-defined function that processes messages sent to a window. The WNDPROC type defines a pointer to this callback function. WindowProc is a placeholder for the application-defined function name.
The DispatchMessage function dispatches a message to a window procedure. It is typically used to dispatch a message retrieved by the GetMessage function.
|
|
|
|
|
In addition to what Michael posted, both APIs are adding messages to the thread's message queue, thus can be retrieved using GetMessage() and PeekMessage(). As MSDN says, on Vista there's a small exception for this behaviour:
"Microsoft Windows Vista and later.
...
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine.
..."
Best regards,
|
|
|
|
|
What about the other part of the question
Also if we want to direct a message to another process will both PostMessage/SendMessage work. What is the difference?
|
|
|
|
|
Do you understand English? PostMessage() returns without waiting for the thread to process the message. SendMessage() does not return until the window procedure has processed the message. PostMessage() is a non-blocking call. SendMessage() is a blocking call. Regardless of Microsoft's implementation details, both calls go to the same place -- the window procedure of the window to which you are sending (or posting) the message.
|
|
|
|
|
hi Tom,
did u get the answer for your question,
"if we want to direct a message to another process will both PostMessage/SendMessage work?"
If so, can you reply that to me?
I dont think postmessage/sendmessage works across processes.
it that right?
Thanks in advance.
cheers....!
Balaji
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
