|
I'm writting a client program that lock the keyboard, mouse until the server unlock it. How can I do that on Windows 9X, and Windows NT/2000/XP?
How can I prevent CTRL+ALT+DEL, ALT+TAB... and hide my client from task list?
Thanks for any idea.
|
|
|
|
|
wow, that would make a nice virus;)
Later,
JoeSox
www.joeswammi.com
It's not easy facin' up when your whole world is black
Rolling Stones
|
|
|
|
|
No, it's not a virus. It is a client program of an Internet Cafe Manager software. 
Have you have any idea?
|
|
|
|
|
bpmtri wrote:
No, it's not a virus. It is a client program of an Internet Cafe Manager software.
I guess I am not understanding why you would want to lock the keyboard, don't these users need the keyboard
bpmtri wrote:
Have you have any idea?
I'll help you brainstorm. What OS will the users be using? This will help point in the right direction.
Later,
JoeSox
www.joeswammi.com
It's not easy facin' up when your whole world is black
Rolling Stones
|
|
|
|
|
I'm sorry. I have not described my problem clearly. I need to lock the keyboard (include special keys: CTRL+ALT+DEL, ALT+TAB...) and mouse to prevent the user from using the workstation without entering a valid ticket number.
On Windows 2000/XP, How can I prevent user pressing CTRL+ALT+DEL. And again, how can I hide my client from Task List on Windows 9X?
Thanks in advance.
|
|
|
|
|
WIN NT BASED OSes ONLY:
-----------------------
KEYBOARD AND MOUSE 1:
Take a look at "systemwide hooks" in MSDN in order to know how to prevent some system keystrokes and the mouse movements...
NOTES:
a system wide hook must be placed in a DLL in order to be systemwide and not application related. (its easier than what it seems).
I use to create two services (take a look at the VC++ assistant and create an ATL service) in order to use those DLL's (remember to keep some way to disbale those services using a password or something else...)
KEYBOARD AND MOUSE 2 (CTRL ALT DEL):
In order to capture those keystrokes, in NT you MUST write down a GINA DLL, this DLL is a security DLL that controls those kind of things, it's for security purposes, you cannot expect that an OS would be secure and to allow any programmer to execute any code that would be able to get the users passwords. (that DLL must be installed in the system and must be placed in it's own registry key).
PS:
Under win9x I remember I had readen something in the MSJ from PAul DiLascia that talked about preventing Ctrl Alt Del using a registry key... try to search for it...
Hope this helps
|
|
|
|
|
Joan Murt wrote:
KEYBOARD AND MOUSE 2 (CTRL ALT DEL):
In order to capture those keystrokes, in NT you MUST write down a GINA DLL, this DLL is a security DLL that controls those kind of things, it's for security purposes, you cannot expect that an OS would be secure and to allow any programmer to execute any code that would be able to get the users passwords. (that DLL must be installed in the system and must be placed in it's own registry key).
That's what I thought, until I saw this:
http://msdn.microsoft.com/msdnmag/issues/02/09/cqa/default.aspx
Seems it's not all that tricky unless you don't like a message box saying "Don't do this"
|
|
|
|
|
That's not a great idea (I think...)
1.
Policies can be modified by software, then, any program will be able to modify the policies and it can be dangerous for the user who would be working at admin level.
2.
Of course that this will be easier than making a new GINA, and depending on the scenery it can be very interesting.
Thank you, always is great to learn new things.
|
|
|
|
|
Using Windows API functions
g_hMsgHook = SetWindowsHookEx(WH_GETMESSAGE, (HOOKPROC)Msg_HookProc, hInst, 0);
and
g_hKeyHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)Key_HookProc, hInst, 0);
you can hook (block) any keys in win9x/NT except ctrl+alt+del.
In win 9x ctrl+alt+del can be locked by SystemParametersInfo(SPI_SCREENSAVERRUNNING, TRUE, &g_bKillAllSysKeys, 0);
In NT ctrl+alt+del can be blocked by writing your own Gina.dll (exported function WlxLoggedOnSAS), but be carefull with Gina...
For more details, see description of these functions in MSDN
|
|
|
|
|
In my application, when I click the minimize button in the upper right corner nothing happens. When I click the maximize button, the application in minimized. I put the following code in CMainFrame, and when I debug, I find that it is never accessed when I click the minimize button. Any suggestions as to why the minimize button is being ignored would be appreciated.
tia
void CMainFrame::OnSysCommand(UINT nID, LPARAM lParam)
{
UINT nItemID = (nID & 0xFFF0);
switch (nItemID)
{
case SC_MAXIMIZE :
MessageBeep(0);
// Window is maximized.
break;
case SC_MINIMIZE:
MessageBeep(0);
// Window is minimized.
break;
}
// call default functionality
CWnd::OnSysCommand(nID, lParam);
}
|
|
|
|
|
Shouldn't it be: switch (nID)
Regards,
Alvaro
That which does not kill me postpones the inevitable. -- despair.com
|
|
|
|
|
Alvaro
Thanks for the observation. What happens, is that if I hold the cursor over the minimize button, there is no tooltip showing, and if I click it, I never get to OnSysCommand. If I hold the mouse over the maximize button, I get a minimize tooltip, and if I click the maximize button, the app minimizes, and I do get into OnSysCommand. If I hold the cursor just between the maximize button and the close button, I get a maximize tooltip, and if I click, i go into OnSysCommand. Its as if XP is not recognizing the location of the buttons. This only happens with XP. With Win98, it works as it should.
bob
|
|
|
|
|
There is no problem with your code.
You have to check the following 2 conditions
1.Did u added in the Message handler?
BEGIN_MESSAGE_MAP()
ON_WM_SYSCOMMAND()
END_MESSAGE_MAP()
2.Did u declare the fn in .h file?
void OnSysCommand(UINT,LPARAM);
|
|
|
|
|
Yes I did both. The problem is that the maximize button is being treated as if I had clicked the minimize button, while when I click the minimize button nothing happens, and if I click exactly between the maximize buttonb and the close button the application maximizes. This only happens when I run the app under XP. I put this OnSysCommand code in to see if I could figure out what was happening
thanks
bob
|
|
|
|
|
I found out what was causing the probelm with the minimize and maximize buttons. I was using a class which did a gradation in windows 98, however it was causing problems when the program was run under XP. So I removed the class, and now it works well/
|
|
|
|
|
Hey, does anyone know how i could simulate the clicking on a systray icon (or its tooltip) via software? The closest i can get so far is to get a handle on the ToolbarWindow32...
Cheers,
Dave
|
|
|
|
|
If you have a handle to the window, then you could try:
::PostMessage( hWnd, WM_LBUTTONDOWN, 0, 0 );
::PostMessage( hWnd, WM_LBUTTONUP, 0, 0 );
This will simulate a click at the top-left of the window.
Dave
|
|
|
|
|
Oh i should have said, my problem is more getting the correct hWnd, the TrayNotifyWnd is only a container window, i can't seem to get the actual window that houses the actual icons...
Cheers,
Dave
|
|
|
|
|
You could take a look at SendInput or mouse_event in the MSDN (though SendInput won't work on 95).
Chris Richardson
You can stash and you can seize
In dreams begin, responsibilities
U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) - Rohit Sinha in the content-challenged thread
|
|
|
|
|
Scratch my last reply. Here's a function I wrote that will simulate a double click on a point in the tray. I'm sure it can be adapted to simulate a single click. Note that I only ran this on XP, the identifiers I pass to GetDlgItem might be different on other systems.
[edit]Oops, I forgot the pre tags[/edit]
void DoubleClickTheTray( int p_iX, int p_iY )
{
HWND a_hTray = FindWindow( _T("Shell_TrayWnd"), NULL );
if( a_hTray )
{
HWND a_hNotifyWnd = GetDlgItem( a_hTray, 0x12F );
if( a_hNotifyWnd )
{
HWND a_hPager = GetDlgItem( a_hNotifyWnd, 0x00 );
if( a_hPager )
{
HWND a_hNotificationArea = GetWindow( a_hPager, GW_CHILD );
if( a_hNotificationArea )
{
LONG a_lPoint = MAKELONG( p_iX, p_iY );
PostMessage( a_hNotificationArea, WM_LBUTTONDOWN, 0, a_lPoint );
PostMessage( a_hNotificationArea, WM_LBUTTONUP, 0, a_lPoint );
PostMessage( a_hNotificationArea, WM_LBUTTONDOWN, 0, a_lPoint );
PostMessage( a_hNotificationArea, WM_LBUTTONDBLCLK, 0, a_lPoint );
PostMessage( a_hNotificationArea, WM_LBUTTONUP, 0, a_lPoint );
}
}
}
}
}
Chris Richardson
You can stash and you can seize
In dreams begin, responsibilities
U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your - Rohit Sinha in the content-challenged thread
|
|
|
|
|
Is the above method any better/different than the following (apart from error checking, obviously):
starthandle = FindWindowEx(0, 0, "Shell_TrayWnd", NULL);
starthandle = FindWindowEx(starthandle, 0, "TrayNotifyWnd", NULL);
starthandle = FindWindowEx(starthandle, 0, "SysPager", NULL);
starthandle = FindWindowEx(starthandle, 0, "ToolbarWindow32", NULL);
Ok, i've found that clicking the tray's icon does nothing, what i want to do is click on the tooltip that the icon brings up. Is there any (easyish) way to do this?
Cheers,
Dave
|
|
|
|
|
That code looks like it would work the same.
CommoDave wrote:
Ok, i've found that clicking the tray's icon does nothing, what i want to do is click on the tooltip that the icon brings up. Is there any (easyish) way to do this?
I'm really not sure how you would go about doing that. A windows hook could probably be used to monitor when the tooltip is displayed, then the click could be simulated (now that we would have the tooltip window). Maybe there's an easier way to get the end result you are trying to get though. What are you trying to do with this? Are you trying to just hide the tooltip or are you trying to do something more complex?
Chris Richardson
You can stash and you can seize
In dreams begin, responsibilities
U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your - Rohit Sinha in the content-challenged thread
|
|
|
|
|
I'm trying to work around a conflict for an automated driver installation program. Windows installs the windows certified device driver for the hardware id of the device, but comes up with a window asking for driver files. It will not allow us to use the better device driver. The window must be cancelled, then the driver windows installed is updated to the newer driver.
I can cancel the window that comes up, but the window will not come up for about 30 secs if the tooltips are not clicked on....
Cheers,
Dave
Cheers,
Dave
|
|
|
|
|
I am trying to develope an application that runs on Windows 95, 98, ME, NT, 2000 and XP. I develope on a nice new/fast PC running Windows XP. After getting most problems worked out on the desktop I started testing on other version of Windows. Boy was I surprized how the same executable would run differently on different version of Windows.
Here are some examples: I have a dialog box that has a property sheet with 3 property pages. On the pages there are buttons that call up a CColorDialog. It works fine on XP, but hangs the machine on ME. For this case I re-designed the dialog to be stand alone property sheet with the same 3 property pages. This approach works on XP and ME, still need to try on others.
Another example is the CRectTracker. On XP the code uses a CRectTracker and the handles and cursor change when the tracker is displayed. On ME the cursor disapears when the CRectTracker::Track function is called.
I am quickly comming to the conclusion that to have an application that runs on 32 bit windows, it cannot be any more complicated that a list box and a few buttons. Does anybody from Microsoft read these pages?
So my question is how do you develope an app for all these version of windows? Do you develope on 95 (the worst one) and once you have it working there, there is a good chance it will work on the others? Do I need to build the exe on a PC running each of the different versions? Is building the exe on XP and delivering it to a customer running 95 an approach that will work?I don't even have access to some of these versions. Does anybody have any ideas?
Thanks for any ideas
Craig Smith
|
|
|
|
|
I will probably get flamed for posting my comments on this one but here is my two cents:
1) Windows 95? Are people using an OS that is 8 YEARS OLD?
2) Millenium users...I feel sorry for them, that is the worst Windows probably released.
Windows 98/2000/XP need to be targeted in my opinion although I am by no means an expert.
P.S. Windows XP cleans up a lot better than it's predecessors so that is something you want to watch out for when targeting older platforms.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
