|
i coded an application using hook events but when I trace events in debug mode, only the events sent by this application are catched!! The application doesn't catch others events from windows!!
My hook functions are in a dll, I don't understand!!
|
|
|
|
|
Hi
Anyone can tell me how i can grayed a Menu.
The problem is i don't have the ID
How can i do that.
Thanks
|
|
|
|
|
I look for a code sample using SetWineventHook() and SetWindowsEvent(). I've already samples from MSDN... Thanks!
|
|
|
|
|
hi,
Win2k protects the system files by detecting changes and replacing changed files from a cache. I see that there are ways to disable this feature. But is there a way to just disable this feature for one single file insted of all system files ?
thanks
karthik
ps: reason being inetinfo dlls stack size is set to 40000 , but some of my dlls need a stack size of 100000 ,so I want to change the stack size of this dll alone. win2k will not allow me to use this modified dll.
|
|
|
|
|
ummm ... i cant help wondering why such a huge stack is necessary ... is there a particular reason you don't want to allocate some memory or a memory mapped file?
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
In this software business there are times when you cant control what is already there, there are portions of code written years ago and no one knows a thing about it. you need to make things work first and then go do your research.
" This is what i call a "smart as*" syndrome, some one asks a question and the return is a wise as* question!"
|
|
|
|
|
hmmmmm
i know what u mean ... no offence taken ... i just get real nervous recompiling a system file as it will change with the next release or any other software that gets installed and uses the same file ... i would rather try to make the existing dll use a different stack or do the research and figure it out now ... it will prolly take no longer than farting around with the system files
imho
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
If you plan to distribute this, it would be against your EULA. You're not allowed to modify system DLL's.
Further, I can't help but think there has to be a different solution to the problem.
|
|
|
|
|
Is this simplified picture of message pumping correct?
1. The user clicks a mouse button.
2. The mouse driver puts an item into the system input queue.
3. A system thread, which handles user input, retrieves this item and, using
coordinates recorded by the driver, determines to which window this message
should be posted. Mouse messages are always sent to the window under the
cursor (unless another window has captured mouse input).
Given the window handle the system detemines the thread to which this window
belongs and posts WM_LBUTTONDOWN and WM_LBUTTONUP messages to the
message queue of this thread. Note, the message is posted to only one message
queue since the system knowns to which thread the window belongs.
4. The application object, derived from CWinApp, will pickup the message from its thread message queue. Then route this message to the appropriate controls/windows.
5. Button window procedure receives WM_LBUTTONUP message and do the following:
(i) update the display of the button (depressed state and then the release state.)
//QUESTION: SendMessage( ) OR PostMessage( )??
(ii) sends WM_COMMAND/BN_CLICKED notification to "the parent window" or a "particular" control.
(iii) posts WM_COMMAND/BN_CLICKED notification to the application/thread message queue.
5. Message map can be "expanded" to a subroutine that searches the message map upon reciept of a message/notification, then route the message to "appropriate" message handler in response a mapped message.
(This brings up the issue of message routing. ie. Things like searching the view class maps, then the document class, then the frame windows, then the app...)
//Example of a handler:
void CMyDlg::OnButton1()
{
// TODO: Add your control notification handler code here
}
Thanks
|
|
|
|
|
Can anyone explain why this template does not work with signed types?
template<class t=""> T IsolateBits(T x, int bit1, int bit2)
{
T v=0;
for(int b=0; b < bit2-bit1; b++)
{
v = (v << 1) | 0x01;
}
for(int b2=0; b2 < bit1; b2++)
{
v = (v << 1);
}
return (x & v);
}
Basically, the template is supposed to change all bits out of range bit1-bit2 to 0's...and it works perfectly unless the class inputed is signed. Any suggestions on how to fix this?
--Jesse
|
|
|
|
|
Your code won't work as a C function either.....I believe the high bit in signed integers is "latched" and will be rotated into the next bit position following a rotation.
|
|
|
|
|
How is this done? Do you have a link to an example?
|
|
|
|
|
i assume you mean 'how do i put a combo box on a toolbar' and that is easy ... just make it a rebar (CReBarCtrl) and plonk it on one of the bands ... s'easy really ... app wizard can generate it for you and all you have to do is edit the dialog template to add the combo box
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Actually, I wanted to put it onto a CToolBar. I finally found an example in the MSDN samples. Subclassed CToolBar and added a CComboBox to it. Created a new toolbar resource with just one button, and then when creating the CToolBar I replaced that button with the combo box.
|
|
|
|
|
I have derived a new static control where one can the font of the text contained in the static control. However if the font size is set very big then half the text is obscured. Is there a way I can find out the new dimensions of the text and as such enlarge the static control dynamically.
|
|
|
|
|
use GetTextMetrics() and adjust the size of your static control using MoveWindow()
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Does anybody know how to implement a ruler control such as found when one is editing or creating a dialog in MSDEV, or know of a sample application with source code.
|
|
|
|
|
i would create a toolbar and plonk a static control on it that you resize as the toolbar resizes ... in the static you can set the mapping mode to whatever you want and draw the markings for the measurements
could be other ways but hey...
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
static control on it that you resize as the toolbar resizes
And any help you can offer on the toolbar resizes? Post your code lines here please.
|
|
|
|
|
hmmmm
check out CDialogBar ... it becomes part of the main window and doesnt float around which may be better for a ruler ... plonk the static control in and catch size change messages in the frame window and change the static control size from there
it might fit ur needs more
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
check out CDialogBar ... it becomes part of the main window and doesnt float around
Are you sure the dialog bars don't float around, or even dock around?
PS. Learn a little more before you post answers, pleeease.
|
|
|
|
|
Wordpad!
Wordpad offers just such a ruler, and it's source comes with VC++.
|
|
|
|
|
|
The MSDN tells me that the thread process for CreateThread must be a function of the following form: DWORD WINAPI ThreadProc( LPVOID lpParameter ).
When I implement this as a simple global procedure I have no problems but if I make the function a member of a class (SerialComms for example) C++ refuses to accept it as a parameter and complains about an illegal cast. Nothing I have tried could coax it into recasting to an acceptable value. The pointer it wants is,
DWORD (WINAPI *ThreadFunction )(void *)
but when I point to a member function it actually sees,
DWORD (WINAPI SerialComms::*ThreadFunction )(void *)
As far as I am concerned these are identical except for the namespace. The linkage is identical also so C++ should only warn me and not kill the compile. I have solved this problem as follows:
union
{
DWORD (WINAPI SerialComms::*x )(void *);
DWORD (WINAPI *y )(void *);
} z;
// Get the read thread procedure address. This is a weird "cast" method.
z.x = ThreadFunction;
m_readThread = CreateThread( NULL, 0, z.y, 0, 0, &m_threadId );
It works but I am not real happy with a "smartass" solution like this.
Question? How can I recast a member function so I don't have to trick C++ into a funny union "cast"? (For C++ purists, my apologies. I'm an old, unreformed assembler and C hacker!)
|
|
|
|
|
Generally, you would declare a member threadproc as static . This placates the C interface, which has no knowledge of member fns. It sort of promotes the fn from out of the classes vtable space into the global arena.
The only sticky point you'll have is that now that the fn is static it can't access the non-static members of the class (static fns have no this pointer). To get around this (no pun) limitation, pass the this pointer as the lpParameter.
later... Actually, your fix is kind of neat - - does it get around the member access problem?
|
|
|
|