|
Thanks Andrew!
I think I need to spend some time learning DirectShow. I know DirectDraw and I understand how to apply image processing and overlay to a video buffer (primary surface, back buffer...). However I am missing the piece to get the video from the webcam to a buffer (DirectShow).
Can you tell me briefly how it works?
Merlinos
|
|
|
|
|
Have a look at the playcap sample (\DXSDK\Samples\C++\DirectShow\Capture\PlayCap) in the DirectX SDK. It runs through the steps to create a filter graph, and add a renderer. You should be able to build on the example to add an instance of the CSampleGrabber filter (\DXSDK\Samples\C++\DirectShow\Filters\Grabber) into the graph.
Once the sample grabber is in the graph you pass it a callback, which is triggered when a frame arrives. In that callback, copy the image data onto the DirectDraw surface.
Hopefully that will get you started - good luck!
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
I am trying to add the CSamlpeGrabber into the playcap sample but I am running into some issues.
I get the following linking errors:
playcap.obj : error LNK2001: unresolved external symbol "public: __thiscall CSampleGrabber::CSampleGrabber(struct IUnknown *,long *,int)" (??0CSampleGrabber@@QAE@PAUIUnknown@@PAJH@Z)
strmbasd.lib(wxdebug.obj) : error LNK2001: unresolved external symbol __imp__timeGetTime@0
Can you tell me what I am missing here? Thanks!
Also, I tried a different way to insert the grabber sample using simply its CLSID and when I do that I get the following error:
playcap.obj : error LNK2001: unresolved external symbol _CLSID_GrabberSample
I am sorry to ask all these newbie's questions but I am a DirectShow newbie.
|
|
|
|
|
to get timeGetTime working you need to link to winmm.lib
including <initguid.h> should eliminate the problem with the clsid
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Is there a way to create a new window, which is brought to the front, from a process which is not the current process. On NT5 upwards, Windows does not allow processes which are not the current process to bring newly created windows to the front.
AllowSetForegroundWindow() will work, but not on Win95/98
I need a method which works on Win95/WinNT4 upwards.
Is this possible ?
|
|
|
|
|
Try SetWindowPos (&CWnd::wndTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); .
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
If i understand what you mean (you asking how to steal input focus on 2K/XP if a window belonging to another process has the focus) You need to attach your threads input Q to the active windows input Q - other wise as you say SetForgroundWindow does nothing.
Like this:
AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),TRUE);
SetForegroundWindow();
SetFocus();
AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),FALSE);
That will attach ure threads input Q to the input Q of the window with the foucs, steal the focus - which is now allowed, then detach it.
I hope thats what u ment )
|
|
|
|
|
Diddy wrote:
AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),TRUE);
SetForegroundWindow();
SetFocus();
AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL),
GetCurrentThreadId(),FALSE);
This is exactly what I want, thanks.
Two questions though:
Shouldn't the ThreadProcessId be stored when GetWindowThreadProcessId() is first called ? Otherwise, when you call it the second time, you are getting the ThreadProcessId of your apps window and not the original window, since it is no longer the Foreground Window.
Also, will it not make the other app unstable, because by stealing the threads input for a short period, you are also stealing its' messages. This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app. Bit of a convoluted description, I know )
Anyway, will it make the other app (or my app) unstable ?
Thanks again for your help.
|
|
|
|
|
1) Yes ) Thats called me trying to attack the situation with copy and paste ) Well spotted.
2) No. It's not stealing its input - its stealing - or rather sharing - its input states. Each thread has a number of states associated with all the windows it has created - such as the one that has the focus, and the curent cursor for each etc. When you call SetFocus, it says is the focus state set for our thread for at least one window we have created - if thats a no, it does nothing - if its a yes, it sets the focus to the window provided. AttachThreadInput simply combins the states for both threads, so thread A and thread B are now working with the same state - since you are attaching to the current forground window, your focus state is now set and you can change the focus to one of your own windows.
In other words:
defenestration wrote:
This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app
Isn't true - its nothing to do with the messages - just to do with certian states of the thread (specifically focus, active, capture windows, key state, queue status, and so on).
It's the recomended way by MSDN anyway - and I have used it for ages with no stabality problems. One thing to be aware of - never put a break point between attaching and detacting. If you are debuging - you will be attaching to MSDEVS thread, and because your app is being debugged, you will be bascially freeze the debugger.
Hope it helps
|
|
|
|
|
Diddy wrote:
Hope it helps
It certainly has. Thanks for the explanation Diddy!
|
|
|
|
|
Hi,
I'm in the process of making my program more robust. I've had a couple integer divide by zero exceptions from my program so I am now going through all divisions within my code and maknig sure they aren't 0.
However, just wondering if there is such thing as floating point divide by zero? I can't seem to find such an exception and coudlnt' generate it myself for testing. Do FLOATs work differently than integers?
Thanks in advance!
|
|
|
|
|
I ran a test and to my supprise, no exception was generated! Why? I am still looking for the answer.
Look in MSDN library under the following:
"Floating-Point Exception Modes"
and
"_controlfp"
I hope that is some help!
Here is a clip from a math parser I wrote (in C) back in 1994 (the code still works):
int matherr( struct exception *except )
{
char t = *(_User.def.name);
int endx=-1, sndx=-1, n = _User.def.nargs;
char *str[2] = { "is","caused" };
char *errors[6] =
{
"outside the domain",
"an illegal value",
"overflow",
"underflow",
"partial loss of significance",
"total loss of significance",
};
switch( except->type )
{
case DOMAIN: endx = 0 ; sndx = 0 ; break ;
case SING: endx = 1 ; sndx = 0 ; break ;
case OVERFLOW: endx = 2 ; sndx = 1 ; break ;
case UNDERFLOW: endx = 3 ; sndx = 1 ; break ;
case PLOSS: endx = 4 ; sndx = 1 ; break ;
case TLOSS: endx = 5 ; sndx = 1 ; break ;
}
if( t && endx>-1 && sndx>-1)
{
_Error( "math","'%s': argument %s %s",
_User.def.name,str[sndx],errors[endx] );
}
else _Error( "math",errors[endx] );
return 1;
}
#include <float.h>
#include <signal.h>
static void fphandler( int sig, int num );
static char *_FpeErrors[10] =
{
"invalid number",
"denormal",
"divide by zero",
"overflow",
"underflow",
"inexact",
"unemulated",
"square root of negative number",
"stack underflow",
"unknown",
};
void p_setfperror(void)
{
if( signal( SIGFPE, fphandler ) == SIG_ERR )
_Error( "p_setfperror","could not set floating point error handler" );
else _FpeSet = 1;
}
static void fphandler( int sig, int fperr )
{
int ndx;
_fpreset();
if( _Error_Flag > -1 )
{
switch( fperr )
{
case FPE_INVALID: ndx = 0; break;
case FPE_DENORMAL: ndx = 1; break;
case FPE_ZERODIVIDE: ndx = 2; break;
case FPE_OVERFLOW: ndx = 3; break;
case FPE_UNDERFLOW: ndx = 4; break;
case FPE_INEXACT: ndx = 5; break;
case FPE_UNEMULATED: ndx = 6; break;
case FPE_SQRTNEG: ndx = 7; break;
case FPE_STACKUNDERFLOW: ndx = 8; break;
default: ndx = 9;
}
_FpeMsg = _FpeErrors[ndx];
}
_Error_Flag = -1;
}
Good Luck!
INTP
|
|
|
|
|
Thanks for the resources. Would you happen to know what the Alpha machines are? I guess we're concerned with x86 right?
I still can't generate a floating point divide by zero. Perhaps the compiler is doing something so that it gets trimmed away. But I just hope it doesn't happen in my program
Has anyone actually seen a floating point exception before? One related to arithematic error? I don't think I have.
Thanks!
|
|
|
|
|
Ryan is right about the infinity thing, but the code sample I gave you was from a math parser that did catch divide-by-zero (all calculations where done using double values).
May be you sould also look up: "ID: Q72726"
The best solution of course is to always test the denominator to make sure it is not zero before using it.
INTP
|
|
|
|
|
herbert_chow wrote:
However, just wondering if there is such thing as floating point divide by zero? I can't seem to find such an exception and coudlnt' generate it myself for testing. Do FLOATs work differently than integers?
A floating-point divide-by-zero doesn't generate an exception - even at the FPU level. FPU's know that anything divided by 0 is infinite, so they actually return a result of infinity (which is a valid number in the IEEE floating point formats, BTW). They don't flag an error condition, so the only way you can check is to determine if the result is infinity.
However, a much better way is to make sure it never happens in the first place...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Just to point out.. that anonymous user was me, I forgot to log in.
Thanks for the great tips everyone! The SIGFPE handler interrupt is something I will need to look into as although I've worked with SIGFPE at the C level for an operating systems course. Im not quite sure how to incorporate it into Visual C++ though.
But I guess I got the main point which is to always check that I'm not dividing by zero.
Well... time to start checking EVERY division in my code.
|
|
|
|
|
Hello,
I'm working on a dialog based application. I need some sort of Panel (like in Delphi) in the main window.
I figured that a panel is nothing more than a modeless child window without any borders.
I derived a class from CDialog and I put some controls on it (edit boxes and such). It all works fine, the window hides and appears when I want it to, the controls work fine (button's get pushed, data moves from and to edit controls), BUT when I try to move the child window, it stays put.
I move the child window like this:
<br />
if(((CMyDialog*) m_pdlg)->SetWindowPos(this, 200, 50, 0, 0, SWP_NOSIZE | SWP_SHOWWINDOW))<br />
AfxMessageBox("test");<br />
The messagebox appears, so the window should be moved, but it doesn't...
I'm all out of clues and fried by my monitor and manuals...
Does anybody know a solution?
Thanks in advance.
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Interesting.
Are you passing in a coordinate that is different than the current one?
Kuphryn
|
|
|
|
|
Hello,
I didn't pass the same coordinates, but I solved the problem now
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
There's always MoveWindow, if you are having problems and make sure that the coordinates are in the parent window coordinates.
|
|
|
|
|
Hello,
I solved the problem now . I don't know why it didn't work before, but it's solved now..
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Hello,
I solved the problem. When I don't typecast the m_pdlg to CMyDialog* everything works fine...
I don't know why I can't typecast m_pdlg to CMyDialog*, but it works fine now
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
When building CodeProject examples (and other source code), I have noticed that the file size of the Release executables that I create, are larger than the Release executables created by the authors of the examples. I couldn't figure out why, but after re-installing XP and VC++6, I forgot to install SP5, and noticed that the Release executables produced were a different size to the ones created when SP 5 had been installed. Sometimes they were larger, sometimes smaller.
For example, if I install VC++6, without the service pack, I end up with a Release executable size of 528KB. With Service Pack 5 installed, this reduces to 444KB.
I've noticed this peculiarity before when compiling the QCD (Great media
player) Monkey's Audio input plugin - My plugin is 202KB, compared to the
official plugin which is 153KB. Everybody else I've spoken to can compile it
and produce a plugin of 153KB. It seems I'm the only one with the problem (
Also, when compiling a viewer plugin for the Directory Opus file manager, the dll produced is 32KB without SP5, and 44KB with SP5.
What's going on ?
|
|
|
|
|
Hmmm! It is a service pack! This implies that some bugs where probably fixed and or some of the code was changed to be more efficient. A bug fix might increase the code size generated by the compliler, why an improvement in efficiency might result in a smaller or larger code size.
In either case the amount of code generated has changed, and is hopefully better than is was without the service pack.
INTP
|
|
|
|
|
Thanks for the reply.
I don't understand why other people can compile the QCD plugin with VC++6 SP5 and produce a dll of size 153KB, and mine is 202KB, using exactly the same settings.
The same is true with the ToDoList project on CodeProject, where the official Release executable is 340KB, but mine is 444KB, again using the supplied project settings.
Any ideas ?
|
|
|
|
|