Hi. you might check the MSDN documentation for ReadDirectoryChangesW and co. APIs. There are also some nice articles on CodeProject discussing this: - CDirectoryChangeWatcher [^] - Spying a file system[^]

Kind Regards, Robert Kuster _________________ www.it.rkuster.com

Hi Fredrick, I think there is no direct way. Though you could call something like this

CEdit myEdit;
CString csContent = _T("");
myEdit.GetWindowText( csContent );
myEdit.SetSel( csContent.GetLength(),
csContent.GetLength(),
TRUE /* scroll to the selected text */ );

.. every time you add new text to your edit control.

Kind Regards, Robert Kuster _________________ www.it.rkuster.com

Hi. > I can't see any way to get from a processID I'm > interested in to its main window handle There is no direct way, but you could use a combination of EnumWindows and GetWindowThreadProcessId calls. There is a MSDN article discussing this issue: Get the Main Window, Get EXE Name[^] > .. or from an application Hwnd to its processID This one is trivial through the GetWindowThreadProcessId API.

Kind Regards, Robert Kuster _________________ www.it.rkuster.com

> I am trying to call ShellExecute or WinExec > in my Win NT service application. > ... both of them dont work. ShellExecute and WinExec both work fine and your process gets created. You just don't see the window of your application because it's on a wrong desktop. To modify this tell your service to be interactive:     Administrative Tools > Component Services > Services (local) >     > double click your service > Tab: "Log On" > Check: "Allow service to interact with desktop" Although you will see the application now, it will still run under the local System account (often unwanted). To modify this behaviour use CreateProcessAsUser rather than ShellExecute or WinExec:

STARTUPINFO si;
PROCESS_INFORMATION pi;

si.cb = sizeof(STARTUPINFO);
si.lpReserved = NULL;
si.lpTitle = NULL;
si.lpDesktop = "WinSta0\\Default";
si.dwX = si.dwY = si.dwXSize = si.dwYSize = 0L;
si.dwFlags = 0;
si.wShowWindow = SW_SHOW;
si.lpReserved2 = NULL;
si.cbReserved2 = 0;

CreateProcessAsUser(hToken,NULL, szMyApp, NULL, NULL, FALSE,
0, NULL, NULL, &si, &pi);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);

How to get the security token of a logged-on user? There are several ways, but I usually simply *steal* it from explorer.exe (via OpenProcessToken). As an example check the nRunAsLoggedOnUser function here[^] (=some handy service helper routines from CISCO). RK :)

> Please use the /MD switch for _AFXDLL builds，where to set this flag? In VC6 go to: Project -> Settings (or Alt+F7) -> C/C++ Tab -> Project Options RK

First, check this: Typename, Disabling Keys in Windows XP with TrapKeys[^] > ...the main purpose is to lockout children from windows system I'm not quite sure if this is an option, but in WinXP you could simply add a new account and start your program instead of explorer.exe. Go to: Start -> Run -> gpedit.msc -> Administrative Templates -> System -> Custom User Interface This way most of the Windows hotkeys will go away for free. But two of them will stay: Ctrl-Shift-Esc and Ctrl-Alt-Del (both are intercepted by Winlogon). To get rid of them you could either disable Task Manager (gpedit.msc -> Administrative Templates -> System -> Ctrl+Alt+Del Options). If you are happy with the notification message that pops up when pressing those hotkeys thereafter, then you are all done. If not, or if you simply need complete control over those hotkeys, you have to write a replacement for msGina.dll (search for GINASTUB in MSDN as a starter example; unfortunately the sources were thrown out of MSND .NET, so you'll have to stick with the Visual Studio 6.0 version). In your custom GINA: 1) Gobble WlxStartApplication in order to disable Ctrl-Shift-Esc. 2) To handle Ctrl-Alt-Del either gobble WlxLoggedOnSAS (you get an ugly flicker) or call

DWORD dwOld;
pWinlogonFunctions->WlxSetOption( hWlx, WLX_OPTION_USE_CTRL_ALT_DEL, 0, &dwOld );

(now the screen-saver won't be started anymore). Isn't it always true: You get something but in the same moment you lose something else. :) RK

Last Christmas, I gave you my :love: But the very next day ... One of my favorite songs. :-O I wish you all the best and a lot of success in the upcoming year. Robert K

Check this: Window Contents Capturing using WM_PRINT Message[^] RK

You might try DocBuilder[^] RK

Hi Chak. > How to detect logoff and lock event from atl COM Service It's easy with logoff - simply call SetConsoleCtrlHandler and catch the CTRL_LOGOFF_EVENT. Lock events are trickier. I guess the easiest way to catch them is via a Winlogon Notification Package[^]. Note: Because the notification Dll gets loaded by Winlogon and because Winlogon is running under the local System account (your COM Service probably isn't?), you can't use the SendMessage API as a means of IPC communication between them. Try memory mapped files or named pipes instead. Also, set the Impersonate[^] reg-value of your notification Dll to 1 or modify the Dacl of your memory mapped file/named pipe appropriately (check this: A NotQuiteNullDacl Class[^]). RK PS: This were just presumptions from the top of my head -> for the exact behavior/terminology and implementation check the MSDN documentation.

Hm, could it be that you export some functions via a .def file? Then check its first line - it should read as: LIBRARY PROGRAMM1.EXE RK

Check this: http://sunlightd.virtualave.net/Windows/FAQ.html#ConsoleChangeColour[^] > And how can I create registration entries? Hm...do you mean registry entries? Then RegOpenKey[^], RegCreateKey[^], .. is the answer. RK

> ..so basically I think this service should grab any keystrokes in any desktop Not at all. :) To grab keystrokes you have to call the SetWindowsHookEx API. Problem: SetWindowsHookEx resides in user32.dll and user32 functions are generally bound to a specific desktop. Because most services don't run under the logged-on user account you won't be able to grab the keystrokes of the loged-on user either (nor the keystrokes of any other desktop, like WinLogon for example) - at least not directly. Fortunately there are two exceptions to the above rule: 1. Services running under the local System account can be made interactive. In other words, they can interact with the user and thus grab its keystrokes too. But this way you will only grab the keystrokes of the loged-on users desktop -> it's the same as if you would make an ordinary win32 exe right away. 2. You can "connect" a (service) thread to a desktop via SetThreadDesktop. Knowing this, you could try on of the following: a) Spawn a new thread for each desktop that is present on the system; then call SetThreadDesktop and SetWindowsHookEx from within each thread. b) Since there is only one interactive desktop (=desktop, that receives the user input) at any time, simply call SetThreadDesktop and SetWindowsHookEx always when the active desktop gets switched. Note: This were just presumptions from the top of my head -> for the exact behavior/terminology and implementation check the MSDN documentation. RK

Hi LaoWei. First, there is a little bug in your CreateMultiThread:

void CTestMultiThreadApp::CreateMultiThread()
{
DWORD tID;
g_nIndex**[1]** = 0;
::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadProc, (LPVOID)&(g_nIndex**[0]), 0, &tID);
g_nIndex[1]** = 1;
::CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadProc, (LPVOID)&(g_nIndex**[1]**), 0, &tID);
}

Second, you use CreateThread in conjunction with MFC. This is dangerous. If your thread uses MFC support it should always be created via AfxBeginThread. Knowing this, you can write CreateMultiThread as follows:

void CTestMultiThreadApp::CreateMultiThread()
{
DWORD tID;
g_nIndex[0] = 0;
AfxBeginThread((AFX_THREADPROC)afxThreadProc,(LPVOID)&(g_nIndex[0]));

g\_nIndex\[1\] = 1;
**AfxBeginThread**((AFX\_THREADPROC)afxThreadProc,(LPVOID)&(g\_nIndex\[1\]));

}

Now your "Debug Assertion Failed" is gone bye bye... :) RK

Pha - you just wrote your 666th message :)

> How do I call from project2 a method in project1? In C/C++ CreateRemoteThread should do it. > Also, do I need to add header and other stuff > to project1 so that it knows how to find method1? Simply pass the address of ThreadFunc from project1 to project2 via some kind of IPC (Interprocess Communication). RK

> Is there a way to register a thread "cleanup" function > that gets called each time a thread exits? Hm..the first solution that comes to my mind: Call GetExitCodeThread periodically.

DWORD dwExitCode;
GetExitCodeThread( hThread, &dwExitCode);

if( dwExitCode == STILL_ACTIVE )
// thread still living
else
// thread terminated -> do your cleanup

Anyway, why don't you simply call the cleanup routine at the end of ThreadFunc (just before calling return)?

DWORD WINAPI ThreadFunc( LPVOID lpParameter )
{
// do your work

MyCleanUpRoutine();
return 0;
}

Regards, RK

> I want to do it without making a wrapper, and without hooking GetProcAddress ... You have to modify the entry point of the original function so that it first executes a JMP instruction to your implementation. Check this link: http://www.fengyuan.com/article/wmprint.html[^] There you will find a nice user32!BeginPaint hook implementation. However, because most user32 and kernel32 functions call an appropriate function in ntdll.dll, rather than executing the 0x2E interrupt directly (like BeginPaint does), your implementation will probably differ somewhat too; it will always depend on how the entry point of the original function looks like. More useful links: 1. Intel OpCodes[^] 2. Api Hooking Revealed[^] 3. API Spying Techniques for Windows 9x, NT and 2000 [^] Regards, RK

> So, what the hell must I do or include to have it work ????? Well, first you'll need to turn off precompiled headers for you .cpp file. :) 1. Project -> Settings (or Alt+F7) -> C/C++ Tab -> Category: Precompiled Headers 2. On the left pane select your .cpp file. 3. Select "Not using precompiled headers" on the right pane. Of course, you'll still need to include the appropriate headers... Regards, RK

> When my application calls the Test1() function, error occurred. > It reports : > ----------------------------------------------------------------- > file: i386\chkesp.c line:42 > The value of ESP was not properly saved across a function call. > This is usually a result of calling a function declared with > one calling convention with a function pointer declared with > a different calling convention. Hm...maybe you compiled your EXE with a different calling convention than your DLL? In VC6, check the following: Project -> Settings (or Alt+F7) -> C/C++ Tab -> Category: Code Generation -> Calling Convention You can also modify the calling convention of each function individually; i.e., try out all the combinations:

EXPORT BOOL __stdcall Test1(BOOL b1) { return b1; }
EXPORT BOOL __cdecl Test1(BOOL b1) { return b1; }
EXPORT BOOL __fastcall Test1(BOOL b1) { return b1; }

> When my application calls the Test1...() Anyway, is your EXE a VB application? Then you'll have to declare the exported function with __stdcall. It's the only calling convention known by VB. Regards, RK