This is a long shot but...we have an Air app that needs to run continously, even if the computer has a screensaver. Is there any way to detect and override that?
Thanks!
So, you want a way, without user intervention, to force your application to run continuously, overriding the users choice in the matter?
Programs that do that are usually called viruses.
How 'bout a big dialog box that says "Turn off your screensaver".
Related
I need to create a simple Delphi application, kiosk style.
It is a very simple thing, a single form where the user writes some personal info to register to an event. 4 TEdit and a TButton.
What I want to achieve is to avoid the user does any action different then typing in TEdit or clicking on the TButton. For example I don't want he does ALT TAB (switchin applications), pressing windows key on keyboard, doing ctrl-alt-canc, etc...
I can add a passowrd protected Button that enables/disables this "Kiosk mode", in this way as I need to exit the kiosk mode I simply press that button and exit.
How to achieve this "kiosk mode" in Delphi without intercepting all the keystrokes manually? Or did anyone already develop this so it can be shared?
I think you'd better create a new desktop, and run your app in there. When your app is done, you can bring back user's desktop. That is how Windows login screen works. Of course Windows login screen uses a special secure desktop. Your app in a separate desktop would be isolated. You will have a desktop background with no start menu, taskbar, or desktop icons because explorer.exe is not running there automatically. Of course a can start a new process, using Task Manager, but desktops in Windows are securable objects; therefore, you can make restrictions if you want. Of course if your app has sufficient permissions.
To create a new desktop, you can use CreateDesktop Windows API, and to switch to the newly created desktop, you can use OpenDesktop function.
You can try Change the Windows Shell.
When you start windows, you don't execute the default shell (explorer.exe), you can execute your application.
Al internet you can find alternative Shell (more attractive) to default windows like:
BlueBox or
SharpE
This option is used for purposes similars at the application that you are developing. Kiosks or TPV.
For change the default applicacion you must modify a registry key:
In Win3.x and Win9x, SYSTEM.INI file:
[boot]
shell=MiAplicacion.exe
In Win2k and WinXP, use Registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
Shell=MiAplicacion.exe
If you test this option, think the mode to turn the configuration to the original value (button or option). You must reboot to test changes.
ADDED: In addition, if you search on the web some similar at this "Delphi Change default windows shell", you can find more code, samples and information about this.
Regards
P.D: Excuse me for mistakes with english.
Well but if someone can open the taskmgr he could just create a new task and run explorer.exe from there so its not really secure though...
Ok Taskmgr can be stopped with policies...
Well and for disabling the cad sequence you can use saslibex which Remko Weijnen had created you can find it here: SASLibEx
kindest regrads,
s!
Requirements:
Our application replaces the usual windows shell (explorer.exe). This is a product requirement for a closed system that we're supplying.
We oughtta let the user select a wi-fi network and connect to it.
The problem: The wi-fi networks dialog only shows up when explorer.exe is running
What we tried:
Write our own wi-fi manager that uses wlan API. It lists connectible networks and allows the user to connect/disconnect. Problem: too many network types/configuratons that have to be tested, especially when the wheel has already been invented and reinvented all over.
Try and check how is the networks dialog implemented. It appears that it's and undocumented COM interface (IUIRAdioManager). Problem: it's undocumented, so no API
Use an existing network manager, for instance the one that comes with the driver. Problems: it's ugly, not to the product's taste; and it opens too many options for the user, like creating and loading profiles, browsing for files on a file system - these things are unacceptable.
Running explorer.exe just for the purpose of showing the networks dialog and then killing it. Problem: once we run explorer.exe - it pops up metro view and hides our fullscreen application or shows the taskbar.
The latter seems like the preferred solution: no need to reinvent the wheel, it does what's needed. Just gotta make explorer.exe not pop out, keep it quiet in the background.
So, we're down to two options:
How to show the networks flyout dialog without explorer.exe?
How to run explorer.exe without it popping out metro or taskbar above our application?
Your first solution would be incredibly difficult to implement. I am almost certain that the Networks window is dependent on explorer.
However, your second is entirely possible.
To hide the taskbar, you will need to find a window (using FindWindowEx) to find the taskbar (name is Shell_traywnd). This will hide the taskbar and start button. EDIT: Unless you are implementing your own taskbar, you might want to set the taskbar to autohide.
Next you will need to hide all of the metro programs. In a similar fashion as above, find the class named EdgeUiInputWndClass and close it. You should be able to get the process name of it and then kill the process.
Windows key. This is a little more difficult. You will probably need to use a program and delete the key or a keyboard hook (a low level keyboard hook) and just ignore key presses with the same scancode as the windows key. Left Windows is 0x5b and Right is 0x5c (source). Note that this will not block Ctrl+Alt+Del.
Finally, to show the Flyout, you can run %windir%\explorer.exe shell:::{38A98528-6CBF-4CA9-8DC0-B1E1D10F7B1B}
(source).
EDIT2:
You should also be able to hide toast notifications via this
Of course, I don't see why you cannot just use Windows 8/8.1 and put the app in kiosk mode.
Here's a though question:
I need to find out when the user double-clicked the OS X desktop, but not icons on it.
Now, I have thought of the following solutions, though I am not sure if they are doable:
Using desktop icons position (not sure how to get them), and the size of the desktop icons, we could theoretically check once the user double-clicks on the desktop, if it is inside one of the icon areas. Contra: Might not be flawless as some icons might be transparent or not taking up the entire icon size.
Maybe there is a variable that tells us if a icon from the desktop has been clicked? Then we could just check if that variable has been activated when the user double-clicked the last time the desk.
I am certainly still open to other (better) solutions, but they need to be sandboxable for the Mac App Store.
This is probably not going to be appropriate for the Mac App Store, for a number of reasons.
First, how are you going to intercept clicks outside your window? There are a few different mechanisms for this (e.g., event taps), but none of them are allowed in sandboxed apps. And that's intentional, and for a good reason—you're not supposed to be interfering with other apps or with the OS.
On top of that, it's hard to imagine that whatever you're trying to do wouldn't count as non-standard UI/HIG stuff, which is another reason for rejection.
But, assuming none of that were a problem, and you could intercept clicks on the desktop, there's no documented way to get all the icons on the desktop, so you have to read the .DS_store file directly, which means relying on private implementation information, which is another thing you're not allowed to do.
Finally, you have to get access to that .DS_store file. Unless you're expecting the user to drag the (invisible) file or its parent directory to your app or select it in an NSOpenPanel or something, the only way to get such access from inside the sandbox is via a temporary exception entitlement. Which you can't use unless you can justify to the reviewer why you need it as a workaround for a bug or limitation in the OS. So, what's your justification going to be?
I'm looking for a way to use your location to determine whether you need to unlock your phone or not, eg at home you just slide to open, but as you leave you then need to enter your code.
Nope, you can't, since your app would be run in a Sandbox, so it can't interact with the whole system (Springboard etc).
How would I go about locking a screen like Keychain does, meaning preventing all access to Dock, menubar, desktop, etc. Basically just a black screen that I can add a password field to, for the user to return to the desktop? I am well aware of the Carbon method, but I want the NSApplication method because this is an all Cocoa application.
Thanks~
If you can get away with not writing this code yourself, all for the better. It is usually a terrible idea to write your own code to lock the screen, considering the number of vulnerabilities that have been found in screen locking code over the years. If you have a Carbon call that can do it, go ahead and use that... don't worry about the "purity" of your Cocoa code.
However, if you decide to write this yourself, here's what you do:
First, capture all the screens using CoreGraphics. See: http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/QuartzDisplayServicesConceptual/Articles/DisplayCapture.html
Next, create a new NSWindow and put it in front of the window that's used for capturing the screens. You'll have to call a CG function to get the "order" of the black window covering each screen, and order the new window in front of that. Normally, the black window has an order so far forward that everything is behind it. Put a password field in the window. Do NOT use an ordinary text field or write your own code for password input. The password input field has a ton of special code in it so you can't copy text out of it, and other programs can't listen to keystrokes while you're typing into a password field. So use the one that Apple provides.
Last, put the computer in "kiosk mode". This mode allows you to disable alt-tab, user switching, the menubar and dock, and even the ability to force quit. See: http://developer.apple.com/mac/library/technotes/KioskMode/Introduction/Introduction.html
It's not a lot of code, it just uses a few different APIs so you'll spend most of your time bouncing between API docs. I suggest writing the screen lock code as its own application (just add a new application target to your Xcode project) and then put the screen locker inside your application bundle. This used to be (as of 10.4) how Apple Remote Desktop implemented the "Lock Screen" functionality, but I can't find the app anymore.
I believe the Cocoa replacement to the SetSystemUIMode API was not introduced until 10.6.
If you can live with Snow-Leopard-only code, the answer is - setPresentationOptions: on NSApplication.