|
sorrie I am new to C++ programming and I want to enquire which part of the code am I suppose to insert the procedures I want to call whenever this 30 ms interval is up?
|
|
|
|
|
Standard timers are not very accurate, since they depend on windows messages. If you have a lot of messages in your queue, then timer requests can be delayed.
You're better off using the multimedia timers, which have a much higher resolution than normal timers and are waitable (using WaitFor(Single/Multiple)Object(s)).
|
|
|
|
|
Does someone know how to change the color of a non owner-draw button?
|
|
|
|
|
I don't believe it's possible. I think you have to make it owner draw to change it.
I struggled with this problem myself, and ended up using statics and the WM_CTLCOLOR message and detecting WM_LBUTTONDOWN instead.
|
|
|
|
|
Does someone know how to change the color of a push button, who doesn't have the owner draw style?
Please help me.
|
|
|
|
|
Have you tried looking at the CColorButton class that is posted on here somewhere (just search for the class name). I am using it, acts perfectly except for in one location. The only drawback is having the owner draw property set on the button.
|
|
|
|
|
hi I need to modify the below Spy sample program but dont know how to modify it .Can anyone point out to me what is there to be changed in the Spy sample program because I dont know how to. I need to detect when any running active application refreshes its screen as a result of input from keyboard and mouse and by the way is wm_paint the message I should monitor for my program? I am really desperate because I am very new to c++ programming and I really hope you can help me . Thanks for replying.
/*****************************************************************************\
* hook.c - Windows message spy application dll
*
* Functions:
*
* DllMain()
* FindSpyWindow()
* HookProc()
* SpyGetMsgProc()
* SpyCallWndProc()
* DbgPrintf()
*
* Comments:
*
\*****************************************************************************/
#include <windows.h>
#include "..\hook.h"
PRIVATE HWND ghwndSpyHook = NULL; // the handle back to the spy executable
PRIVATE SPYMSGDATA gsmd;
PRIVATE COPYDATASTRUCT gcds = { 0, sizeof(SPYMSGDATA), &gsmd };
PRIVATE VOID FindSpyWindow(VOID);
#ifdef DBG
VOID DbgPrintf(LPTSTR fmt, ...);
#endif
/*****************************************************************************\
* DllMain (hModule,cbHeap,lpchCmdLine)
*
* Called when the libary is loaded
*
* Arguments:
* PVOID hModule - Module handle for the libary.
* ULONG ulReason - DLL purpose
* PCONTEXT pctx - not used
*
* Returns:
* TRUE - Everything is ok
* FALSE- Error.
\*****************************************************************************/
BOOL
APIENTRY DllMain(
PVOID hModule,
ULONG ulReason,
PCONTEXT pctx
)
{
UNREFERENCED_PARAMETER(hModule);
UNREFERENCED_PARAMETER(pctx);
//
// This function is called for every instance of the DLL. We must find
// and store the handle to the spy window every time an instance of the
// DLL is instantiated.
//
if ( ulReason == DLL_PROCESS_ATTACH ) {
FindSpyWindow();
}
return TRUE;
}
/*****************************************************************************\
* FindSpyWindow
*
* Finds the spy window and store a local copy in this instances data.
* This must be called everytime that a new instance of the DLL is
* created.
*
* Arguments:
* none
*
* Returns:
* VOID
\*****************************************************************************/
PRIVATE VOID
FindSpyWindow(
VOID
)
{
ghwndSpyHook = FindWindow(HOOKWINDOWCLASS, HOOKWINDOWNAME);
}
/*****************************************************************************\
* HookProc( hWnd, uiMessage, wParam, lParam )
*
* The hook proc for the windows hook being spied on
*
* Arguments:
* HWND hWnd - window handle for the parent window
* UINT uiMessage - message number
* WPARAM wParam - message-dependent
* LPARAM lParam - message-dependent
*
* Returns:
* 0 if processed, nonzero if ignored
\*****************************************************************************/
BOOL WINAPI
HookProc(
HWND hwnd,
UINT uiMessage,
WPARAM wParam,
LPARAM lParam
)
{
HWND hwndSpyingOn;
HWND hwndSpyApp;
if (ghwndSpyHook == NULL || !IsWindow(ghwndSpyHook))
{
//
// Spy has terminated. Find the new window.
//
FindSpyWindow();
}
if (ghwndSpyHook != NULL && hwnd != ghwndSpyHook)
{
hwndSpyingOn = (HWND)GetWindowLong(ghwndSpyHook, 0);
hwndSpyApp = (HWND)GetWindowLong(ghwndSpyHook, sizeof(HWND));
//DbgPrintf("H ghwndSpyHook:%8.8x", ghwndSpyHook);
//DbgPrintf("H hwndSpyingOn:%8.8x", hwndSpyingOn);
//DbgPrintf("H hwndSpyApp:%8.8x", hwndSpyApp);
//
// Send the message on asynchronously for Spy to deal with if
// it is the appropriate hwndSpyingOn window to spy on.
//
if (hwndSpyingOn == hwnd
|| (hwndSpyingOn == HWND_ALL && hwnd != hwndSpyApp
&& !IsChild(hwndSpyApp, hwnd)))
{
gsmd.wParam = wParam;
gsmd.lParam = lParam;
gcds.dwData = uiMessage;
//DbgPrintf("H Sending Message hwnd:%8.8x msg:%d", hwnd, uiMessage);
SendMessage(ghwndSpyHook, WM_COPYDATA, (WPARAM)hwnd, (LPARAM)&gcds);
//DbgPrintf("H Sent Message hwnd:%8.8x msg:%d", hwnd, uiMessage);
//DbgPrintf("");
return TRUE;
}
//DbgPrintf("");
}
return FALSE;
}
/*****************************************************************************\
* SpyGetMsgProc
*
* The Get Message hook function.
*
\*****************************************************************************/
LRESULT CALLBACK
SpyGetMsgProc(
INT hc,
WPARAM wParam,
LPARAM lParam
)
{
PMSG pmsg;
pmsg = (PMSG)lParam;
if (hc >= 0 && pmsg && pmsg->hwnd)
{
return HookProc(pmsg->hwnd, pmsg->message, pmsg->wParam, pmsg->lParam);
}
//
// Note that CallNextHookEx ignores the first parameter (hhook) so
// it is acceptable (barely) to pass in a NULL.
//
return CallNextHookEx(NULL, hc, wParam, lParam);
}
/*****************************************************************************\
* SpyCallWndProc
*
* The Call Window Proc (Send Message) hook function.
*
\*****************************************************************************/
LRESULT CALLBACK
SpyCallWndProc(
INT hc,
WPARAM wParam,
LPARAM lParam
)
{
PCWPSTRUCT pcwps;
pcwps = (PCWPSTRUCT)lParam;
if (hc >= 0 && pcwps && pcwps->hwnd)
{
return HookProc(pcwps->hwnd, pcwps->message, pcwps->wParam, pcwps->lParam);
}
//
// Note that CallNextHookEx ignores the first parameter (hhook) so
// it is acceptable (barely) to pass in a NULL.
//
return CallNextHookEx(NULL, hc, wParam, lParam);
}
#ifdef DBG
/****************************************************************************
* DBGprintf
*
* This debugging function prints out a string to the debug output.
* An optional set of substitutional parameters can be specified,
* and the final output will be the processed result of these combined
* with the format string, just like printf. A newline is always
* output after every call to this function.
*
* Arguments:
* LPTSTR fmt - Format string (printf style).
* ... - Variable number of arguments.
* Returns:
* VOID
\****************************************************************************/
VOID DbgPrintf(
LPTSTR fmt,
...
)
{
va_list marker;
TCHAR szBuf[256];
va_start(marker, fmt);
wvsprintf(szBuf, fmt, marker);
va_end(marker);
OutputDebugString(szBuf);
OutputDebugString(TEXT("\r\n"));
}
#endif
|
|
|
|
|
I have following problem:
I Use the Multicolumn ComboBox from Xiao Wu Guang to display some data from a database
(extract data from a table and insert it into the box)
but sometimes happen that two values are the same except the Case
for example
"hello" and "Hello"
in the Drop Down List i see both rows
but if i choose "Hello" the programm automaticle assume i chose "hello" (i think because
"hello" <= "Hello")
please can somebody tell me how i can make a case sensetive seletion???
tnx
|
|
|
|
|
hi,
i have for example a 'vector <object*>' and i have allocated memory for the 'object*' with 'new'.
now i use the clear()-method to clear the vector. have i to use 'delete' before to destroy the 'object*' ?
thx
|
|
|
|
|
Yes. clear() only destroys the contents of the vector, which in this case is just pointers. Destroying the pointer does not destroy the object.
|
|
|
|
|
Hello,
I use Visual C++ and I work with network sockets
(MFC's CAsyncSocket and winapi socket functions).
My application need some data to be sent in
separate TCP packets. In other words I must be
sure that some data are sending immediately and
want to avoid a situation when this data will wait
for the next data to join with them in a single
packet. How can I achieve this? I tried to use
both CAsyncSock::SetSockOpt() method and direct
winapi's setsockopt() call to set TCP_NODELAY
option, but they DON'T WORK, so I see in network
packets analyzer. Any suggestions will be very
appreciated. Thanks in advance.
|
|
|
|
|
As I'm not aware of the overall purpose of your application it's a little hard to be more specific, but here are a few thoughts.
If you want to send single packets you'll have to use UDP not TCP. There is no way to *guarantee* that TCP/IP packets won't be aggregated, either on your machine, or at some other point along the wire. UDP of course doesn't offer guaranteed delivery so you'll have to engineer that functionality yourself.
Here's a snippet from Warren Young's Winsock Programmers FAQ that you might find helpful:
The whole document is found here
>.3.17 - When should I turn off the Nagle algorithm?
Generally, almost never.
Inexperienced Winsockers usually try disabling the Nagle algorithm when they are trying to impose some kind of packet scheme on a TCP data stream. That is, they want to be able to send, say, two packets, one 40 bytes and the other 60, and have the receiver get a 40-byte packet followed by a separate 60-byte packet. (With the Nagle algorithm enabled, TCP will often coalesce these two packets into a single 100 byte packet.) Unfortunately, this is futile, for the following reasons:
Even if the sender manages to send its packets individually, the receiving TCP/IP stack may still coalesce the received packets into a single packet. This can happen any time the sender can send data faster than the receiver can deal with it.
Winsock Layered Service Providers (LSPs) may coalesce or fragment stream data, especially LSPs that modify the data as it passes.
Turning off the Nagle algorithm in a client program will not affect the way that the server sends packets, and vice versa.
Routers and other intermediaries on the network can fragment packets, and there is no guarantee of "proper" reassembly with stream protocols.
If packet arrives that is larger than the available space in the stack's buffers, it may fragment a packet, queuing up as many bytes as it has buffer space for and discarding the rest. (The remote peer will resend the remaining data later.)
Winsock is not required to give you all the data it has queued on a socket even if your recv() call gave Winsock enough buffer space. It may require several calls to get all the data queued on a socket.
Aside from these problems, disabling the Nagle algorithm almost always causes a program's throughput to degrade. The only time you should disable the algorithm is when some other consideration, such as packet timing, is more important than throughput.
Often, programs that deal with real-time user input will disable the Nagle algorithm to achieve the snappiest possible response, at the expense of network bandwidth. Two examples are X Windows servers and multiplayer network games. In these cases, it is more important that there be as little delay between packets as possible than it is to conserve network bandwidth.
>>
|
|
|
|
|
Interestingly enough, I'm looking at the same problem. I'm working with real-time control systems. The real-time OS is sending data to a monitoring station, which must be updated as soon as possible, and packet sizes can often be as little as 20 bytes. Thankfully data doesn't always change constantly, so network bandwidth isn't the issue, but rather notifying the client as soon as possible is.
|
|
|
|
|
Just to let u know..
There seems to be a problem with SEH raising exceptions in release mode (using VC++ 6 SP4)
In release mode, a divide by zero does not raise any exceptions but it does in debug mode. However, if I uncomment the cout line after the divide (in release mode), an exception would be raised.
If the program was compile with the /EHa option (asynchronous exception), then an exception is always raised.
I didn't do an disassembly but it's probably due to the compiler not generating the divide code since it's not used.
[source]
#include < windows.h >
#include < iostream >
#include < stdexcept >
using namespace std;
void SEH_Translator( unsigned int u, EXCEPTION_POINTERS* pExp )
{
throw exception("SEH exception");
}
void main()
{
try
{
_set_se_translator(SEH_Translator);
int x,y;
x = 9999;
y = 0;
int z = x/y; // cause a divide by zero exception
// cout << z << endl; // uncommenting this throws an exception in release mode
}
catch(...)
{
cout << "Exception caught" << endl;
}
}
[/source]
|
|
|
|
|
As you said, compiler optimization in release mode may have removed the divide-by-zero.
|
|
|
|
|
The reason that an exception doesn't occur in this code in release is because the optimizer will throw all the code away as it does nothing... As soon as you include the cout z has to around so a value can be displayed hence the exception - In a debug build no code is optimized hence you get the behaviour expected.
|
|
|
|
|
I am trying to send a message from a worker thread to a specific class/window in the main dialog. How do I find the HWND of this dialog in order to call PostMessage/SendMessage with the appropriate parameters?
|
|
|
|
|
Your question is similar to the question:
"I am trying to send a letter from my work location to someone downtown. How do I find the address of that person in order to put an address on the letter?"
We cannot help without either guessing or asking you a lot of questions and if you answer all the questions then you will probably have answered your question yourself.
|
|
|
|
|
Ok, whatever the hell that is supposed to mean.
|
|
|
|
|
Roger,
I'm pretty sure that FindWindow will return a valid hwnd for any window currently in the zorder. You need only pass the window title to the function to return the hwnd.
Check the docs or search msdn for FindWindow.
Good luck,
Frank
|
|
|
|
|
The windows I am mostly working with are child windows with no title. I noticed the FindWindow function takes one of two parameters, class name or window name. What do you do if you do not have a title for the window? How do you find the class name?
|
|
|
|
|
You can use Spy++ to retrieve the class name. It should have been installed with VC++ 6. Spy will allow you to select a window to "spy" and then it will give you all the relevant information about that window.
You can also use spy to "spy"  on window messages. Nice utility.
Frank
|
|
|
|
|
Thank ya much, never used Spy++, could be a neat adventure.
|
|
|
|
|
When using Spy++ I can find the correct dialog, but all of the dialogs that are open have the same classname, #32770 (that is the classname for ALL dialogs on the application). How do I differentiate between thm when using FindWindow and using the class name parameter?
|
|
|
|
|
Hello,
I think you are on the wrong track with FindWindow.
Why don't you just store the pointers to the ChildWindows in a nice collection class (e.g. in the parent or in your application object) when they are created, and remove them when you destroy them. You can even make them searchable on a particular key (hey, you are the boss, so you decide what the key should be).
Then don't use (p_whatever)->SendMessage(...); // p_whatever is a pointer to a CWnd
but use
HWND theWindow = (p_whatever)->GetSafeHwnd();
if (theWindow != NULL)
{
SendMessage(theWindow, ...);
}
or better use PostMessage.
better still when sending messages to other threads use
PostThreadMessage.
Don't over-complicate things...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
