|
Well, i believe you should be able to do something like that using DirectX, usually if your video card has an S-Video output it will either simply clone what you see on your monitor thorough VGA (or DVI) or you can choose between a few possibilites about what the card should output on the S-Video "port", clone the display, or create a second separate dekstop, or span the desktop between the two display devices (so half of your desktop is on the S-Video screen and half is on the VGA screen)... i am not sure weather you can control these settings programatically though. However, i think if you for example set up 2 separate desktops you can get access to the "secondary display's" video memory using DirectX.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
VLC does this. Download it, then run it and open a "Capture Device", it's way of saying DirectShow.
Then, depending on your version, type in
screen:
to the command line it shows at the bottom of the "open" dialog, or choose "Desktop" from a list of capture devices (same thing internally).
If you want to save it, "stream" this to a file by clicking on "stream" or the "more options" arrow and then on "stream", then entering a file name and an encoding preference in the dialog that follows.
|
|
|
|
|
It would be very helpful to get some links to similar projects or source code.
The prefered method would be to build the video frames without displaying them on screen but rather passing them directly to the video memory. Although if this isn't possible then the other method you suggested might work, but then I do need to programatically create two seperate desktops and then "draw" on only one of them.
|
|
|
|
|
I believe all you need (no, not love) are a few DirectX tutorials and those linger all around the net, just use codeproject's search engine or google. You can create a backbuffer, render your frame onto it and then display it on the screen, this is the commonly used way to render flickerfree animation in -for example- games.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Ok, Thanks for your help.
Yair
|
|
|
|
|
I have a SDI app in which I want to serialize data in a custom structure which is indescribable using predefined MFC CDocument-Derived classes (e.g. CRichEditDoc or CDocument)! Let's suppose that's something like the following structure:
struct MY_DATA
{
BOOL bIsDeleted;
UINT uPosition;
BYTE *RTF_Data;
}
I have a splitter window with 2 rows and 1 column. One of its view is derived from CRichEditView and the other from CMyAppView (derived from CView). CMyAppDoc is derived from CDocument. I wonder how to save and load the above structure in this situation!
Thank you masters!
|
|
|
|
|
Is the MY_DATA structure part of the document?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
|
Then why not just save it when OnSaveDocument() is called?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
The problem lies in this that I can't use CRichEditDoc::Serialize: because the CMyAppDoc is NOT derived from CRichEditDoc.
|
|
|
|
|
Won't this work:
void CMyAppDoc::Serialize( CArchive &ar )
{
if (ar.IsStoring()
{
ar << my_data.bIsDeleted;
ar << my_data.uPosition;
}
else
{
ar >> my_data.bIsDeleted;
ar >> my_data.uPosition;
}
}
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
What about the contents in RichEdit control (or RichEditView, whatever) within the splitter window. I wanna serialize it as well...
|
|
|
|
|
Regardless of the view chosen, the data comes from the document.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Jusef Marzbany wrote: What about the contents in RichEdit control (or RichEditView, whatever) within the splitter window. I wanna serialize it as well...
"Contents" you mean the data typed in the editview? Whatever. It should be save into the document finally. Where you can make use of the ::Serialize() function.
You have missed the point clearly. Would you mind reading the doc/view concept again? I'm not kidding. Just go through it once and you'll get a better picture. You are most welcome to come back.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
Well, you chose not to make it from CRichEditDoc..
If you've chosen these views, then you already need to have a mechanism to talk between CRichEditView (and your other kind of view) and CMyDoc - whatever that is.
You must have chosen these views for a reason, so you must already have an idea how to represent your data in the views?
So, break the problem in to two.
1/ Save the document information using serialise.
2/ In CWhateverView::OnUpdate, get the document data and put it into your view somehow...
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job!
|
|
|
|
|
Thnx 4 Ur attention! but I've choosen CRichEdiiitView to view a part of data, not the whole!
|
|
|
|
|
Heje, you must be really excited about CRichEdiiitView!
You make a good point - I've looked back at the first post, and you do have a BYTE *RTF_Data; part of your data structure.
And your approach is a good one - you have two ways of looking at your data, so you have two views in a splitter window. So far so nice.
But you still have two separate questions to answer...
1a/ Shoving that document data into the view whenver it changes...
1b/ When a user types something in the richedit control, putting it back into the document - if it's readonly, this does not exist.
You can solve both of these by looking in the code for CRichEditView/Doc - some clever MFC gnome will already have the solution ready for you to copy.
2/ Serializing the MY_DATA structure to and from a file.
You can't just copy the structure in, as one of the members is a pointer. Do a search for the code for how CArray or CStringArray serializes. You'll find the first send / read a number which describes how large they are. You can adapt this idea also.
I've now typed a bunch - you'll have to try things out, and if you need further help, get back to me / us. Hopefully you'll have made a smaller problem by then!
Good fortune,
Iain.
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job!
|
|
|
|
|
thank you a lot! 
|
|
|
|
|
Iain Clarke wrote: 1/ Save the document information using serialise.
Wow, that's pure English!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I really need the result! PLEASE don't mix this piece with these jokes. Thank you ...
|
|
|
|
|
I can't: it is my nature, anyway, good luck.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
no no no! I didn't mind to offend you. You are, as I've told several times, a genius. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Jusef Marzbany wrote: no no no! I didn't mind to offend you.
I'm not hurted. At the moment you're helped by two of the best CP's members, I have nothing to say, technically, on the argument. I was sincerely wishing good luck to you (since you appeared worried).
Jusef Marzbany wrote: You are, as I've told several times, a genius.
If you recall me your postal address I'll send you the bucks ASAP.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi,
Just a brief question regarding the Dialog Data Exchange process
The User Calls UpdateDate with a Flag "BOOL bSaveAndValidate" which seems from the MSDN
doc
To be a public member of the CDataExchange Class
However from an Artcle of the CodeProject titled "Dialog Data Exchange in MFC"
seems that the UpdateData Fuction Ccreates the CDataExchage Class
The User supplies the pointer to this class in the Overrideable DoDataExchage
method
|
|
|
|
|
Yes, what is your question ?
|
|
|
|