|
This code has just the same effect. I`ve placed a button and a editctrl on dialog for testing purposes and aded the above code in OnButton1 , but the text appears all at once after a 1500 miliseconds pause...
CString f;<br />
f = L"Checking database. ";<br />
this->c_StatusText.SetWindowTextW(f);<br />
Sleep(500);<br />
f += L"Opening database. ";<br />
this->c_StatusText.SetWindowTextW(f);<br />
Sleep(500);<br />
f += L"Loading data.";<br />
this->c_StatusText.SetWindowTextW(f);<br />
Sleep(500);
|
|
|
|
|
How about giving the control a chance to refreshredraw...
CString f;
f = L"Checking database. ";
this->c_StatusText.SetWindowTextW(f);
this->c_StatusText.UpdateWindow();
Sleep(500);
f += L"Opening database. ";
this->c_StatusText.SetWindowTextW(f);
this->c_StatusText.UpdateWindow();
Sleep(500);
f += L"Loading data.";
this->c_StatusText.SetWindowTextW(f);
this->c_StatusText.UpdateWindow();
Sleep(500);
|
|
|
|
|
Yes! This works! Don`t know how I forgot about this function...
Thanx!
|
|
|
|
|
Perhaps this link[^] will make you look differently on UpdateData().
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Interesting link, thanks!
I could only find one item, from my experience, that's true...
I can never remember which way does TRUE or FALSE cause the data exchange to go.
The rest seems to be either examples of poor MFC programming practices or maybe it's dated -
MFC 4?
Mark
|
|
|
|
|
Mark Salsbery wrote: I can never remember which way does TRUE or FALSE cause the data exchange to go.
I used to have that problem. There seems little that perhaps two functions would have been a better choice.
Steve
|
|
|
|
|
As much as I like Dr. Newcomer's articles, I've got to disagree with him here.
For simple dialog interaction, MFC's dialog data exchange (DDX) and UpdateData() are the way to go. The wizards give you an easy way to get data into and out of your application, especially if you're new to MFC and/or Windows programming. DDX/DDV provides a consistent means of converting between Windows controls and variables in your code. For the more sophisticated, the DDX and DDV functions are an extensible framework for adding your own styles of interaction.
UpdateData isn't intended to provide 'fine' control, which seems to be the bulk of Dr. Newcomer's complaint. If you need separate controls to behave differently, or if there are dependencies between controls, then UpdateData isn't going to do what you want, since that isn't what it's designed for. For those cases, you will need to go the 'control variables' route which he advocates. The bad thing about that is, it's entirely up to you to do the transference between Windows controls and program variables yourself, along with any validation necessary. You must write a lot more code. My gut feeling is, for most dialogs, that isn't needed.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: For simple dialog interaction, MFC's dialog data exchange (DDX) and UpdateData() are the way to go.
Well, Gary, I'd like to put it in a more humble way and just say that it may be a matter of opinion and I beg to differ. Perhaps it depends on what you mean by simple.
Each time you call UpdateData, variables that are subject to DDV will be validated and if the value is considered invalid an annoying message box will appear.
This implies, in my opinion, that DDV should not be done unless the user performs some kind of "save" operation, like closing the dialog box with the OK button. Since DDV is triggered by a call to UpdateData, a direct consequence is not to call UpdateData. I get the impression that this is also what Newcomer is talking about.
Another side effect is that if you choose to validate the data of a control when the data changes, the data of all the controls in the dialog will be both exchanged and validated which I consider unnecessary and it implies that this is not the way it should be done.
Gary R. Wheeler wrote: UpdateData isn't intended to provide 'fine' control, which seems to be the bulk of Dr. Newcomer's complaint
Depends on what you mean by "fine control", but I suspect that what you mean by this is what Newcomer talks about in another essay regarding control variables.
He specifically points that essay out as well.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Hi Roger,
Not speaking for Gary, but since I agree with his reply -
I thought this statement in the artice "You should never call UpdateData in a modal dialog. Just
Don't Do It. Ever." was quite extreme. The DDX stuff is pretty clearly documented and all the
examples in the article are uses that go beyond what DDX seems to be intended to be used for.
In a typical dialog, the controls are initialized, the user interacts with the dialog, the user
chooses to commit any changes or cancel. DDX works perfectly for this.
All this "talk" about validation applies to extracting values back out of controls, which only
needs to be done once in the life of a modal dialog. If there's a need to use the value of a
control to perhaps alter the contents/state of another control then to me that is what I read
Gary's "'fine' control" to mean. DDX, IMO, wasn't intended for that.
Regarding the original poster - Using UpdateData to update a control, besides being inefficient
(ie if there was 100 other controls being updated in the exchange), it is, IMO, a perfectly
valid method. Hopefully he read the article and understands the potential pitfalls.
Thank you for posting the link. Agree or disagree, I always enjoy those articles. 
Cheers!
Mark
|
|
|
|
|
Mark Salsbery wrote: I thought this statement in the artice "You should never call UpdateData in a modal dialog. Just
Don't Do It. Ever." was quite extreme.
Of course it's extreme.
I've read Joe Newcomer's articles back and forth. Some of it I don't share his opinion in, but most of it I can relate to.
Joe has a certain style when writing his essays and articles which can be provocative, extreme and/or offensive. I don't know Joe Newcomer in person, but his writing style reminds me of myself; I too can get provocative and somewhat offensive when trying to explain my thoughts, but always with a humorous twinkle in the eye.
So that's just the style he writes in. Consider it a wake up call, try to see his picture but like he states himself: "I find nothing wrong with disagreeing with another programmer". 
Regarding the DDX/DDV stuff, it has it's legimite usage.
But I agree with Joe in the sense that UpdateData should not be called while the user interacts with the dialog. But that's my opinion.
Regarding "fine control" there's not really much to say than DDX/DDV was never intended to be used for that, so I guess we agree on that...
Mark Salsbery wrote: Thank you for posting the link. Agree or disagree, I always enjoy those articles.
I don't know if there's been some kind of a mixup. I didn't reply to you, the link was intended for the OP in order to widen his thoughts about the use of UpdateData.
I'm glad you liked the article though. 
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Roger Stoltz wrote: I don't know if there's been some kind of a mixup. I didn't reply to you
No mixup. Just discussion (or hijacking a thread, however one looks at it) 
Roger Stoltz wrote: "I find nothing wrong with disagreeing with another programmer"
I find I learn alot doing that, or when others do that
Mark
|
|
|
|
|
Roger Stoltz wrote: DDV should not be done unless the user performs some kind of "save" operation
DDV routines only validate on save operations. The first argument to the DDV routines is a pointer to an object of type CDataExchange, which includes the member m_bSaveAndValidate. All of Microsoft's DDV routines check this value prior to issuing an error. This value is TRUE only if you call UpdateData(TRUE), which means you are doing a save operation.
This seems wasteful, until you see how economical it is. You code a single DoDataExchange function that works for both moving program variables into Windows controls, and then back again. For each control, you have one statement that handles the transfer, and a second statement that handles the validation.
Roger Stoltz wrote: Another side effect is that if you choose to validate the data of a control when the data changes, the data of all the controls in the dialog will be both exchanged and validated which I consider unnecessary and it implies that this is not the way it should be done.
UpdateData() is intended for use in dialog boxes that are essentially "fill-in-the-blank" forms. This was the primary behavior and use of dialogs when MFC was first created.
Developers discovered how easy dialog programming is. As a result, more and more applications were written as dialog apps. Dialogs are now applications made up of controls, and the "fill-in-form" metaphor is less applicable.
I'm simply trying to point out that Dr. Newcomer's out-of-hand rejection of DDX/DDV and UpdateData ignores perfectly valid uses of the facility, especially for simple applications.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: DDV routines only validate on save operations. The first argument to the DDV routines is a pointer to an object of type CDataExchange, which includes the member m_bSaveAndValidate. All of Microsoft's DDV routines check this value prior to issuing an error. This value is TRUE only if you call UpdateData(TRUE), which means you are doing a save operation.
Of course, this is how DDX/DDV works and if you've got the impression that I don't know how DDX/DDV works; I apologize for not being very clear on that. I know very well how it works, I've even stepped through the call chain when I started doing dialogs with MFC about a decade ago. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
My point was that, in my opinion, the data should not be saved until the user has confirmed it by clicking the "OK"/"Apply" buttons or similar. The other direction, i.e. copying the data to the controls, is irrelevant since nothing will be validated using DDV.
I'm talking about when to to perform a save operation, not how.
Regarding the "fill-in-the-blanks" form, I agree that DDX/DDV has it's legimite usage.
My initial intention with my post to Makakuin, was to give some perspective to the usage of UpdateData, not to start a religious dispute on whether DDX/DDV is good or evil.
My post was meant to be informative. The OP didn't provide enough information to advise whether DDX/DDV should be used or not, no matter what opinion I might have on the concept.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
don't call UpdateData(false) at regular interval...it update whole screen when called.. better use individual control
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and you
|
|
|
|
|
The MFC SDI program has a document/view architecture and a dialog based flat file database.
At times,
1. the rich text in the view must be "read only" (preferably the user is unable to obtain focus in the view)
2. while the user makes changes to the database
3. and saves the changes to the document as a whole (which of course does not contain any changes to the rich text the user can read but not edit in the view).
At other times, all parts of the document view and database are availble for edit and save.
QUESTION: How does one prevent changes to the view while allowing full "read only" access (including scrolling) of the rich text in the view (preferably from OnInitialUpdate), and still allow editing and normal file save (savemodified and dosave) for the (changed) dialog-based database?
NOTE: Using PretranslateMessage in the Doc file traps keyboard input for a partial resolution, however, it also disables the scroll bar so only one page of the view may be displayed.
SUGGESTIONS?
Thanks.
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
Have you tried EM_SETOPTIONS with ECO_READONLY flag (CRichEditCtrl::SetReadOnly(BOOL)) ?
I can't remember if that still lets the user scroll...
|
|
|
|
|
Thank you!
EM_SETOPTIONS with the ECO_READONLY flag set rings the bel when the user attempts to edit the view, and does allow scrolling.
Thanks again!
It appears you are the person who helped me before.
Your assistance is very much appreciated!
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Richard Feynman, Minority Report to the Official Report on the Space Shuttle Challenger Crash
|
|
|
|
|
Hello all,
I'm trying to port an old application to visual C++ 2005.
I'm thinking on buying it since the express version seems great.
What I've found strange is that in that old application I had several RegisterWindowMessage() calls in the header file of the app class.
I'm registering the messages in the header file of the CMainApp class: (CMainApp.h)
static const UINT wm_regmsgModeChange = RegisterWindowMessage(WREG_MODE_CHANGE);
As an example, in one of the dialogs (CTestDlg.cpp) I use:
BEGIN_MESSAGE_MAP(CTestDlg, CDialog)<br />
ON_REGISTERED_MESSAGE(wm_regmsgModeChange, OnModeChange)<br />
END_MESSAGE_MAP()
I'm getting this error:
error C2440: 'static_cast' : cannot convert from 'void (__thiscall CTestDlg::* )(WPARAM,LPARAM)' to 'LRESULT (__thiscall CWnd::* )(WPARAM,LPARAM)'<br />
None of the functions with this name in scope match the target type
I've searched the MSDN, but I've no idea on what is happening here...
I've seen that the examples from Microsoft are like mine, except the fact that they register the message on the same dialog that it will be used.
I need to use the registered messages in more than one dialog. Which would be the correct steps?
As always, thank you in advance.
|
|
|
|
|
The compiler error is telling you everything you need to know. The message handler needs to be a function that returns LRESULT, but your handler returns void.
|
|
|
|
|
To expand on Michael's post a bit:
Some time ago (MFC 7.0, I believe), Microsoft tightened up the type definitions for user-defined message handlers. In MFC 4.2 (VC6), a message handler could have the following prototype:
void OnMyMessage(WPARAM wParam,LPARAM lParam); In MFC 7.0, they changed the required type to be the following:
LRESULT OnMyMessage(WPARAM wParam,LPARAM lParam); The only real change is the addition of a return type. Note that this was never a functional change. User-defined handlers were always supposed to return an LRESULT, but most didn't.
Modify the return types of your handlers, add a return (LRESULT)0; to the end, and you're all set.
Software Zen: delete this;
|
|
|
|
|
Does anybody know of any good books for VC++ 6.0 that covers more advanced topics? Something that's more advanced that the beginners books like "learn VC++ in a week" type of books.
Some topics that I'm interested in are stuff like multimedia software, database software, communication with online servers, coding USB hardware and the drivers for it, etc...
Thanks
|
|
|
|
|
Have you thought of moving to VC8 ? I doubt there's any VC6 books still in print.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
what are the major benefits of moving to VC8?
I'm asking about VC6 because that's what I use at work, and so far, VC6 has been adequate for what I'm doing. I will have to have a good reason for my boss to fork out the extra money for VC8.
|
|
|
|
|
acerunner316 wrote: what are the major benefits of moving to VC8?
For most folks, it's either the standards-compliance, or the new bells and whistles. It's been nearly 13 years since VC++ v6 was introduced so a fresh tool is (most of the time) welcome.
acerunner316 wrote: I'm asking about VC6 because that's what I use at work, and so far, VC6 has been adequate for what I'm doing.
Same here. I also have the added constraint that my product is a plug-in to a much larger commercial application.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
VC8 is standards compliant, VC6 is not. That's really the main reason I like it. VC8 does also build prettier UI.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
