|
The Undefeated wrote: Im still getting used to C++, been doing C# where comparing strings is easy.
It would have been easy here too, if you had used string classes (like std::string or MFCs CString).
They have an overloaded compasison-operator doing things the "intuitivly right" way.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
The Undefeated wrote:
if(Current->ID == "Player")
from where ID is coming.. and is "Player" is hardcoded...
"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
|
|
|
|
|
Well im just using strcmp() now, but ID was set elsewhere, like this:
Main->ID = "Player", and yes, its hardcoded.
The if statement is in a Function, which is given the pointer to a struct, in this case 'Main'
|
|
|
|
|
Hi all. I have gotten a nesting error from VC and i dont know what i need to do to get what i need done and fix this problem.
The error
[code]
fatal error C1061: compiler limit : blocks nested too deeply
[/code]
What im doing is making a bunch of pre-programmed options. So i have a lot of if/else statements. Something like 30-40 or more. If there is a way to make it more simple i'd like to know. Something like using one main command to call on different functions. Thanx in advance!
|
|
|
|
|
Without seeing your code or knowing more precisely what you are doing, all I can say is
WOW! >128 levels of nesting! (I had to look it up - never heard of that error  )
|
|
|
|
|
From MSDN :The code includes blocks that are nested to a level greater than the compiler limit (128 :-O levels of nesting). Simplify block nesting in the code. :wtf: What a pity !!
Can you use switch or something else ?!!
Can you separate into some functions ?
|
|
|
|
|
I'd be interested in seeing your code but I get the distinct impression that it could be scary.
Steve
|
|
|
|
|
Can anybody explain why only the last UpdateData() works in this code. All the lines seem to appear at once.
CString f;<br />
f = L"Checking database.";<br />
this->m_StatusText = f;<br />
this->UpdateData(FALSE);<br />
Sleep(500);<br />
f += L"Opening database.";<br />
this->m_StatusText = f;<br />
this->UpdateData(FALSE);<br />
Sleep(500);<br />
f += L"Loading data";<br />
this->m_StatusText = f;<br />
this->UpdateData(FALSE);
|
|
|
|
|
Makakuin wrote: Can anybody explain why only the last UpdateData() works in this code.
The bigger question is why are you using it in the first place?
Makakuin wrote: //m_StatusText is a CEditCtrl with value variable CString
Impossible. It's either one or the other. Change m_StatusText to be a CEdit member variable and use SetWindowText() instead.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Sorry - that was just an experiment, and I found out, acciddentally, that only the last UpdateData() worked in this code....
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
