|
How about storing the data to the global variables?
Benben
|
|
|
|
|
keep your data in a structure/class, and pass the reference to the each pages. in case of any validation, do it in corresponding page. gotcha? 
['Loka Samastha Sukhino Bhavanthu' - May all beings be happy and free]
|
|
|
|
|
Mark F. wrote: The problem is I don't know how to store the data variables from one page to the next so that at the last page I can use it other than writing it to a file when next button fires.
Use variables for storing each control value, in respective propertypage class.Validate its values when user press next button.
In last page, you can use this code.
CPropertySheet *pSheet=GetParent();
CPropertPage* pPage1=pSheet->GetPage(1);
pPage1->Aceess variables;
CPropertPage* pPage2=pSheet->GetPage(2);
pPage2->Aceess variables;
|
|
|
|
|
The common link between all of the pages is the sheet. Store the data there.
"Talent without discipline is like an octopus on roller skates. There's plenty of movement, but you never know if it's going to be forward, backwards, or sideways." - H. Jackson Brown, Jr.
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks to all. I worked it out!
"Complexity breeds problems. Keep it simple." - Mark
|
|
|
|
|
Mark F. wrote: I worked it out!
Care to share?
"Talent without discipline is like an octopus on roller skates. There's plenty of movement, but you never know if it's going to be forward, backwards, or sideways." - H. Jackson Brown, Jr.
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi.
I have a capture graph running (capturing video frames from a webcam)and if windows media player (or winamp) visualization is switched to full screen mode, my graph just seems to freeze. Nothing happens, no video, no errors, no events, nothing. When full screen mode is switched off everything goes back to normal.
Help anyone?
Thanks
Aritosteles
PS: guys I know this might be off topic but I found no other place to post my question and I'm quite desperate
|
|
|
|
|
Just started with C++ a few days ago. Everything going good but need some help with classes - ifstream & ofstream.
Need to be able to display the contents of a text file in a console application. Also any info on how to output to a text file. Have included fstream header but just not getting my head around it !!!!
Most web sites visited just dont seem to be providing the info I need.
Any help with basic code included or good links would be much appreciated !!!!!!
Thanks in advance for any info.
|
|
|
|
|
An ifstream will attempt to read any type using the >> operator. An ofstream will write any type using the << operator. So, if you create a std::string, you can read a file a line at a time like this :
ifstream file("iostream test.txt");
std::string s;
while (!file.eof())
{
file >> s;
// do something with s
}
Now, std::endl is the end of line character, you need to insert this as it's used as a delimiter. The same is true if you're writing a file a line at a time.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Hi
Thanks for the code.
Much appreciated as it has been torturing me all afternoon. Working fine now.
Take it easy and thanks for the help.
The problem with political jokes is they get elected.
|
|
|
|
|
Following the CHKBOOK sample in MSDN I finally have two
different views associated with the same document, and working
simultaneously. The problem is that when I run my program I
only get the first view. The second view only appears when I
*open* a document from a file, and not when I start a new one.
The cause is no wonder, because the piece of code that opens
the second view is only inside the OpenDocumentFile() function.
That makes sense in the sample, which is designed to work always
on a file (either is opens an existing file, or it creates a new
one).
Q: What code should I add where, for my application to open both
views on a *new* document?
Furthermore, I have learnt that you can resize a view by calling
its parent frame's MoveWindow() function. I would like to size
each of my two views to a certain desired size at startup. What is
the appropriate place to add this code?
|
|
|
|
|
requemao wrote: Q: What code should I add where, for my application to open both
views on a *new* document?
None. The sample has handled multi-view management already.
After you create/open a document, the main frame adds "Check" and "BooK" menu items to your view menu. You should be to switch views by clicking on either "Check" or "Book".
Best,
Jun
|
|
|
|
|
Sorry, I did not explain it correctly:
It's not the Checkbook application that I'm working on. I am working on an application of my own, which needs to manage and coordinate two different views. I did not know how to achieve that, so I had a look at several articles on CodeGuru and old topics on microsoft.public.vc.mfc, with little to no success. Finally I found the Checkbook sample and tried to imitate it. I succeeded, except that the second view is only shown when I *open* an existing document, but not when I simply start the program or click File/New.
I know I should add some code somewhere, because right now there is only piece of code that spawns the second view, and that is inside CMyApp::OpenDocumentFile(). The question is: where is the appropriate place for that code? (And what is exactly the code, if that's not asking too much).
|
|
|
|
|
Can't be sure without seeing your code. You may verify a couple of things:
1) Your app overrides OpenDocumentFile() so that it displays any views beside the default. The base class OpenDocumentFile() opens the first view as the default.
2) Let your app to handle file-new command, and call the overriden OpenDocumentFile() in the command handler.
Best,
Jun
|
|
|
|
|
Jun Du wrote: 1) Your app overrides OpenDocumentFile() so that it displays any views beside the default.
Yes, this is done. When I open an existing document (and ONLY then), both views appear and work correctly. It is done this way (just like the sample):
CDocument* CSequApp::OpenDocumentFile(LPCTSTR lpszFileName) <br />
{<br />
CSequDoc* pDoc = (CSequDoc*) CWinApp::OpenDocumentFile(lpszFileName);<br />
if (pDoc == NULL)<br />
return NULL;<br />
CFrameWnd* pNewFrame = m_pEditorTemplate->CreateNewFrame(pDoc, NULL);<br />
if (pNewFrame == NULL)<br />
return pDoc;<br />
m_pEditorTemplate->InitialUpdateFrame(pNewFrame, pDoc);<br />
}
Jun Du wrote: 2) Let your app to handle file-new command, and call the overriden OpenDocumentFile() in the command handler.
At present, I have this in the message map:
ON_COMMAND(ID_FILE_NEW, CWinApp::OnFileNew)
If I understand you correctly, I should change it to...
ON_COMMAND(ID_FILE_NEW, OnFileNew)
...and then define the OnFileNew function:
void CSequApp::OnFileNew()<br />
{<br />
CWinApp::OnFileNew();<br />
... (some call to OpenDocumentFile())<br />
}
Is this right? In that case, what's the code I have to add there? I don't think I'll get it right myself...
|
|
|
|
|
requemao wrote: If I understand you correctly, I should change it to...
ON_COMMAND(ID_FILE_NEW, OnFileNew)
...and then define the OnFileNew function:
void CSequApp::OnFileNew()
{
CWinApp::OnFileNew();
... (some call to OpenDocumentFile())
}
Yes.
Best,
Jun
|
|
|
|
|
Check out this technical article [^]; it describes how OnFileNew() should be overridden. Basically, in case of multiple document templates, don't call base class'
CWinApp::OnFileNew();
in CSequApp::OnFileNew(). Add code to retrieve the file name first and then call
OpenDocumentFile(fileName);
The resulting code should be similar to CHKBOOK sample code.
Best,
Jun
|
|
|
|
|
Jun Du wrote: in CSequApp::OnFileNew(). Add code to retrieve the file name first and then call
OpenDocumentFile(fileName);
I must be overlooking something. Even after reading the whole tech note and browsing trough the member functions of CDocument and CWinApp, I still haven't found out how to retrieve the file name (which is required by the OpenDocumentFile() function). Can you please point me to the function I need?
Manuel M.
|
|
|
|
|
The relevant part from the article is:
"One common customization of ID_FILE_NEW is to provide a different and more graphical choice of document types. In this case you can implement your own CMyApp::OnFileNew and place it in your message map instead of CWinApp::OnFileNew. There is no need to call the base class implementation."
Maybe this is where you find confusing:
The base class OnFileNew() doesn't ask for the file name, because it automatically creates one ("New") for you. However, it only displays one view. Without overriding OnFileNew(), you won't get more than one view at the startup. You have to override OnFileNew() and call OpenDocumentFile(), which requires a file name and the file must be created before the call.
After reviewing the CHKBOOK sample code carefully, you'll find its OnFileNew() does only two things:
1) Prompt a GUI to ask for the new file name and create the file.
2) Call the overridden OpenDocumentFile() with the file name.
It didn't call base class' OnFileNew(), which I think you know why now.
So, the code before calling OpenDocumentFile() should be:
1) Constructing a file name (either asking the user or use "New" as the default).
2) Creating that file physically on the current folder.
Note that this is how CHKBOOK is implemented and it looks like what we have to do if we use OpenDocumentFile().
Best,
Jun
|
|
|
|
|
It now works, thanks to you!
I appreciate the effort you have put in explaining this to me and giving me accurate pointers. You have taught me quite something, thank you very much.
Manuel M.
|
|
|
|
|
You're welcome. Glad it worked out finally.
Best,
Jun
|
|
|
|
|
Does anybody know if there is an option for non-grid fitting ClearType Font rendering in GDI+ ?
I use the AntiAlias FontRenderingHint currently which yields fairly stable string widths at various scales but the readability suffers a tad (blurry) so I wanted to see if ClearType would help, but I can only find a grid fit for cleartype in the enumeration which suffers the same width/height issues as GDI fonts at various scales due to hinting/rounding errors etc...
I would guess non grid fit rendering would be possible with subpixel rendering but it seems to not be a reality for GDI+
Any ideas on whether this is even possible and where one might find it if it were?
|
|
|
|
|
I'm trying to pass a struct by reference to a callback function, but I cannot for the life of me deference it. Here is the initialization and sending of the struct
WINDOW_SKIN ws;
ws.iSize = sizeof(WINDOW_SKIN);
...
hWnd = CreateWindow( WINDOWBITMAP_CLASS,
...
hInstance,
&ws );
Just as you would do with any other struct. But on the recieving end:
WINDOW_SKIN *ws = (WINDOW_SKIN*)lparam;
if ( ws->iSize == sizeof(WINDOW_SKIN) )
The ws pointer holds the address of lparam, and the iSize paramater holds the address of the struct. I know lparam is a pointer to a an address, but how can I get to my data?
|
|
|
|
|
Never mind, after trying several gazzillion variations I found it.
WINDOW_SKIN *ws = *(WINDOW_SKIN**)lparam;
|
|
|
|
|
The only reason that works, and not (WINDOW_SKIN*) is that you didn't pass a WINDOW_SKIN*, but a WINDOW_SKIN** - or you're incredibly lucky. Have you looked at what you pass to CreateWindow and what you receive in your WM_CREATE handler (I'm assuming it's WM_CREATE), using the debugger?
--
Torn from tomorrow's headlines
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
