|
BOOL bStat=FALSE;
bStat= m_ControlWrapper.CreateControl (
strControlProgID,"",WS_VISIBLE,cRect,this,5000,NULL,
FALSE,NULL);
IOleObjectPtr pOleObj(m_ControlWrapper.GetControlUnknown ());
LPUNKNOWN lpUnknown=m_ControlWrapper.GetControlUnknown ();
now the problem is that I want to queryinterface and want to call the methods and properties. For that I have taken IDL generated by OLE view and added to the project and compiled.
IWebAgentModulecom iInterface= NULL;
the above statement gives errors "cannot instantiate abstract class due to following members"
Do I have to import the DLL??
Any Idea??
Thanks
|
|
|
|
|
Let MFC create the classes for you by adding the control to a dialog.
|
|
|
|
|
|
Giorgi Moniava wrote:
1) Is there any way to determine the maximum value that I can specify for SIZE variable ?
2GB in theory.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Hello Giorgi Moniava!
Don't u know about the range of each Primary data type in C.
ex:
int -32676 to 32678 (I hope this is right)
and I don't think that u can assign a value greated than this to an int variable (ex:705301340)
|
|
|
|
|
Shoaib Patel wrote: Don't u know about the range of each Primary data type in C.
have you tried same in Windows Environment :- sizeof(int) = 32 bit = 2^32.. ok
|
|
|
|
|
Hey,
I am having trouble capturing video from my pc cammera. The directx SDK
directshow sample "Play Cap" have developed my previewing skills. But capturing is not going so well. In the DX9 Book it is said that just by making some minor changes in the ICaptureBuilderGraph2::RenderStream() we developers be able to capture live video. But thats not happening. In the
"Play Cap" sample code when i do this minor changes as told it raises an error.
<br />
<br />
IBaseFilter *pMux;<br />
<br />
hr = g_Capture->SetOutPutFileName(&MEDIASUBTYPE_Avi,<br />
L"C:\\Test.avi",<br />
&pMux,<br />
NULL);<br />
<br />
hr = g_Capture->RenderStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Avi,<br />
pSrcFilter, NULL, pMux );<br />
<br />
pMux->Release();<br />
pSrcFilter->Release();<br />
<br />
hr = setupVideoWindow();
<br />
|
|
|
|
|
I don't see a video renderer filter, so how can you setup the video window?
You seem to have only created a graph for capturing video to disk.
|
|
|
|
|
dear hfry,
I didn't gave the whole code. In the paragraph it is mentioned that the "Play Cap" sample code which comes with dx9 SDK helped me develop some understanding of video capture. Now if you have seen the Source Code of "Play Cap" you will understand where in between that code i have inserted these lines. I have mention that after the line "g_pCapture->AddFilter()".
Which you will find in the Funtion VideoCapture() "(Play Cap)" Source code.
If even then you need the code then i will write the code for you.
Thanks for the reply.
|
|
|
|
|
I have taken the trouble to look at the sample. Did you add your capture code after
<br />
hr = g_pCapture->RenderStream (&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video, pSrcFilter, NULL, NULL)<br />
?
Or did you modify it into your capture code?
If you render a video stream with the destination as NULL, it will render it to the default video renderer (The old video renderer usually, and VMR7 in non-mixing mode on Windows XP).
edit:
That said, if you want to do both capturing to disk and previewing to the screen, always render the preview pin first. That way in the event that there isn't a real preview pin, a smart-T filter will be inserted so you can do the capture. From memory AFAIK, I don't think the smart-T gets inserted if you render the capture pin first and there isn't a preview pin.
-- modified at 9:09 Monday 27th March, 2006
|
|
|
|
|
Million thanks,
Now it seems you have almost understood my problem. I have added the code
below before the line you have mentioned and ommited it. The code below gives error when i give "renderstream" pMux Pointer. If i leave it null the code runs but video doesn't gets saved. This code is supposed to capture the live
video.
<br />
IBaseFilter *pMux;<br />
<br />
hr = g_pCapture->SetOutputFileName(<br />
&MEDIASUBTYPE_Avi,
L"C:\\Example.avi",
&pMux,
NULL);
<br />
if(FAILED(hr))<br />
{<br />
Msg(TEXT("Couldn't create save file..."));<br />
}<br />
<br />
hr = g_pCapture->RenderStream(<br />
&PIN_CATEGORY_CAPTURE,
&MEDIATYPE_Video,
pSrcFilter,
NULL,
pMux );
<br />
pMux->Release();<br />
<br />
the code below remains as it is. <br />
|
|
|
|
|
And what is the hr error code from g_pCapture->RenderStream()? Before starting all this did you use GraphEdit to check what kind of graph you should be building?
|
|
|
|
|
Dear hfry,
Sorry for the delayed answer. I am posting this message to inform you that my boss has shifted me directx to C#. Now I am doing work on some other
project.
The answer to your question is i didn't used graphEdit to check what kind
of graph i should use.
Now my final question is after using graphEdit in my application will i
be able to generate a captured file successfully. Because with your help i am
now able to just create blank file with nothing on it. Which gives an error
that ClassFactory couldn't generate xxx. I will do as you have told me and give it a last try.
By the way thanks for all ur time an patience. Forever gratefull. Mubashir
|
|
|
|
|
Can you send me soure code of this programing ?( Visual c++ 6.0)
I'm doing a project about"capturing video from webcam"
Thanks
aloha
|
|
|
|
|
Well, after a long time, way too long, I have managed to implement multi threading into my project. Whoever said Multithreading was easy to learn should be taken out and have TCP poured into his eyes.
Anyway, I have got to a part where I need to communicate with the main thread. I am using PostMessage to indicate when the thread has finished which is working no problem. But on each iteration of the thread I want to display some text and increase a progress bar on the main dialog. I am again using PostMessage to do this but the results are not very good.
The problem is because PostMessage returns before the command has executed, text is often missed and the progress bar falls short. Now I am writing the text into global scope, so I somehow need to force the thread to wait until the main thread has done what it should.
After reading through the projects on CP I am left even more confused, there is so much talk of Mutex, Critical sections, Syncronisation... And to make things even more difficult most of them are for MFC which I just can't understand.
Somebody please, in simple terms, what should I do here? And if possible a simple non-MFC example.
Thankyou.
|
|
|
|
|
waldermort wrote: The problem is because PostMessage returns before the command has executed
use sendMessage
never say die
|
|
|
|
|
There's actually a lot of different ways of doing this, depending on what you want.
A simple solution in your case would be to use SendMessage instead of PostMessage. You can pass the pointer to your string as one of the arguments for your message, since SendMessage doesn't return until the call is handled this is fine.
|
|
|
|
|
Maybe I have understood this all wrong, but most of the text's I have read say not to update the GUI from a thread. I don't really understand it but thats what I did. I will try this with SendMessage as you suggest. Thinking about it, I don't know why I didn't try it in the first place.
|
|
|
|
|
It worked a treat.
just one more question if I may.
I am using threads mainly to prevent the main dialog from freezings when performing actions such as load and save. I am also using a SQL database with which all the actions are performed. Would it be safe to have 2 or more threads working on the same database?
I am guessing it would be much the same as Sendmessage, in that messages are sent to the database and a value is returned. But I don't want and can't afford to get this wrong.
|
|
|
|
|
Indeed, as you have posted earlier, you should not update the GUI from anything other than the main thread. By calling SendMessage from your worker thread to your dialog, it is the main thread that is handling the message. The SendMessage call blocks till the message is handled. A special case is when the sending thread and the destination thread is the same, in this case, the call is like calling a subroutine. If this was not the case, then calling SendMessage with the source and destination threads being the same would cause deadlock.
SQL databases are designed to handle concurrency in such a way that it always ends up in a "correct" state. Is there any particular order that you would like certain queries to be performed? Updating by 2 operations like read, then write, without using transactions could be problematic.
|
|
|
|
|
waldermort wrote: ...most of the text's I have read say not to update the GUI from a thread.
True. This is why secondary threads should not use SendMessage() when communicating with the primary thread. It could very easily create a blocking situation. Using PostMessage() allows the secondary thread to continue to work regardless of what the primary thread is doing (e.g., responding to user input).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: True.
So if you are not supposed to use SendMessage, and PostMessage doesn't work, how would you deal with this situation?
Maybe I should also note that these message are only used to inform the main thread of the current progress, text is sent to a status bar aswel as progress bar messages which is also located on the status bar.
When the thread is complete a use Postmessage to send a confirmation to the main thread. The thread then ends itself with a call to _endthreadex().
|
|
|
|
|
waldermort wrote: ...and PostMessage doesn't work...
Why?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
waldermort wrote: Well, after a long time, way too long, I have managed to implement multi threading into my project. Whoever said Multithreading was easy to learn should be taken out and have TCP poured into his eyes.
Creating a thread is easy... balancing it, synchronizing it, reading/writing from it, and many other processing is far more difficult. So no, multithreading is not "easy" from a grand standpoint of overall functionality and control.
I do believe it is important though. You have good suggestions as far as this specific problem, you will find others that need synchronized control (only one thread reading/writing), and that is where Mutex and critical sections come in. There are many tutorials on multithreaded synchronization from java to C++ and C# so there is a lot to choose from out there.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
As the other replies have said, SendMessage is a quick fix, but that negates most of the benefit of the worker thread, since it will block until the main thread processes the message.
Another issue to look at is how often you're updating your progress UI. I personally don't do it more than once every 500ms, because that's fast enough to satisfy a person that stuff is happening. If your updates are happening like every 10 ms or so, there are going to be so many context switches that it will quickly drag down performance.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
