|
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)
|
|
|
|
|
CPallini wrote: As far as I know, the server's send is not blocked by the client recv.
They're not, unless they're on the same thread... in which case everything is blocked by the recv().
|
|
|
|
|
Hi
I am getting a return code of 0 from a Create(IDD_DIALOG,dptr); after I created the dialog on the heap CMyDialog *dgtr = new CMyDialog, in the CWinApp and set it to the main windows m_pMainWnd = dgptr;
|
|
|
|
|
The question makes no sense. A modeless dialog is designed to be shown while its owner Window can still accept input and respond to messages. If you want a dialog as your main Window then use a modal type, or some appropriate CView class if using MFC.
|
|
|
|
|
|
Hello.
I am trying to hook winapi for 64 bit apps. I found this example: API Hooking with MS Detours[^]
And I tried to modify BeginRedirect to work with 64 bit programs but every time I inject, my target crashes.
Here's my new code.
#undef UNICODE
#include <windows.h>
#include <cstdio>
#define SIZE 10 //Number of bytes needed to redirect
typedef int (WINAPI *pMessageBoxW)(HWND, LPCWSTR, LPCWSTR, UINT);
int WINAPI MyMessageBoxW(HWND, LPCWSTR, LPCWSTR, UINT);
void BeginRedirect(LPVOID);
pMessageBoxW pOrigMBAddress = NULL;
BYTE oldBytes[SIZE] = {0}; BYTE JMP[SIZE] = {0}; DWORD oldProtect, myProtect = PAGE_EXECUTE_READWRITE; char debugBuffer[128];
INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
{
switch(Reason)
{
case DLL_PROCESS_ATTACH:
MessageBoxW(NULL, L"Attacheds", L"Hooked MBW", MB_ICONEXCLAMATION);
pOrigMBAddress = (pMessageBoxW) GetProcAddress(GetModuleHandle("user32.dll"), "MessageBoxW");
if(pOrigMBAddress != NULL)
BeginRedirect(MyMessageBoxW); break;
case DLL_PROCESS_DETACH:
memcpy(pOrigMBAddress, oldBytes, SIZE);
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
void BeginRedirect(LPVOID newFunction)
{
sprintf_s(debugBuffer, 128, "pOrigMBAddress: %x", pOrigMBAddress);
OutputDebugString(debugBuffer);
BYTE tempJMP[SIZE] = {0xE9, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0xC3}; memcpy(JMP, tempJMP, SIZE); DWORD JMPSize = ((DWORD)newFunction - (DWORD)pOrigMBAddress - 9); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, PAGE_EXECUTE_READWRITE, &oldProtect);
memcpy(oldBytes, pOrigMBAddress, SIZE); sprintf_s(debugBuffer, 128, "Old bytes: %x%x%x%x%x", oldBytes[0], oldBytes[1],
oldBytes[2], oldBytes[3], oldBytes[4], oldBytes[5]);
OutputDebugString(debugBuffer);
memcpy(&JMP[1], &JMPSize, 8); sprintf_s(debugBuffer, 128, "JMP: %x%x%x%x%x", JMP[0], JMP[1],
JMP[2], JMP[3], JMP[4], JMP[5]);
OutputDebugString(debugBuffer);
memcpy(pOrigMBAddress, JMP, SIZE); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, oldProtect, NULL); }
int WINAPI MyMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uiType)
{
VirtualProtect((LPVOID)pOrigMBAddress, SIZE, myProtect, NULL); memcpy(pOrigMBAddress, oldBytes, SIZE); MessageBoxW(NULL, L"This should pop up", L"Hooked MBW", MB_ICONEXCLAMATION);
int retValue = MessageBoxW(hWnd, lpText, lpCaption, uiType); memcpy(pOrigMBAddress, JMP, SIZE); VirtualProtect((LPVOID)pOrigMBAddress, SIZE, oldProtect, NULL); return retValue; }
Modified lines are 5, 42, 44, 51. Changes I made are underlined.
Could anyone tell me how to fix it?
|
|
|
|
|
Most likely person to help you is the one who wrote the article and the code. Please post your question in the forum at the end of the article.
|
|
|
|
|
Hello Folks,
Am new to MFC, actually am trying to use PageUp/PageDown keys to switch top/Bottom of the tree, but the problem is when trying am to click keys by default it selects an item & switches over from top-to-bottom/bottom-to-top. And I've also tried the solution
TreeItem = GetSelectedItem();
if (TreeItem)
{
SetItemState(TreeItem, 0, TVIS_SELECTED);
}
but it works when any one of the keys for the second time. so i request for a solution where i can directly switch over from top/button without any item being selected/focused
Thank You,
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
