|
Yes that's probably not right thanks
|
|
|
|
|
It's really bad form to use this sort of naming in projects. None of those names have any significance in terms of what they are supposed to represent and, as you have discovered to your cost, it's easy to end up with basic errors such as the above.
Use the best guess
|
|
|
|
|
Richard I thought the names were meaningful
I am writing a Windows MFC/C++ front end the the Hercules MainFrame Emulator
I am using named pipes to communicate with C console applicaton Hercules
the data names Jobname and Progname are the Jobname and Progname to be traced
|
|
|
|
|
ForNow wrote: I thought the names were meaningful I was alluding to your dialog controls IDC_EDIT3, IDC_EDIT4 etc.
Use the best guess
|
|
|
|
|
[Agree 100% with this.]
To elaborate, the resource.h constants (ie. IDC_xxx) should have meaningful names, be numerically unique, the control/value variable names should be meaningful as well, and clearly related to the resource.h constants.
--
Harvey
|
|
|
|
|
Richard MacCutchan wrote: ForNow wrote:
DDX_Control(pDX,IDC_EDIT3,eprogname);
...
DDX_Text(pDX,IDC_EDIT3,progname);
I do not think you should be duplicating these controls in different DDX_xxx statements.
Hmmm ... second high ranking person to say this.
This is not a problem. It is supported and works fine. I have done it many times.
--
Harvey
|
|
|
|
|
It's some years since I wrote any MFC code, but I don't quite understand what's going on here. Surely, if you map the same control to different variables then it is potentially going to end up with some items getting updated with the wrong values. Or do I need to go back and study DDX macros again?
Use the best guess
|
|
|
|
|
DDX_Text is effectively a macro that does [Set|Get]WindowText on the window with given control ID and the given string.
DDX_Control gets a pointer to the window with given control ID, casts it to the appropriate MFC class, and assigns it to the given variable (which is a CEdit in this case).
It's perfectly safe and common practice to have both data and control members of the same GUI element, and has been since MFC 1.0 back in the early 90s.
|
|
|
|
|
Thanks, that makes more sense, but I'm still not sure what the OP's problem is - do you?
Use the best guess
|
|
|
|
|
No, the posted code looks fine, stylistic issues aside, so more information would be needed, in particular OnInitDialog and the button click message handler, but every place where UpdateData is called would need to be checked, as it's a quite common to overwrite the data you want before reading it, which is what I suspect happens here.
Personally, I think that using GetWindowText - which seems to work - makes more sense until one is more familiar with MFC and all its horribleness with magic macros. Use DDX_Control and get and set your data via the control instead.
|
|
|
|
|
Exactly - thanks for responding. I couldn't have given a better answer.
--
Harvey
|
|
|
|
|
H.Brydon wrote: Hmmm ... second high ranking person to say this. Having a high ranking merely indicates that you post a lot of messages here, it does not indicate any level of skill or knowledge. Although, I do try to base my answers and comments on what I have learned, what I can test on my own system(s), or what I can find in the documentation. When I get it wrong I am more than happy to be corrected, that just means I will learn (and hopefully remember) something new.
Use the best guess
|
|
|
|
|
Here are a few of my notes:
- Make sure that the IDC_xxx constants map to unique numbers (check the resource.h file)
- You are doing a number of unusual things with everything declared public. There is no reason for the controls to be public and the variables are usually exposed with accessors if necessary.
Where do you determine that the variables are not populated as desired?
--
Harvey
|
|
|
|
|
Thanks
For your help as you can tell from my reply
I am a mainframe assembler programmer
By trade and I am using this project to
Learn MFC C++ Windows Programming
Thanks again
I appreciate the critique and will revise
The Class
|
|
|
|
|
In case there is confusion. Here is what I am suggesting...
You said (edited):
void Cprogdialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX,IDC_STATIC5,sprogname);
DDX_Control(pDX,IDC_EDIT3,eprogname);
DDX_Control(pDX,IDC_STATIC9,sjobname);
DDX_Control(pDX,IDC_EDIT4,ejobname);
DDX_Control(pDX,IDC_STATIC7,slocation);
DDX_Control(pDX,IDC_EDIT5,elocation);
DDX_Control(pDX,IDC_STATIC8,saddr);
DDX_Control(pDX,IDC_EDIT6,eaddr);
DDX_Control(pDX,IDC_PUSH,process);
DDX_Text(pDX,IDC_EDIT3,progname);
DDX_Text(pDX,IDC_EDIT4,jobname);
DDX_Text(pDX,IDC_EDIT5,location);
DDX_Text(pDX,IDC_EDIT6,addr);
}
What we (collectively) are suggesting is:
void Cprogdialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX,IDC_SPROGNAME, sprogname);
DDX_Control(pDX,IDC_EPROGNAME, eprogname);
DDX_Control(pDX,IDC_SJOBNAME, sjobname);
DDX_Control(pDX,IDC_EJOBNAME, ejobname);
DDX_Control(pDX,IDC_SLOCATION, slocation);
DDX_Control(pDX,IDC_ELOCATION, elocation);
DDX_Control(pDX,IDC_SADDR, saddr);
DDX_Control(pDX,IDC_EADDR, eaddr);
DDX_Control(pDX,IDC_PROCESS, process);
DDX_Text(pDX,IDC_EPROGNAME, progname);
DDX_Text(pDX,IDC_EJOBNAME, jobname);
DDX_Text(pDX,IDC_ELOCATION, location);
DDX_Text(pDX,IDC_EADDR, addr);
}
Making sure that the resource editor is closed (ie. close the window), open resource.h and manually edit all of the IDC_xxx values to make sure that they are unique. The values themselves don't matter that much; just that they are unique.
I would have used "m_ctl" and "m_s" prefixes on the vars as well but that is really just style.
--
Harvey
|
|
|
|
|
|
i was update up update2,but right click still no see code map,,why??thanks for reply
|
|
|
|
|
Sorry, but that does not make much sense. Which code map are you referring to, and where are you right-clicking?
Use the best guess
|
|
|
|
|
uhh..i watched that video in vs2012 video's,,,there are "Code Map" in the vs2012 toolbar on video,but why did not i? thans for reply
|
|
|
|
|
|
What happens when you press Ctrl+` ? Aren't you able to see it in any of the menu/right click on any function?
-Sarath.
Rate the answers and close your posts if it's answered
|
|
|
|
|
I guess you need VS 2012 Ultimate to get the full code map feature.
I tried this with VS 2012 Update 2 and it sure works.
|
|
|
|
|
Hi,everyone.
These days i read a book about the socket .There is a question ,when we bind the address in the server ,we must use the function htons to transform the port to the network byte order, but why do not we need to use the function in the send /recv function ?
i guess some reasons ,but i am not sure about it .
1.Because the TCP\IP protocl will do the transform at the back
2.Because of the parameter char*,it makes the buffer to the array of char and that do not need to transform.
Is there anyone know this ? I am very appreciate for your help .
|
|
|
|
|
Probably because Send/Receive are handling char (7/8bit BYTE) obviously it doesn't create a problem in which order which they arrive.
It only becomes a problem when transmitting 16 bits or larger. I would also hazard a guess than unicode is transmitted MSB first.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
I guess you meant utf-16 when you said unicode. Actually there are little and big endian versions of unicode, both versions have a unique byte order mark at the beginning of the file. Of course if you send utf-16 basically "as a file" with byte order mark and process it accordingly (for example using an utf library) then there is no problem because the library will do the byte swap for you if necessary after interpreting the byte order mark. However if you interpret it as a sequence of 16bit integers then you have to take care. with utf-8 there are no endianness problems but the same is not true for utf-16 and utf-32 that are basically just a series of uint16/uint32 integers - you decide what byte order to use for transferring.
|
|
|
|
|