Make window refuse focus

JRL · Post by **JRL** » Mon Dec 04, 2006 9:38 pm

Hello All,

There have been a number of threads about making a window stay-on-top. Does anyone know a way to do pretty much the opposite? I want to prevent a window from having focus even if a user picks on the window. I could continuously set focus on another window or the desktop but that steals focus from everything. I thought there might be some way to do this with a library function or a VBscript. So far, I haven't found anything.

Anyone have any ideas?

jpuziano · Post by **jpuziano** » Tue Dec 05, 2006 12:37 am

Hi JRL,

Try the code below. It should make it impossible to set focus to a new Notepad window i.e. a window with title = Untitled - Notepad

This first approach just quickly flips the focus back to whatever had it previously:

Code: Select all

OnEvent>WINDOW_NEWACTIVE,0,0,DoNewWindow

MDL>Notepad Auto Unfocus

Label>start
//loop until user kills macro with SHIFT-ESC
//add a Wait so as to not hog the processor
Wait>0.01
GoTo>start

SRT>DoNewWindow
GetActiveWindow>title,x,y
IF>title=Untitled - Notepad
   //Notepad window just received focus
   //so change focus back to previous window
   Press ALT
   Press TAB
   Release ALT
ELSE
   //Not a Notepad window so ignore
ENDIF
END>DoNewWindow

The above denies focus but still lets the user see the window. If you wanted to minimize as well, you could try this instead:

Code: Select all

OnEvent>WINDOW_NEWACTIVE,0,0,DoNewWindow

MDL>Notepad Auto Minimize

Label>start
//loop until user kills macro with SHIFT-ESC
//add a Wait so as to not hog the processor
Wait>0.01
GoTo>start

SRT>DoNewWindow
//Set for detecting Window Titles
Let>WIN_USEHANDLE=0
GetActiveWindow>title,x,y
IF>title=Untitled - Notepad
   //A new Notepad window just received focus
   //Set for detecting Window handles
   Let>WIN_USEHANDLE=1
   GetActiveWindow>window_handle,x,y
   //Minimize using handle (to ensure we minimize the right one)
   WindowAction>2,window_handle
   //Play an informative "Notepad Denied" wav file
   //PlayWav>c:\windows\media\Windows XP Critical Stop.wav
ELSE
   //Not a Notepad window so ignore
ENDIF
END>DoNewWindow

Note: I had it playing a "Notepad Denied" sound at one point but commented those lines out as the macro became unreliable (user was sometimes able to set focus to the notepad window anyway).

Marcus, do you know why that would make this unreliable? Timing issues?

JRL · Post by **JRL** » Tue Dec 05, 2006 2:27 pm

Thank you jpuziano, I've already tried this approach.

My goal is to write a script that will make a few applications available only with a password. I think that having the app visible is not bad but there may be exceptions. For example if the user can call Task Manager, they can possibly see enough information to figure out how to disable the application restricting program(s).

I have written this twice already, once where the focus was refused on the restricted app's window by calling a password window and forcing focus on it until the user either got the password correct or canceled. (more or less jpuziano's suggestion) When they cancel the restricted app's window is closed. The other is similar but I added a mouse position check that moves the mouse to the opposite side of the restricted window when the user attempts to move the mouse to the window. The problem with the first one is if the user is persistent they can still manage to make selections if they pick during a lull in the script's stay-on-top loop. Not a problem if stopping Notepad but In a web browser a good pick will get the next page. The problem with the second is that it's still possible to access the app via the keyboard.

I thought that possibly someone had already developed a libfunc or vbscript that could absolutely refuse focus to a window.

As I was typing this it occurred to me that if the "Enter your password" window went full screen and stayed on top there would be nothing else for the user to do but enter the password or cancel. Hmmm... sounds ugly but possibly effective.

Me_again · Post by **Me_again** » Tue Dec 05, 2006 2:33 pm

I thought windows could be locked down so that a user can't open task manager or the command prompt?

jpuziano · Post by **jpuziano** » Tue Dec 05, 2006 4:51 pm

JRL wrote:As I was typing this it occurred to me that if the "Enter your password" window went full screen and stayed on top there would be nothing else for the user to do but enter the password or cancel. Hmmm... sounds ugly but possibly effective.

That sounds promising, if the "Enter your password" dialog was full screen and "stay-on-top" with no re-size, minimize or close controls. Also, test how it responds to Alt-F4, does this close the password dialog? If so, the user will see the restricted app screen underneath.

Access to Task Manager is a problem of course. If they have that, they may figure out which app/process is running that is restricting them and simply kill it.

Having these restricted apps actually installed on their machines is also a problem. Since you're trying to restrict them based on detecting the actual windows of these apps, do I assume that these restricted apps must actually be installed, running and *doing something* on their machines and you are just trying to prevent them from altering certain settings? If so, continue on the path you're on. I'd be curious to see what you find works best.

Much safer of course would be to remove these apps from their machines and install them on a server (if that's possible in your case). That way you could authenticate them with a password and if they fail the login, there would be no app window they could see and no restriction apps/processes running on their machine that they might figure out how to kill.

Bob Hansen · Post by **Bob Hansen** » Tue Dec 05, 2006 9:23 pm

I was recently looking at a third party freeware utility to require passwords for any program. If you think you can use that, I will go locate it for you.

JRL · Post by **JRL** » Tue Dec 05, 2006 9:29 pm

Thanks Bob,
At this time I'd say don't put any effort into it. I think I have a method to make this work. I have what I feel is a working script. I'll post it when I think its bulletproof and the community can then shoot holes in it.

On the other hand if you run into it, go ahead and post its location.

Later,
Dick

Bob Hansen · Post by **Bob Hansen** » Tue Dec 05, 2006 9:36 pm

I did a quick look but did not see it. It is probably at another office site. I will look when convenient, but sounds like no rush right now..... glad you have a solution....

Rain · Post by **Rain** » Thu Dec 07, 2006 11:02 pm

Do you know the names of the apps windows you don't want the user to be able to set in focus?

Why not run a script that gets the active window title and if the window in focus is one of the apps you don't want the user to access reset the focus back to last active window?

Something like this:

Code: Select all

label>Get_Active_Window_Loop
wait>0.05
gaw>name,x,y
//Lets check the window name
if>%name%=(APPS you don't want user to set in focus)
//set focus back to last active window
set>%name%
endif
goto>Get_Active_Window_Loop

jpuziano · Post by **jpuziano** » Thu Dec 07, 2006 11:54 pm

Hi Rain,

Thanks for posting that code. I tried it using a Notepad window (Title = "Untitled - Notepad") as the window we don't want to allow focus to switch to but unfortunately it allowed me to focus Notepad. I liked your concept though and realized it should work fine if we just saved the title of the "previous non-restricted window" so we could switch back to it later if need be. Here's what I came up with:

Code: Select all

//need to save the previous window title to be able to switch back 

//Store initial window title in var "previous_name"
//Limitation: Restricted window must not have focus when macro starts
gaw>name,x,y
Let>previous_name=name

label>Get_Active_Window_Loop
wait>0.01
gaw>name,x,y
If>name=previous_name,Get_Active_Window_Loop

//New window now has focus so check window name
IF>%name%=Untitled - Notepad
   //Notepad not allowed - set focus back to previous non-restricted window
   set>%previous_name%
ELSE
   //new window OK so set previous_name value equal to this window
   Let>previous_name=name
ENDIF
goto>Get_Active_Window_Loop

A limitation here is that focus must not already be on the restricted window when this macro starts (though that could be coded for). Also, what happens if there are NO windows open... not tested... however, it seems to work fairly well when a few windows are open; it won't let you set focus to that Notepad window, seems solid.

I did find a way to make it fail though. Go to the bottom of the screen and repeatedly click the button for the Notepad App and if you do this quickly a few times, it throws the following error (it did for me anyway):

over-stressed little macro wrote:Warning

Specified Window "O" Not Present.
Any subsequent Key Sends in Script May Cause Exceptions.

Abort Ignore

Also, the "O" isn't an O but a single character that looks like a hollow box.

Why does it want to Abort here? Is this some sort of bug? (It never hurts to ask.) Anyway, that's a strange error. Has anyone ever see that one before or know what might be happening?

Also, does anyone have ideas on how this macro could be made *rock solid* and able to withstand any amount of clicking without allowing access to the restricted Notepad window or Aborting?

JRL, have you found a solution that can't be tricked or made to error out?

jpuziano · Post by **jpuziano** » Fri Dec 08, 2006 6:11 am

Hi Bob,

I'm getting more curious about that other solution you mentioned...

Bob Hansen wrote:I was recently looking at a third party freeware utility to require passwords for any program. If you think you can use that, I will go locate it for you.

I wonder if it works by inserting itself into the chain of messages Windows uses to communicate with itself. If a message is generated that tries to focus a restricted window, maybe it kills off that message before Windows "sees" it and reacts to it.

I'm not sure if JRL found a suitable solution yet but no rush on my part... just curious... whenever you come across it would be great.

By the way, just wanted to say thanks again for all your help and great info on the forums over the years. Your energy and willingness to jump in and help is flat out amazing. Your posts and the activity here were a big part of why I chose Macro Scheduler many years back... just wanted you to know you're appreciated... take care.

JRL · Post by **JRL** » Fri Dec 08, 2006 2:21 pm

jpuziano wrote:JRL, have you found a solution that can't be tricked or made to error out?

I'm working on it.

My primary goal was to password protect IE and Firefox. I think this concept could be used to password protect any software. I have a script that I think will do the job. Its not perfect in its current state. There are some techniques to make it much better and when I get the time to add those I'll post it.

Rain wrote:Why not run a script that gets the active window title and if the window in focus is one of the apps you don't want the user to access reset the focus back to last active window?

Tried that. It doesn't work with a browser. Even if the active window test loop has only a 0.001 second wait, there is still enough lag time for the user to select links on a web page. It gives the appearance of working with a browser that never has focus.

Incidentally, when there are no other open windows, set focus to "Program Manager".

Set>Program Manager

Sets focus to the desktop.

Later,
Dick

Bob Hansen · Post by **Bob Hansen** » Fri Dec 08, 2006 6:27 pm

I located the program I referred to earlier. I could not find it on my systems, because I did not have it! It was shown to me by an associate.

And I was wrong, it is not freeware. I had been looking at a 14 day trial that someone else had on their system, and they thought it was free. But the cost is not expensive, about $20 USD. (I know, expensive is always relative)

This is the page with tech info: http://www.mykeylogger.com/exe-protector/password-exe/

From their Help.chm file:

Main Features

Protect any Windows EXE file by setting the password (16/32/64-bit binary executable files are supported)
Set/remove password on-the-fly using user-friendly wizards
Protect file on local or network drives
Fail-safe protection is provided to make sure that you won't lock your operating system
Absolute integrity after you remove the password (file will be identical to the original one)
Protection is implemented directly on the file, without dubious background process protection
Password may contain up to 50 characters
No reboot is required after installation and setting/removing password-protection
Launch protected/unprotected file directly within EXE Password Protector for testing purposes
Create backup copy of the original EXE for the peace of mind
Extensive description of every step you will have to go though guarantees you an easy start
14-day try-before-you-buy demo license to evaluate EXE Password Protector
Truly user-friendly interface

I just downloaded my own trial version but don't know when I will get to test it out properly. Since I only saw a brief demo, I cannot safely recommend it at this time, but can only make you aware of its existence.

I have installed, passed AV and malware checks. I have found no bad comments/reviews when I googled the product. But, as with any new software, use at your own risk.

CAUTION: If you protect a file, and do not unprotect it before the 14 days is up, I don't know if you can ever unprotect it without purchasing the product. It does make a copy of the original exe file if you select that option, but I would be inclined to make my own master copies also, at least until more comfortable with what it does. Looks like it has a lot of potential if you need this type of security.