|
You can call it from anywhere. You usually call it first from CDialog::OnInitDialog to set the initial values of the variables. Then you call it at other times, in response to user input to save any new values.
|
|
|
|
|
ForNow wrote: I have a CStatic ptr says
CStatic *mytext
Why use a pointer? Just add:
CStatic mytext;
to your dialog's header file. Add an entry to your dialog's DoDataExchange() method like:
DDX_Control(pDX, IDC_MYTEXT, mytext);
Then in your dialog's OnInitDialog() method, set the control's text like:
mytext.SetWindowText(_T("Hello World"));
And that's it! No need for pointers, memory allocation, or messy calls to UpdateData().
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Thanks in a related question if I wanted to change the font of the text I'm guessing I would do that in a the OnCtlColor would I use pWnd->SetFont (of course after I created a font) with CreateFontIndirect or would I use the pDC and do pDC->SelectObject
Thanks
|
|
|
|
|
See the "Bold static controls" section of this article.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
You are really helpful I am going to press my luck and ask the following if the variable was a CString using DDX_Text as per jeron1 would I then look to change The font in OnCtlColor
Thanks
Thanks
|
|
|
|
|
I do not know. In 23 years of using MFC, I've never used a CString as an interface to a static control. Give it a whirl and let us know how it works.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I can't imagine setting or changing the font color being affected by the type of variable (CString or CStatic)associated with the control.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I was just looking to change the font of a control associated with a CString
David's suggestion would work if I associated the control with a CStatic CWnd object
Thanks
|
|
|
|
|
Another way could be like something shown here[^].
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
How often are you changing fonts? Once? if so just call SetFont(...) on the static control object in the OnInitDialog() handler and be done with it (make sure the CFont object is a member of the dialog class). After that you can call SetWindowText() whenever you want. Should be quick enough to try.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I agree the only things I was adding is the I have to add the message handlers to my CDialog derived for it work per day he article
Thanks will try Tommrow
|
|
|
|
|
jeron1 just wanted to thank you I couldn't get anything going with DDX_Control/CStatic
but the DDX_Text/CString worked out great
Thanks
|
|
|
|
|
Hi,
I'm developing a server multithread (multiclient) and I have a problem with recv function (c language - SO: windows).
My clients send info to server every 5 seconds and recv function blocks thread until info arrives. I try with ioctlsocket, but the number of byte read always is 0; I try with flag MSG_PEEK, but the data is copied into the buffer, but is not removed from the input queue and so I have many messages.
Is there a way to perform recv function no blocking?
THANKS
|
|
|
|
|
Usually a blocking recv is not a problem at all in a multithreaded application: the receiving thread blocks but the other threads keep runnning and the application is responsive.
On the other hand, as you may find in the documentation[^], you might use non blocking mode on sockets, however, I guess, your application would be more involved.
|
|
|
|
|
Thanks for reply.
The problem is, if my server must send data to client, it waits 5 seconds because recv function blocks thread.
I try to launch another thread (for each client) for send operation, but cpu works 100%.
|
|
|
|
|
Quote: The problem is, if my server must send data to client, it waits 5 seconds because recv function blocks thread.
As far as I know, the server's send is not blocked by the client recv.
Quote: I try to launch another thread (for each client) for send operation, but cpu works 100%.
Waiting on I/O operations should not consume CPU, there's probably a flawn in your code.
|
|
|
|
|
DWORD WINAPI cliTh1( LPVOID lpData ){
struct CLIENT_INFO *pClientInfo;
char szClientMsg[250];
char packet[50];
HANDLE clientTxThread;
pClientInfo = (struct CLIENT_INFO *)lpData ;
char *ip = inet_ntoa(pClientInfo->clientAddr.sin_addr);
printf("SOCKET:%d - IP:%s - THREAD_ID:%ld\n", pClientInfo->hClientSocket, ip
,GetCurrentThreadId());
Q->pClient = pClientInfo;
pClientInfo->primaConn = 0;
pClientInfo->indirizzo = 0;
pClientInfo->p = getDisconnect;
while ( 1 ){
if(j>=MAXELEMENTS){j=0;};
if(WSAGetLastError()){
if(pClientInfo->primaConn == 1){
disconnectBuffer[pClientInfo->indirizzo] = 1;
pClientInfo->primaConn=0;
}
if(disconnectBuffer[pClientInfo->indirizzo] == 1){
creaPackDisc(packet, pClientInfo->indirizzo);
strcpy(bufferRx[j].packet, packet);
Enqueue(Q, packet);
j++;
}else{
closesocket(pClientInfo->hClientSocket);
ExitThread(pClientInfo->txThId);
ExitThread(GetCurrentThreadId());
}
Sleep(1000);
}else{
if((pClientInfo->primaConn == 0) && (pClientInfo->indirizzo != 0)){
pClientInfo->connessione = setConnect(GetCurrentThreadId(), pClientInfo->indirizzo, ip);
if(pClientInfo->connessione == 1){
pClientInfo->primaConn = 1;
}
clientTxThread = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)txThread,
pClientInfo,0,&pClientInfo->txThId);
if ( clientTxThread == NULL ){
printf("Unable to create client thread");
} else {
CloseHandle( clientTxThread ) ;
}
}
if(recv( pClientInfo -> hClientSocket, szClientMsg, sizeof( szClientMsg ), 0 ) > 0){
strcpy(bufferRx[j].packet, szClientMsg);
memset(&szClientMsg[0], 0, sizeof(szClientMsg));
pClientInfo->indirizzo = calcolaHighLow(bufferRx[j].packet[1], bufferRx[j].packet[2],
bufferRx[j].packet[3], bufferRx[j].packet[4]);
Enqueue(Q, bufferRx[j].packet);
j++;
strncpy(message, "ACK\n\r",5);
send(pClientInfo -> hClientSocket , message , 5 , 0);
}
}
}
return(TRUE);
}
CPU works 100% with this solution.
|
|
|
|
|
|
Yes, I'm testing <n> clients with server on the same machine. My goal is: if the system works fine on my pc, I will have no problems on server machine.
Is there a minimal example of recv no blocking?
|
|
|
|
|
Did you read the linked page? It is normal a 100% CPU usage if they both run on the same machine.
|
|
|
|
|
If you only have one physical machine, I suggest installing Windows in a virtual machine, and running one of the tasks there. That would ensure that the platforms are separate, and would help you to track down the 100% CPU issue.
IMO, a multithreaded blocking recv() implementation is conceptually much simpler than a non-blocking recv() implementation.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Daniel Pfeffer wrote: IMO, a multithreaded blocking recv() implementation is conceptually much simpler than a non-blocking recv() implementation.
Yep, and it works really well... just be careful for hanging sockets in Linux.
Daniel Pfeffer wrote: If you only have one physical machine, I suggest installing Windows in a virtual machine, and running one of the tasks there. That would ensure that the platforms are separate, and would help you to track down the 100% CPU issue.
This might actually yield the same result. The issue is the super low latency in the network when everything is co-located. Essentially if you're tx and rx run as fast as possible, it could take up all the CPU time available.
modified 30-Jun-15 19:41pm.
|
|
|
|
|
Albert Holguin wrote: This might actually yield the same result. The issue is the super low latency in the network when everything is co-located. Essentially if you're tx and rx run as fast as possible, it could take up all the CPU time available
I thought the problem was an optimization in the network stack that gave special treatment to packets sent to the local IP address (127.0.0.1 or the network address). In this case, the data are simply copied to the recv() buffer, without any thread switches etc.
The network drivers provided by the virtual machine monitor may not be optimized to such an extent. While it is possible to detect (and optimize for) packets sent to/from the host O/S, there would be no point in it as the emulation would be less close to a separate machine. I suspect that the virtual machine monitor emulates the physical network card driver, leaving the rest of the network stack untouched.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
 perhaps.... you would really only run into this issue in certain cases (where it would actually be a problem), where the data source isn't throttled and infinite (i.e. mostly test cases)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
