|
Hi !
To set system-wide hook you should place a hook procedure in DLL.
Best regards,
-----------
Igor Soukhov (Brainbench/Tekmetrics ID:50759)
igor_soukhov@yahoo.com | ICQ:57404554 | http://siv.da.ru
|
|
|
|
|
I had this exact same problem. Here's the reason:
Whenever an app or DLL does something which triggers your hook, the system loads and maps a copy of your hook DLL into that process. Thus, the system has X copies of your DLL. Each DLL has SEPARATE data. Thus, the original DLL you load to run the hook is not aware of a variable being set in another instance of the DLL.
What you need to do is create a shared segment in your DLL, as follows (in the CPP file, not in any routine but out in the open):
#pragma data_seg(".shared")
HHOOK g_hHook = NULL ;
HWND g_hWndSelected = NULL ;
#pragma data_seg()
#pragma comment(linker, "/SECTION:.shared,RWS")
Any variable that gets set or used by the hook (except local variables, of course, since they are only temporary anyway) should be in this section so that ALL of the loaded DLL instances see that variable get the new value. For example, the hook handle above is used when calling CallNextHook(), since whichever instance of the DLL gets activated, it needs the handle to pass on. Similarly, if the activation code makes a note of the handle of a window being clicked by the mouse, then that window handle must be in the shared section (as the example above shows).
By doing the above, when your app that installed the hook goes to its original instance of the DLL and asks for the handle of the clicked window, your DLL can see the data even if another instance set it.
I hope that clears up the problem, it did for me 
|
|
|
|
|
현재 프로젝트 안에 include란 폴더가 있는데
그 안의 헤더 파일이 두개 포함되어 있습니다.
지금 현재 프로젝트 화일에 분명 참조를 했는데...
도 계속 헤더 화일을 인식못하거든요?
어떻게 해야 할지 모르겠어요.
방법이 없을까요?
급한데... 보시면 답변 좀 부탁드리겠습니다.
|
|
|
|
|
Please translate your question... I think there's no people who know Japaness so good =)
Best regards,
-----------
Igor Soukhov (Brainbench/Tekmetrics ID:50759)
igor_soukhov@yahoo.com | ICQ:57404554 | http://siv.da.ru
|
|
|
|
|
here goes:
---snip!
// abc
class Base
{
public:
// pure virtual function
virtual bool Load (UINT nID) = 0;
protected:
Base (UINT nID)
{
Load (nID);
}
};
class Concrete
{
public:
Concrete (UINT nID)
: Base (nID) {}
bool Load (UINT nID)
{
// do the operation
}
};
Concrete c (123); // here's the problem
---/snip
this looks okay to me, but the linker complains that it cannot find the definition of Base's Load() member. My reasoning is that it shouldn't need it- it's never used except when its overriden... but?
does this have something to do with using a pure virtual function in a ctor? thats my guess, but it would be good if someone could point me towards the standard.
i'm using VC++ 6 sp 4
thanks,
Nick
|
|
|
|
|
Well this isn't much help, but I just tried your code using Borland's 5.5 compiler and it works fine. I get the same error as you when using VC++ 6 sp5.
|
|
|
|
|
heh... thanks
should have given it a run-over with gcc- i usually use that to weed out problems with vc++
cheers
nb
|
|
|
|
|
> does this have something to do with using a pure virtual function in a ctor?
I imagine your right. I think that if you call a pure virtual member within an a class that declares it, you are telling the linker to find the member it points to (in the VTABLE). The linker chokes because you have not defined one (obviously since it's declared as a pure virtual).
BTW: Why the protected ctor? Since Base has a pure virtual in it, it will never be able to be instantiated anyway.
-Ben
"Its funny when you stop doing things not because they’re wrong, but because you might get caught." - Unknown
|
|
|
|
|
Do NOT call a (pure) virtual function in a constructor or destructor. This can result in undefined behavior.
Think about it, or grab a copy of 'Stroustrup'.
--------------------------------------------------
If my messages appear curt, I apologize.
I try to be brief to save your time as well as mine.
--------------------------------------------------
|
|
|
|
|
Thanks,
Now that I think about it... Base ctor called first, pure virtual function call would open the possibility for using unconstructed subclass data...
mmm
makes me worried that Borland C++ DID compile it! Thanks again to all of you ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
nick
|
|
|
|
|
I found this in the MSDN online help :
Another restriction is that if the constructor for an abstract class calls a pure virtual function, either directly or indirectly, the result is undefined.
http://msdn.microsoft.com/library/devprods/vs6/visualc/vclang/_pluslang_restrictions_on_using_abstract_classes.htm
Borland compiled without errors, but didn't run correctly. I added printf function calls to the constructors and destructors of both classes. When I ran the program, the printf functions didn't output anything. When I removed the call for "Load()" in the base class, all worked as it should. I guess you could say that MSVC++ works better since it doesn't allow to shoot yourself in the foot.
|
|
|
|
|
In my program I need to use some mathematical (unicode) symbols like sigma, square root, integral, and so on. For some reason only some of the unicode works while others not. For example, I have an array Names and a CCombobox m_combo, and a loop to add the strings in the array to the combo box.
static const CString Names[] ="a","=",0x221A,0x222B,0x2211,0x2212, 0x223B};
for(int i=0; i<7; i++)
m_combo.AddString(Names[i]);
The combo box correctly displayed "a", "=", square root (0x221A), integral (0x222b),sigma (0x2211), minus sign (0x2212), but it shows only a square box for 0x223b instead of showing the symbol. This only happens to many other unicode characters.
Why some symbols can be correctly displayed while others not? Also how can VC++ convert a wchar_t into a CString automatically?
bob
|
|
|
|
|
Ok, I'd be very grateful if you can help me out here...
In my main dialog window, I fire up a new one. I that new dialog I want to have a CListBox (with values in it of course). I have no problem using the CListBox.AddString(...) in my main dialog.
Whenever I try to add a line in the new dialog the program crashes... Why? How can I do this the right way? I suspect the answer is very simple, I just can't figure it out...
The error message is: Debug Assertion Failed.
Cheers,
Erik
|
|
|
|
|
Are you using the CListCtrl? If so remember that you must first have the columns present if you use a CHeaderCtrl. Once you have that you can use the following code
int iRowRet = m_LISTCONTRL.InsertItem(m_LISTCONTRL.GetItemCount(),strText);
m_LISTCONTROL.SetItemText(iRowRet,1,strText);
UpdateWindow();
|
|
|
|
|
No, im just using a CListBox, and AddString(...) to fill it with values.
This works just fine in my main dialog window. It chrashes (when using AddString(...) or any other CListBox member function) in a modal dialog initiated from my main window.
Hope you can help me now,
Erik
|
|
|
|
|
Where are you adding the strings to the dialog? in the OnInitDialog? elsewhere?
-Ben
"Its funny when you stop doing things not because they’re wrong, but because you might get caught." - Unknown
|
|
|
|
|
I've tried adding the strings from everywhere...
Constructor, OnInitDialog, though buttons... AddString to that CListBox crashes the program.
I suspect I have to initialize the dialog in some way?
Erik
|
|
|
|
|
Can you post some code or even the code that asserted would help,
Michael
|
|
|
|
|
ASSERT(::IsWindow(m_hWnd))
That's where it fails. Apparently my m_hWnd is NULL. How to fix this?
|
|
|
|
|
Trace into the MFC source and check where the assertion occurs. Any hints in the source code comments? Also check if the dialog's m_hWnd is NULL before you call AddString().
Are you trying to do something like this?
CMyDlg dlg;
dlg.m_wndList.AddString("asdf");
dlg.DoModal();
This will fail, because the dialog's window handle (and the list) hasn't actually been created yet.
--------------
"Fabricati Diem, Pvnk"
|
|
|
|
|
the assertion --> ASSERT(::IsWindow(m_hWnd))
So I guess my m_hWnd is NULL. How can I fix this?
Erik,
|
|
|
|
|
CMyDlg dlg;
dlg.DoModal();
And then, inside the dialog:
m_CListBoxVariable.AddString("Testing, testing..."); // Assertion error here!
|
|
|
|
|
This should work. And m_CListBoxVariable was added with ClassWizard? Maybe the DDX macros in DoDataExchange() have been corrupted somehow. Try removing the member and add it again.
--------------
"Fabricati Diem, Pvnk"
|
|
|
|
|
I tried removing, and adding it again. No luck.
I think the problem is somehow related to the fact that hWnd is NULL in my new dialog object. I have no clue however how to initialize hWnd.
Please, can't someone just try to make a dialog based app, and then fire up a new dialog from the main frame. And if you can assign values to variables in this new CDialog, please tell me how you did....
|
|
|
|
|
I created a small test project and it works OK. This is what I did:
1. Create a standard Dialog-based MFC app
2. Add a new dialog resource to the project (IDD_DIALOG1)
3. Put a listbox on the new dialog
4. Open ClassWizard and coose to create a new CDialog class for new dialog resource (CDialog1).
5. With ClassWizard, add a CListBox member for the list (m_wndList)
6. Add a button to the main dialog and add an OnClick handler like this:
#include "Dialog1.h"
...
void CMainDlg::OnButton1()
{
CDialog1 dlg;
dlg.DoModal();
}
7. Add a WM_INITDIALOG handler in CDialog1:
BOOL CDialog1::OnInitDialog()
{
CDialog::OnInitDialog();
m_wndList.AddString("String to add");
return TRUE;
}
Try this, and if you still get an assertion at CListBox::AddString(), something is very, very strange.
--------------
"Fabricati Diem, Pvnk"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
