Kiosk mode AIR desktop application - windows

I am developing a photo capturing kiosk application on AIR as3 for Windows Desktop.
I have set the stage display to FULL_SCREEN_INTERACTIVE and that works fine. (I have also hid the Start Menu and Task Bar)
The problem is if there is any pop-up like Windows Update or Team Viewer connection etc. it comes to the top in front of my application and then people are able to minimize my application and breach into my windows computer.
Can I do anything to make sure that my application ALWAYS STAYS ON TOP of all other messages, programs and applications ?

Related

Captive AIR application causes default web browser to launch when AIR app launched from OS icon

I have used NSIS to create an installer for an AIR application everything installs properly. As part of the installation I create a custom protocol like "MyVeryOwnApp://" so that if the user clicks an icon on a specific website it will launch the application.
The installer also creates a start menu and desktop icon. When installing on a "clean" machine, Windows 10, no other apps installed, everything works as it should.
On other Windows 10 computers including all of the development machines, when the application is launched the default web browser is also launched. This also occurs when launching the application from the Flash Builder 4.6 IDE.
I need to find out the cause so that I can either keep it from happening when I deploy the application, or at a minimum be able to explain to users what the issues are.
I have resolved the problem.
The cause was there was mxml code left over to set the browser focus into the main module. It looked like;
<utils:JavaScript>
<![CDATA[
function setBrowserFocus()
{
Main.focus();
}
]]>
</utils:JavaScript>
This evidently caused AIR to instantiate a new instance of the default browser.
I removed the code as it is no longer needed.

How to hide flashes on a touch screen?

I'm developing an Adobe Air application for Windows which makes use of a touch screen. When I touch the screen, both on the Windows desktop and within my app, there is a circular flash at the touch point.
How do I disable this, so that there is no visible indication of the touch point, other than that provided by my app? Is does not seem possible to disable this in the Windows touch settings, and there is no mention of visual feedback that I can find in the air API.
Try this...it worked for me on a win7 system.
OK,--Click Start, type in gpedit.msc and hit enter. --Click through
User Configuration --Administrative Templates -- Windows Components --
Tablet PC -- Cursors. --Double click on "Turn off pen feedback" and
select Enabled to enable the filter that turns off the ripple. Do this
not just for User Configuration but repeat the process for Computer
Configuration to make sure it is disabled for everyone using the
workstation
The link here.

Why does RDC eat my keystrokes?

I'm trying to use Microsoft's Remote Display Control (version 2.03, copyright 2000) to view my Windows CE device on the desktop (not only is it nice for my "regular" handheld device, because it makes the display easier to see, especially in zoom mode, but it is even more important for the other devices I have to test, whose screen is too dim for me to make out exactly what's on the screen (it's like the vision test from h311) - which is necessary for debugging, of course) but for some reason I am not able to enter key strokes on the device while it's connected to the desktop. I can enter them neither on the desktop/in RDC nor on the handheld device itself while connected via RDC.
This, of course, is untenable (no pun intended).
The .exe is created in XP Mode, copied to a "holding tank" in Windows Explorer on the Windows 7 machine, then copied from there to the handheld device.
Then I connect from the handheld device by selecting Start > Programs > cerdisp > selecting OK in the "Remote Display Control" dialog, then Connect, then OK (and I do connect), then run the app on the desktop in the "WindowsCE" window that RDC supplies. It allows me to select menu items, but the keyboard is broken/mute...???
Is this a known bug? Is there a workaround? The desktop is a Windows 7 machine.
Doing a "cold boot" of the handheld device caused it to come back to responsiveness, keyboard-wise. These devices are betimes more peckish than a put-upon puddle of Platypi.

How to detect if Windows 8 is showing desktop

In a Windows desktop application written in C# and running on Windows 8 how can I detect if Windows 8 is in desktop mode (i.e. showing the Desktop rather than the modern UI)?
Although it's in C++, the Start Screen Visibility Sample should be a good starting point for you. It uses COM objects to get the state of all monitors on the system that are either displaying Windows Store Apps or the Start Screen, and illustrates how to receive notifications when the state of a monitor changes or when the visibility of the Start screen changes.

Windows 8 Layered Windows Over Metro Apps

I have an app that runs on Windows 7 using Microsoft's Layered Window http://msdn.microsoft.com/en-us/library/ms997507.aspx. This app is setup to have a 30% opacity, it's always on top, and it is transparent to events (ie: it forwards all events to windows underneath it). You can think of it as a "screen" you are looking at your desktop through. It is currently being used to be an omnipresent feedback layer for our users.
We've tried running the same app on Windows 8, and notice it works as expected in desktop mode, but nothing overlays the start menu and other metro apps.
Does anyone know if there is an equivalent always on top window mode that works across metro apps and the start menu in Windows 8?
Yes, it is possible. Please take a look at this page:
http://blogs.microsoft.co.il/blogs/pavely/archive/2012/05/16/windows-8-topmost-vs-topmost.aspx
Specifically the second post in the comments section:
The topmost window is also affected by the accessibility settings. If you want a window on top of Metro, you need it to declare accessibility. Here are the key points:
The application must demand uiAccess (app.manifest)
The application must assert “topmost” window positioning (either in Win32/SetWindowPos or WinForms/WPF’s Topmost property, programmatically or otherwise)
Without making changes to the group policy setting, it must be installed to some trusted location [C:\Windows, C:\Program Files, C:\Program Files (x86)].
If you want to be able to run it out of an arbitrary location, you must disable the security setting: “User Account Control: Only elevate UIAccess applications that are installed in secure locations”.
This is the same as setting HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ValidateAdminCodeSignatures to 0
Said application cannot be run in the debugger
If it’s a .NET application:
The manifest must be embedded in a post-build step
The application must have “delayed signing” (meaning it cannot be ran from the built-in debugger, although you can build and attach – this is what Microsoft does)
The application must be signed with a trusted certificate.
Said trusted certificate must be installed to the Trusted Root Certificate Authority (this is important! It must not just simply installed)
Run the windows speech recognition. Its a top most window which floats over start menu, desktop etc. So its possible for sure. I am working on a touch simulator for Windows 8 and needed to implement this feature.
Here are the steps to achieve this:
http://www.pixytech.com/rajnish/2013/05/windows-8-topmost-window/
I am almost positive that you can't have any other app overlaying a Metro app. The new Metro environment is meant to run single, full-screen apps (or two, but only if snapped to the side). Further, allowing something to act as a man-in-the-middle is a bit dangerous, since they could capture all sorts of sensitive user data.
That being said, if you can set the "always on top" property of a window, it might stay put over the Start menu and various Metro apps. I know it works with Task Manager, but I have never tried with an arbitrary app. I do not know that it would work well for Metro apps, however, due to their events being different than old-timey winform apps. You'd have to see if your "screen" allows touch events to pass through.

Resources