|
I added MS ParamEqu filter ( which is a DMO ) into my graph using IDMOWrapper interface.
I want to manipulate parameters of it ( gain,bandwidth,center freq) programatically in my code.
When I searched for this , I found IMediaParams Interface ( http://msdn2.microsoft.com/en-us/library/ms785964(VS.85).aspx)
But I am not sure that it will solve my problem.
If you experienced changing parameters of a DMO fitler programatically , can you give me advices about that ?
For example I didnt understand "envelope" concept. Also sample code for using that interface would be very good.
Best Regards
|
|
|
|
|
Can you do a LoadLibrary in a DLL I seem to be having problems ???
|
|
|
|
|
Yes. But don't try to do so in your DllMain function. See here[^] for details.
Steve
|
|
|
|
|
Still no go
I put the code in the same source but in a function which I exported and imported in my main() .exe
|
|
|
|
|
|
Okay
The function is init_image at the bottom
I call it from my main() exe
This all started when I wanted to see what thread('s) came in on the THREAD_ATTACH so decided to play around with StacKwalk in imagehlp.dll etc.....
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
i = 4;
break;
case DLL_PROCESS_DETACH:
i = 3;
break;
case DLL_THREAD_ATTACH:
threadhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentThread(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&threadhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
processhndl = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentProcess(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&processhndl, // Target Handle pointer.
0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
memset( &c, '\0', sizeof c );
c.ContextFlags = CONTEXT_FULL;
GetThreadContext(threadhndl, &c);
s.AddrPC.Offset = c.Eip;
s.AddrPC.Mode = AddrModeFlat;
s.AddrFrame.Offset = c.Ebp;
s.AddrFrame.Mode = AddrModeFlat;
while(1)
pSW(imageType, processhndl, threadhndl, &s, &c, NULL, NULL, NULL, NULL );
// while(1)
// StackWalk(IMAGE_FILE_MACHINE_I386,
// processhndl,
// threadhndl,
// &s,
// &c,NULL,NULL,NULL,NULL);
break;
case DLL_THREAD_DETACH:
i = 2;
break;
return false;
}
return TRUE;
}
__declspec(dllexport) void init_image(void)
{
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
Thankx
|
|
|
|
|
Is that an infinite while loop inside your DLL_THREAD_ATTACH case?
|
|
|
|
|
Yes; just wanted to Walk thru the stack
When I load imagehlp.dll in my main exe it works (the LoadLibray) however not in the export'ed function (that lives in
the DLL source)
in order to get all the variables LoadLibrary (handle) and ProcAddress to the DLL I would have to export it thought it
would be simpler to have all the code in the same source as the DLL where In THREAD_ATTACH I would see what thread
attach'ed to the DLL via StackWalk and other imagehlp functions
Thankx again
|
|
|
|
|
Does this fix it?
hImagehlpDll = LoadLibrary((LPCWSTR)L"imagehlp.dll" );
Note the 'L' notation for wide string.
|
|
|
|
|
|
ForNow wrote: hImagehlpDll = NULL;
Is hImagehlpDll a pointer?
ForNow wrote: hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" );
Does hImagehlpDll have a non-NULL value? Why the cast? Use L or _T() instead for your string literals.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ForNow wrote: I seem to be having problems ???
Are we supposed to guess what these problems are?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Sorry dont know Where that thread came from
I did a LoadLibrary in my main executable for imagehlp and it worked... however what I was hoping to see is in my DLL when I get the thread_attach message is to identify the thread
Some one suggested the use of StackWalk so.....
Orignally I did the LoadLibrary in DLLmain but I was quickly told that was a big no no ... As the OS namely Windows hold locks while processing DLLmain as it is shared code among .exe and DLL and I would cause a deadlock
So.. I put the code for this (the LoadLibrary and GetProc in a exported function in the same source as my DLL
My main .exe imported this function and I called the function in a another DLL that was "implicity loaded" (hope that is right term as opposed to Dynamic Loaded e.g. LoadLibrary) in my main .exe a few lines after my startup code from my main .exe
I think calling a exported function from a DLL which does a LoadLibrary maybe the problem
Dont Know
Thankx again
|
|
|
|
|
Sorry the Value returned from LoadLibrary was NULL
|
|
|
|
|
So why are you then not calling GetLastError() to find out why?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I got a x7e ERROR_MOD_NOT_FOUND
But thats not it
When I do the load in the main its okay When I call the exported function init_image it fails
int main(int ac,char *av[])
{
int rc = 0;
HINSTANCE hImagehlpDll;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- Okay
init_image();
code in DLL source
__decspec(dllexport) void init_image(void)
{
DWORD myerror;
DWORD DWfLAGS = FORMAT_MESSAGE_FROM_SYSTEM || FORMAT_MESSAGE_ALLOCATE_BUFFER;
DWORD size = 100;
char mybuffer[100];
LPTSTR error_ptr;
imageType = IMAGE_FILE_MACHINE_I386;
pSW = NULL;
hImagehlpDll = NULL;
hImagehlpDll = LoadLibrary((LPCWSTR) "imagehlp.dll" ); <--- fails here
myerror = GetLastError();
// FormatMessage(dwFlags,NULL,myerror,NULL,error_ptr,size,NULL);
pSW = (tSW) GetProcAddress( hImagehlpDll, "StackWalk" );
return;
}
|
|
|
|
|
What does wide L mean ????
|
|
|
|
|
ForNow wrote: What does wide L mean ????
The L is not wide, but the string it precedes is.
Use the L prefix to denote a wide-character character literal or a wide-character string literal.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thankx Can I buy you lunch one day
Honestly one of the things I noticed with this problem coming from a MainFrame
Background is (using MainFrame Sercvices) When you want to use one of the Authorized
Assembler services IBM always prefaces the discription of the macro by requirements
Such as must be Authorized state or No Locks Held
There is no such documentation on Windows API's
|
|
|
|
|
ForNow wrote: There is no such documentation on Windows API's
Are you referring to MSDN?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I was refering in MSDN if they are are any requirements when using an API
shuch as no Locks held etc....
I guess I found out they are certin things I cann't do in DLLMain
Thankx again
|
|
|
|
|
A few questions regarding use of the inline key word
1) Do you use it?
2) How do you decide when to use it?
3) Do you ever actually measure the benifit of using it?
4) Can using it ever degrade performance?
5) Can the effect of using it vary on different hardware or operating systems?
|
|
|
|
|
Josh Gray wrote: 1) Do you use it?
Yeah.
Josh Gray wrote: 2) How do you decide when to use it?
When the overhead of a function call is comparable to the overhead of the function itself. For example, a simple accessor function.
Josh Gray wrote:
3) Do you ever actually measure the benifit of using it?
Very rarely.
Josh Gray wrote: 4) Can using it ever degrade performance?
I guess it's possible. If you inlined a frequently called large function you would increase the size of the EXE. Remember that the compiler has the last say however: it doesn't have to inline a function you've marked as inline if it decides it's not worth it.
Steve
|
|
|
|
|
Thanks mate
Stephen Hewitt wrote: I guess it's possible. If you inlined a frequently called large function you would increase the size of the EXE. Remember that the compiler has the last say however: it doesn't have to inline a function you've marked as inline if it decides it's not worth it.
What I've been wondering about is the effect this has on hardware optimisations. For example instruction pipe lines and cpu caching.
I'm going to do some experimenting to see if making some functions inline has any real world effect
|
|
|
|
|
Josh Gray wrote: I'm going to do some experimenting to see if making some functions inline has any real world effect
You will not see much difference if you do not disable optimizations. The MSVC compiler is very intelligent with its inlining and will very often inline your functions even if you did not ask it to.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
