|
You can do it for the entire system, but I don't know of any way to do it for just one app. You might check the BCGSoft forums, they might have a secret API.
|
|
|
|
|
Hans Dietrich wrote: You can do it for the entire system, but I don't know of any way to do it for
just one app
The single MFC Feature Pack application is ignoring my system settings so I thought there might be a way to force it to behave and pay attention to the system settings but so far, I've dug around in the BCGSoft/Microsoft source code for CMFCVisualManager and the label/caption drawing code simply uses the DC passed in so I guess I need to see where that DC comes from and see if it can be modified.
I'll dig around the BCGSoft site. I have to say, by the time I figure out how to use this Feature Pack stuff, they'll have moved on to something new again.
|
|
|
|
|
Post a question on the BCGSoft forums.
|
|
|
|
|
Didn't have the secret API but something in the BCGSoft FAQ made a neuron fire.
Thanks for the assistance.
|
|
|
|
|
Hi All,
I have to hit a WebSocket server and have to maintain the connection alive.
Please share some article about implementing a WebSocket Client application in C.
Thanks All.
Do your Duty and Don't expect the Result
|
|
|
|
|
For a socket client in Windows you basically need to call the following functions in order -
WSAStartup[^] - Initialize winsock.
socket[^] - Create the socket specifying the required protocol like TCP, UDP etc.
connect[^] - Connect the previously created socket to the specified server.
After this step the connection is ready.
To communicate with the server you can use the following functions -
send[^]/sendto[^] - Send a stream of bytes to the server.
recv[^]/recvfrom[^] - Receive a stream of bytes from the server.
To tear down the connection the following functions must be called -
closesocket[^] - Disconnect
WSACleanup[^] - Cleanup winsock.
|
|
|
|
|
|
The WebSocket protocol works on top of a normal TCP socket connection, so you must understand Winsock first before you can start implementing WebSockets.
|
|
|
|
|
Thanks for the reponses.. guess i'm not clear with my question..
I'm clear about the WinSocket APIs.. just need to know the WebSocket Handshake details..
I got the below header from Wikipedia & i want to know what are all the things are variable values in this header?
GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http:
Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
^n:ds[4U
As far as i know the /demo in first line, Host & Origin will change.. but exactly what will be the values?
Will the values of Key1, Key2 & the last 8 byte values also change?
I have to hit the server which has the format as ws://xxx.xxx.xxx.xxx:8181/websock
Also is it possible to send any extra information in the above handshake header? if so what will be its format?
Thanks Again.
Do your Duty and Don't expect the Result
|
|
|
|
|
|
Can websockets be implemented using CURL ?
Also it seems that once the client receives "HTTP/1.1 101 WebSocket Protocol Handshake" it should just wait on recv or recvfrom. Am I correct ? If so, who closes the socket connection once all communication is done? The server or the client ?
Thanks
|
|
|
|
|
If I have an LPCTSTR lpszString , how can I check if lpszString is empty ? Either , if is NULL , is correct lpszString == NULL ?
Thank you .
|
|
|
|
|
The best way is to make two checks:
if ((lpszString == NULL) || (lpszString[0] == 0))
{
[lpszString is NULL or empty ]
}
|
|
|
|
|
Thank you , does function .
|
|
|
|
|
if(!lpszString || !*lpszString){
}
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
In C and C++, strings are null-terminated. As such the last character will always be a NUL character (ASCII 0).
Consequently, any string (char*, const char*, LPTSTR, LPCTSTR etc.) can be checked for empty using:
LPCTSTR sz;
if (!sz[0]) { }
However, commonly you also need to check if the string pointer is null - this means that the pointer does not refer to a string at all, rather than that the string is empty:
LPCTSTR sz;
if (!sz) { }
Commonly, the two must be used together to check for empty or null:
if (!sz || !sz[0]) { }
|
|
|
|
|
Thank you all , I learned something here !
modified 2-Jan-19 3:54am.
|
|
|
|
|
You're welcome.
I should have mentioned that in the last case, order is important:
if (!sz || !sz[0]) { }
If sz is null, then !sz will evaluate true and the second won't be evaluated.
Otherwise, sz[0] will cause a memory access violation if evaluated on a null pointer.
(I also reordered the comment to reflect this).
|
|
|
|
|
Hi,
I'm trying to work through the example code in the MSDN DirectSound Programming Guide to enumerate sound devices.
When I run my app, the ComboBox which should list the available sound devices is for some reason empty.
Below is the Callback Procedure I've used for the Direct Sound device enumeration.
BOOL CALLBACK DSEnumProc(LPGUID lpGUID, LPCSTR lpszDescription, LPCSTR lpszDriverName, LPVOID lpContext)
{
HWND hCombo = (HWND)lpContext;
LPGUID lpTemp = NULL;
if(lpGUID != NULL)
{
if((lpTemp = (LPGUID)malloc(sizeof(GUID))) == NULL)
return TRUE;
memcpy(lpTemp, lpGUID, sizeof(GUID));
}
ComboBox_AddString(hCombo, lpszDescription);
ComboBox_SetItemData(hCombo, ComboBox_FindString(hCombo, 0, lpszDescription), lpTemp);
free(lpTemp);
return TRUE;
}
FYI Inspecting lpGUID during debugging reveals that the first time the if(lpGUID != NULL) is reached, it's value is 0 so the statement evaluates to FALSE, and lpszDescription points to the 'P' of "Primary Sound Driver". The call to ComboBox_AddString processes ok without returning CB_ERR or CB_ERRSPACE. The process repeats for the other available devices, but once it's finished the ComboBox remains empty!?
Below is my Callback procedure for the dialog containing the ComboBox. I've added a static text to display the total number of entries as a check, but this shows "Num Entries: 0" when I run the app. What am I missing here?
BOOL CALLBACK DLG_AudioDeviceSelectionProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
HWND hCombo, hEntryCountText;
int iCount;
TCHAR szBuffer[32];
switch(message)
{
case WM_INITDIALOG:
hCombo = GetDlgItem(hDlg, IDC_COMBO);
if(DirectSoundEnumerate((LPDSENUMCALLBACK)DSEnumProc,(VOID*)&hCombo) != DS_OK)
{
EndDialog(hDlg, TRUE);
return TRUE;
}
iCount = ComboBox_GetCount(hCombo);
hEntryCountText = GetDlgItem(hDlg, IDC_ENTRY_COUNT);
wsprintf(szBuffer, TEXT("Num Entries: %i"), iCount);
SetWindowText(hEntryCountText, szBuffer);
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDCANCEL:
case IDOK:
EndDialog(hDlg, 0);
return TRUE;
}
break;
}
return FALSE;
}
I'm using MS VC++ 2010.
I've worked through Petzold but I'm still essentially a Win API noob.
modified on Monday, April 11, 2011 12:57 AM
|
|
|
|
|
First of all, there is no break; after the case WM_INITDIALOG: block.
If this doesn't fix the problem, then get count of the combo box after each AddString() - put a breakpoint on it to make sure it's incremented.
If you still have problem, post here your code where you call AddString().
|
|
|
|
|
Thank you for your response Hans.
I added the break; after the case WM_INITDIALOG: block. Thank you, this was an oversight. Unfortunately it has not fixed the problem.
I've now added a static int called iCount to the callback procedure where I call ComboBox_AddString(). I've used ComboBox_GetCount() to update iCount.
I've also added some error handling to the ComboBox_AddString() call.
When I put in a breakpoint here and debug, I see that iCount remains at 0 each time the code passes through.
Below is my revised code.
BOOL CALLBACK DSEnumProc(LPGUID lpGUID, LPCSTR lpszDescription, LPCSTR lpszDriverName, LPVOID lpContext)
{
HWND hCombo = (HWND)lpContext;
LPGUID lpTemp = NULL;
static int iCount;
if(lpGUID != NULL)
{
if((lpTemp = (LPGUID)malloc(sizeof(GUID))) == NULL)
return TRUE;
memcpy(lpTemp, lpGUID, sizeof(GUID));
}
if(ComboBox_AddString(hCombo, lpszDescription) == CB_ERR | CB_ERRSPACE)
{
MessageBox(hCombo, TEXT("Error Adding String To ComboBox"), TEXT("Error!"), MB_OK);
}
iCount = ComboBox_GetCount(hCombo);
ComboBox_SetItemData(hCombo, ComboBox_FindString(hCombo, 0, lpszDescription), lpTemp);
free(lpTemp);
return TRUE;
}
Is it something to do with the way I'm trying to pass the ComboBox handle to the DSEnumProc procedure when I initialize the dialog? I notice that the value of hCombo in the code below is different from the value in the code above when I debug.
hCombo = GetDlgItem(hDlg, IDC_COMBO);
if(DirectSoundEnumerate((LPDSENUMCALLBACK)DSEnumProc,(VOID*)&hCombo) != DS_OK)
{
EndDialog(hDlg, TRUE);
return TRUE;
}
Thank you again for your help
Paul
|
|
|
|
|
When you say (VOID*)&hCombo, what you're doing is passing the address of hCombo. But in your callback, you write
HWND hCombo = (HWND)lpContext;
So, you're doing one thing, but telling the compiler something else. Do you see what I mean? I could go further if you want.
|
|
|
|
|
Yes, I used (Void*)&hCombo and HWND hCombo = (HWND)lpContext as this was how it was written in the MSDN explanatory code snippets.
I think I understand what you mean though.
lpContext is a pointer which contains the address of hCombo when I pass it, so I need to dereference lpContext when I'm initializing the local hCombo in the callback, right?
I've tried HWND hCombo = (HWND)*lpContext; but the IDE says "Error: expression must be a pointer to a complete object type". Is it incorrect to declare, dereference, cast and initialize all in the one statement?
Thank you again.
Paul
|
|
|
|
|
Actually, it would be simpler to just keep your callback code the same, and write (Void*)hCombo. A HWND will fit into a pointer-size variable, which is what lpContext is. So keep the callback like you had it before: HWND hCombo = (HWND)lpContext;
|
|
|
|
|
Thanks Hans. It works. 
I think I took MSDN's description of DirectSoundEnumerate too literally.
It says:
HRESULT DirectSoundEnumerate(
LPDSENUMCALLBACK lpDSEnumCallback,
LPVOID lpContext
)
Parameters
lpDSEnumCallback
Address of the DSEnumCallback function that will be called for each device installed in the system.
lpContext
Address of the user-defined context passed to the enumeration callback function every time that function is called.
So I assumed lpContext had to be a pointer, but since it's just being passed straight on to the callback function anyway, I guess it doesn't have to be.
Your help is greatly appreciated.
Best regards
Paul
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
