|
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.
|
|
|
|
|
From what I've recently read/heard about UTF-16 (plus more javascript issues), and space for 1 million code points, it is now UTF-20, but nobody bothered to rebless the name.
see this --> mathiasbynens.be/notes/javascript-encoding
You're correct about the BOM, I just forgot.
"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.
|
|
|
|
|
UTF-20 LOL
|
|
|
|
|
You don't have to use the function on the data that you are transferring.
If you don't know what endianness means then read this first: http://en.wikipedia.org/wiki/Endianness[^]
When you are filling some data structures of the socket api (like the port parameter of sockaddr_in) then you have to specify the port number in big endian as the socket api expects you to give port numbers and inet4 addresses in big endian format. The reason for this is probably that some guys decided to use big endian. (I think requiring the use of htons and its friends was a bad idea as this transormation from host to network byte order could be done by the socket api implementation itself, but thats another subject for debate...). htons() always returns the 16 bit integer in big endian format regardless of the endianness of your machine. If your machine is big endian then it does nothing, if your machine is little endian then it swaps the bytes. Anyway the htons is a acronym for HostToNetworkShort - I didn't know that for some time in the past and without that it was quite hard for me to memorize these functions: HostToNetworkShort, NetworkToHostShort (16bit), HostToNetworkLong, NetworkToHostLong (32bit). Since these days most of the user machines and a lot of server machines are little endian you have to use these functions when the socket api you are calling requires them.
When you are transferring your own data you decide what byte order to use. For example if both of your machines (server and client) are little endian then it is logical to transfer 16bit and wider integers in little endian. However if the endianness of the machines are different then you have to choose whether you use little or big endian format in your data stream. If you choose little endian, then you have to do nothing on the little endian when you are sending/receiving network data, but you have to swap byte order on the big endian machine.
Since you called this whole stuff "the big-ending and little-ending" I assume you know not too much about endianness and I try to give you some help here. The two most important parts of the computer from the programmer's perspective are the processor and the memory. Imagine the memory as a big byte array. (pointers are basically just indexes into this byte array! What the computer does is basically the following: It reads instructions from the memory and executes them. During instruction execution the processor loads values from the memory into its own internal storages ("variables"/registers http://en.wikipedia.org/wiki/Processor_register[^]) and then performs calculations with these loaded values and later the processor stores these values back to memory. The difference between big-endian and little endian processors is the way they load/store integers that consist of more than 1 byte. Lets demonstrate that with and example: lets say you have a 16 bit integer in memory (2 bytes in hexadecimal):
01 00
If you load these 2 bytes on a little endian machine then the processor will load it as 0x0001, but a big endian will load these 2 bytes as 0x0100.
The same is true not only for data loading from memory but also for storing. Lets say you make complex calculations and the result is a 16 bit number that you want to store somewhere in memory. If the result of the calculation is 1 then a little endian processor stores 01 00 into the memory while the big endian stores 00 01.
TCP does nothing with the order of bytes when you transfer them over the wire. However if the endianness of the 2 machines (connected by TCP) differes then you have to take care.
Lets say you connect a little endian windows machine with a big endian linux machine using TCP. You calculate this, calculate that on your windows machine and lets say the result of the calculation is 1. You store this to memory on your little endian windows machine (01 00) and send it with TCP to the linux machine. If you load it on the big endian machine without byte swap then the big endian machine will see 0x0100 and not 0x0001. You can decide to use big endian in your transferrable data but in that case you have to convert on the windows machine (instead of the linux) every time you load or send network data.
|
|
|
|
|
Thank you for help , i got it .
|
|
|
|
|
You are welcome! There is one more thing I forgot to mention: when I have machines with different endianness I usually choose the endianness of the server for transferring data over the network. This way the byte swaps must be done by the clients - the server is usually a performance bottleneck as it has to communicate with a lot of clients while a client has not much to do, just communicates with the server. In general its a good practice to push every kind of computation/task to the clients whenever possible.
|
|
|
|
|