Display TV content in SiteKiosk (using a Hauppauge TV device)

If necessary you can also display content from a TV device in the SiteKiosk Browser using an ActiveX control.

Some manufacturers already provide an ActiveX control for their TV device (if it works in the Internet Explorer 32 Bit it should also work in the SiteKiosk Browser).

Otherwise you will find the description about how to develop an ActiveX and a basic example about how to use it with SiteKiosk in this article.
Provisio developed a simple ActiveX Control Based on a SDK from Hauppauge that can be used with Hauppauge TV Cards to display TV content in the SiteKiosk Browser.

In the following you will find the description how to install and use it in SiteKiosk.
At the end of this article you will also find the download link to a ZIP that contains the ActiveX source which developers can use to make additional customizations to the ActiveX.
The provided ActiveX can be used with Hauppauge devices that are supported with the actual WinTV 7 software from Hauppauge. It was created with the SDK that Hauppauge provides at request.
http://www.hauppauge.co.uk/site/contact/contact_us.html

Requirements:
A. An actual Windows system (Windows XP / Windows 7 / Windows 8)
B. The WinTV 7 Redistributable SDK software from here:
http://www.provisio.com/Download/DevBlog/WinTV/WinTV7Setup-SDK-31191-Redist.zip
C. The Microsoft .NET Framework v4.0.30319 has to be installed on the PC too.
http://www.microsoft.com/en-us/download/details.aspx?id=17718
D. The ZIP containing the ActiveX and 2 demo HTML files from here:
http://www.provisio.com/Download/DevBlog/WinTV/WinTVCtrl.zip
E. SiteKiosk (for using the ActiveX in the SiteKiosk Browser):
http://www.provisio.com/en-US/Downloads/Download.aspx?ItemId=1

Usage:
1. The WinTV 7 Redistributable SDK software from Hauppauge has to be installed on the computer where you want to use the ActiveX (the WinTV 7 Software is also included)

2. Start the WinTV 7 Software and configure the WinTV device. The TV channels have to be configured with the WinTV Tool before, so that the ActiveX will find the channels.

3. Unzip the file "WinTVCtrl.zip" and copy the folder "WinTVCtrl" to "...\SiteKiosk\Html\"

4. Register the ActiveX dll as follows:
- Open the command line (cmd.exe) with "Run as administrator" and enter this command (on x64 Systems use "C:\Program Files (x86)\..."):
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe" "C:\Program Files\SiteKiosk\Html\WinTVCtrl\WinTVCtrl.dll" /codebase

For testing/using the ActiveX choose the "test_WinTVCtrl.html" or the "test_WinTVCtrl2.html" at "C:\Program Files\SiteKiosk\Html" (on x64 Systems use "C:\Program Files (x86)\...") in SiteKiosk configured as start page (-->Start Page & Browser).
Then start SiteKiosk in "Run once" mode first for testing.
When opening the web page it may take some seconds until you can watch the TV content because the ActiveX will be initialized.

The "test_WinTVCtrl.html" provides some buttons to control the displayed content (choose a channel and use the watch button to display the TV channel that is chosen)

The "test_WinTVCtrl2.html" will just display the TV content and switch the channels automatically every 30 seconds.


Development:
Feel free to customize the HTML files to fit your needs or even create your own HTML file and implement the ActiveX.

In case you want to customize the ActiveX or develop it further you can download the (Visual Studio) source files for the ActiveX Control from here:
http://www.provisio.com/Download/DevBlog/WinTV/ActiveXSource.zip

Furthermore you would need the full WinTV SDK that Hauppauge provides at request.
http://www.hauppauge.co.uk/site/contact/contact_us.html

Creating a Custom SiteRemote Alert

The SiteRemote server already offers a variety of alerts that help you maintain your kiosk systems. But for specific projects it is helpful to be able to create additional alerts that can trigger an email or sms to notify about a possible problem. Customers running their own SiteRemote server can create their own custom alerts. Creating such an alert requires work on the client side (SiteKiosk) and on the server side (SiteRemote). The following is a short guide to creating a custom alert:

 

1. SiteKiosk

To create new alerts you first have to write the alert event into the log file of the SiteKiosk client machine. To do this, you can use the SiteKiosk Object Model which can also be accessed from other programming languages. The log entry you create with the SiteKiosk Object Model will be used to trigger SiteRemote alerts.

The Write method of the SiteKiosk Object Model is used to create log entries for custom alerts: http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logfile_write_mth.html

The Write method has the follwing parameters:

type

Short value that specifies the type.

level

Short value that specifies the level.

facility

String that specifies the facility.

text

String that specifies the text to write.

 

The Type property contains the type of the log file message. Possible types are: http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logmessage_type_prop.html

The Level property contains the level of the log file message. Possible levels are: http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logmessage_level_prop.html

The Facility property contains the description of the device, plugin or component (http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logmessage_facility_prop.html).

The Text property contains the text of the log file message (http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logmessage_text_prop.html).

See the LogMessage object for further information about the parameters (http://www.provisio.com/en-US/Help/ObjectModel/sitekiosk_object/logmessage_obj.html).

 

More information about the SiteKiosk Object Model can be found here: http://www.provisio.com/en-US/Help/HelpFrame.aspx?HelpFolder=ObjectModel.

 

The example code for our custom alert looks like this:

SiteKiosk.Logfile.Write(9999, 40, "CustomFacility", "Custom Text to write");

 

When adding this to an HTML example page we will get this:

<html>
	<head>
		<title>Write Log</title>
		<SCRIPT TYPE="text/javascript">
		window.external.InitScriptInterface();
		function WriteLog(){
			SiteKiosk.Logfile.Write(9999, 40, "CustomFacility", "Custom text to write");
		}
		</SCRIPT>
	</head>
	<body>
		<input type="button" value="SiteKiosk Logfile Write Button" onclick="WriteLog()">
	</body>
</html>

Copy & paste the code into an editor (e.g. Notepad) and store the html file (e.g. Alert.html) at the path “…\Sitekiosk\Html”. Configure the html file as the start page and run SiteKiosk to test. The log entry will be created when you click the button.

 

2. SiteRemote Server

With the example above you will see a log entry like this appearing on the SiteRemote Server:

40 9999 2012-07-17 13:51:22 +0200 [CustomFacility] Custom text to write

In order to get an alert notification from this log entry you created, you will need to edit the Notification settings on the Settings page of the Administration section of your SiteRemote server installation.

To receive an alert email and/or SMS, you need to create the corresponding entries under the “Notification settings”.  Create the entries by adding new strings with the text for the alert message (-->Users-->username-->Alert Notifications-->Notification options for results).

Please follow the next steps to configure your SiteRemote server to show a custom alert:

A. Open the SiteRemote Administration page and go to the “Strings” tab. Select the language and use the “Add new” button to create a new string. The next free ID will be chosen automatically.  Enter your message in the text field.

For our example (ID 3545 CustomEventTitleText / ID 3546 CustomEventBodyText / ID 3547 CustomEventGroupID):

Note that for SiteRemote Server 6 and higher you need to create the strings twice. Once under the Web-Strings tab and once under the Report-Strings tab. Both can be found on the Strings page of the Administration. Use the same IDs under both tabs.

The following variables can be used to get the server name, the alert text and the alert time from the client in your alert notification:

$(Server_name_short) receives the error "$(Alert:LogText)". Error occurred at $(Alert:LogLocalTime) local machine time.

Use the existing entries for “SiteCashError” as a reference:

B. After creating the new strings, open the “Settings” page.

Under “Notification settings” follow the “Edit configuration” link.

Press the “Add New” button at the “LogMessage options” section.

You will see a form like this:

Enter the corresponding values for your log entry with “Fire if message count > 0” and “Period (min): 0”. In this case we chose the event name “CustomEvent”:

Use the Save link to save the new entry.

C. Scroll down to the “Notification Events” and press the “Add New” button.

The “Name” value must be an exact match to the “Event name” that was used under LogMessage options section.

The value for "Bit" is a number to represent the ID of the Event.

Select the next free Bit number or the highest available number.

For the different IDs enter the string number(s) you have created.

- OnlineTitleId: Title text on the web page

- OnlineTextId: Body text on the web page

- MailTitleId: Title text Email

- MailTextId: Body text Email

- SMSTitleId: Title text SMS

- SMSTextId: Body text SMS

For our example this means:

Use the Save link to save the new entry.

D.  Scroll down to “Groups” and press the “Add New” button.

The “Events” value must be an exact match to the “Event name” that was used under the LogMessage options section.

The value for "Bit" is a number to represent the ID of the Event.

Select the next free Bit number or the highest available number.

Enter the string number you created for GroupID in the “TitleID” box.

For our example:

Use the Save link to save the new entry.

Click the OK button at the bottom of the page to save and move on to the next step.

 

Last, login to your SiteRemote team account and activate the new alert on the settings page (-->Users-->Username-->Alert Notifications-->Notification options for results).

For our example:


Now, when you press the button that was created to write the SiteKiosk log file entry, you will get an alert when logged into your team account and via email and/or SMS (if configured).

 

Example online text:

Example email text:

When an alert is triggered, it will be displayed in your team account and sent by email if that option is configured. If you do not receive the email even though the alert is displayed, you should check the “Delay” that is configured under “-->Settings-->General-->Alerting Delay” (default 15 minutes).

Tools for Creating an Automated SiteKiosk Installation

Deploying a SiteKiosk rollout on a great number of terminals can become a lot easier using some of the tools provided by PROVISIO. With the help of these tools you can create a standalone installation script that you bundle with the required files or use it to create an installation package with one of the deployment toolkits available on the market or prepare a machine to create an image using an imaging software. One of the deployment toolkits is Microsoft's SCCM, which has been the topic of an FAQ article already.

The following is an overview of the tools and what you can do with them.

The installer of SiteKiosk allows you to conduct a silent installation as part of a script or using a deployment toolkit. To do so you need to start the executable of the installer that can be downloaded from our website www.provisio.com with parameters. A basic silent installation of SiteKiosk looks like this:

sitekiosk.exe /S /V"/qn"

A full list of available parameters for the silent installation, including examples, can be found in this FAQ article.

During the installation of SiteKiosk a little tool will be copied to the installation path of SiteKiosk (default path: C:\Program Files\SiteKiosk). The tool ist SKStartup.exe (default path: C:\Program Files\SiteKioskSKStartup.exe). This tool can be used to register SiteKiosk and set the startup options. To register SiteKiosk use the license name and license number you received from PROVISIO or a reseller as parameters for SKStartup.exe:

SKStartup.exe /l "YourComp - 10 License(s)" /s 9QH6H-YWF7V-R2PAR-WT3MT-DX6F6

The parameter /l is followed by the license name and the parameter /s is followed by the license number.

SKStartup.exe can also be used to automatically set the desired start settings for SiteKiosk, e.g. Autostart. For this a bit of extra work is required. First you need to create a SiteKiosk configuration file that fits your kiosk project using the SiteKiosk configuration tool, preferrably safe it to the default location for SiteKiosk configuration files: C:\Program Files\SiteKiosk\config\. Next you start SiteKiosk and from the SiteKiosk Quick Start menu you select Customized. Choose your configuration file and set all the start options as desired, then click on the Export button to export your startup options. This creates a file called startup.xml. This file needs to be part of your installation package. You can copy it to wherever you want, e.g. directly into the SiteKiosk installation path once the installation is done. Now you can use the /i parameter with SKStartup.exe to apply the start settings on any of your SiteKiosk terminals:

SKStartup.exe /i startup.xml

Make sure to also copy the SiteKiosk configuration file you created to the same location you used while creating the startup.xml file on all of your machines.

You can of course register SiteKiosk and set the startup options in just one step:

SKStartup.exe /i startup.xml /l "YourComp - 10 License(s)" /s 9QH6H-YWF7V-R2PAR-WT3MT-DX6F6

Note that in order to use the SKStartup.exe you need to first install SiteKiosk, e.g. using the silent installation and only then register SiteKiosk and set the startup options. The SiteKiosk configuration file and the startup.xml file can be created on any PC you have installed SiteKiosk on, you can even use an unregistered version for it.

The SKStartup.exe is also described on this page of the SiteKiosk help.

An optional step is to automatically register the SiteKiosk terminal with a SiteRemote team. This is obviously only required when you want to use the remote management and digital signage features of SiteRemote. Within a SiteRemote team you can find the Extras button which will bring up the Apps page where you can find the Auto Register Tool. You can install the tool on any PC. It provides a small GUI that lets you select your SiteRemote client type and the data required to register a terminal at a SiteRemote server. Once this data is provided a file will be created with the registration data necessary to register a client. The GUI also provides information where this file needs to be copied on a client to start the registration process, the path depends on the client type. Make the resulting file a part of your installation package and during the installation process, after SiteKiosk has been installed, copy it to the required location. Once the file is at the final location and the terminal is able to reach the SiteRemote server it will be registered.

When creating an image instead of an installation script or package you don't need to use most of the tools as you can do most of the required steps with the normal GUI options of SiteKiosk. Use the imaging software of your choice and make sure to follow its procedures to create a working image. Install the operating system and all required updates and drivers. Also install other software like Flash or Acrobat Reader if desired and apply all available updates to them as well. Make sure everything that requires it is registered.
Now you would install SiteKiosk and prepare the configuration to include all the settings required for the kiosk project. You can also register SiteKiosk, if your license count covers enough machines. You may also configure the desired start settings.
Next you are ready to shutdown the machine and create the image using an imaging software.
An optional step before shutting down the machine to make the image would be to prepare it for use with SiteRemote. An important thing to remember is to not register the machine with SiteRemote before you create the image, otherwise all machines using that image will show up as the same machine under SiteRemote. Instead use the Auto Register Tool described above to create the auto registration file. Before copying the file to the required folder (see the instructions in the GUI of the Auto Register Tool) make sure to disconnect the internet connection to prevent the machine from directly registering itself. Once the file is in place you are ready to start the imaging process.

Whether you prefer a script, a deployment toolkit or an image to deploy a great number of SiteKiosk terminals, the above tools should provide you with the necessary help to make this an easy task.

Verschiedene Lösungen für das Kompatibilitätsproblem von SiteKiosk unter Windows 7 mit Internet Explorer 10

The English version can be found here: http://devblog.provisio.com/post/2013/04/10/Solutions-to-Fix-the-Compatibility-Issue-with-SiteKiosk-and-IE10-on-Windows-7.aspx

Das Kompatibilitätsproblem, dass die SiteKiosk Versionen 7.1 bis 8.6 unter Windows 7 bei installiertem Internet Explorer 10 betrifft (Windows 8 Systeme sind nicht betroffen), ist ab der SiteKiosk Version 8.7 gelöst worden. Die empfohlene Problemlösung ist daher ein Update auf mindestens SiteKiosk 8.7 durchzuführen. Das Update ist kostenlos für alle Nutzer von vorhergehenden SiteKiosk 8 Versionen und für alle Kunden mit SiteKiosk 7.8, die ihre Lizenz seit August 2011 erworben haben.

Kunden, die kein Update auf mindestens SiteKiosk 8.7 durchführen können oder wollen, stehen die folgenden Lösungen zur Verfügung, um das Problem zu lösen:

  1. 1) Laden Sie diesen kleinen Fix herunter, den wir auf unserer Webseite anbieten und führen Sie die Exe-Datei aus.

    Sie können den Fix auch als Silent-Installation durchführen. Nutzen Sie dafür auf der Kommandozeile den Parameter /s (IE10patch.exe /s).

    HINWEIS: Nutzer mit einer SiteKiosk 7.1 Version auf Windows 7 64Bit Systemen müssen vor der Anwendung der Fix-Datei mindestens auf SiteKiosk 7.5 updaten.

  2. 2) Die zweite Lösung ist für alle Nutzer verfügbar, die www.siteremote.net für die Fernverwaltung Ihrer Kiosk Terminals nutzen oder einen eigenen SiteRemote Server betreiben.
    Wenn Sie sich in Ihr Team unter www.siteremote.net einloggen und zum Aufträge-Tab gehen, finden Sie dort eine Auftrags-Vorlage mit dem Namen Windows 7 IE 10 Fix. Weisen Sie diesen Auftrag Ihren Windows 7 Maschinen zu. Lesen Sie bitte zuvor die Ausführungen die in der Auftragsbeschreibung stehen.
    Das Nachfolgende gilt nur für Kunden, die Ihren eigenen SiteRemote Server betreiben. Kunden mit einem eigenen SiteRemote Server können die obige Auftrags-Vorlage selbst erstellen. In einem Team auf Ihrem SiteRemote Server gehen Sie bitte zum Aufträge-Tab und klicken dann unten auf der Seite auf Neue Vorlage. Wählen Sie einen Namen und eine Beschreibung und als Clienttyp SiteKiosk. Wählen Sie dann Datei hochladen als Aktionstyp und klicken Sie auf Hinzufügen. Laden Sie die Datei win7ie10fix.js aus diesem zip-Archiv zum SiteRemote Server hoch und nutzen Sie %SiteKioskPath%\ als Zielpfad. Stellen Sie sicher, dass Sie das Überschreiben von bestehenden Dateien auswählen. Jetzt selektieren Sie bitte Ausführbare Datei starten als Aktionstyp und klicken auf Hinzufügen, um einen zweiten Auftragsschritt zu erstellen. Nutzen Sie wscript.exe "%SiteKioskPath%\win7ie10fix.js" als Befehlszeile. Stellen Sie dann Sichtbare Ausführung mit Benutzerrechten ein. Als optionalen Schritt können Sie noch den Exit-Code auf einen Wert von 0 setzen und dies als erfolgreiche Ausführung markieren. Speichern Sie die neue Vorlage und weisen Sie diese Ihren Windows 7 Maschinen zu.

 

Falls Ihr Rechner bereits von dem Problem betroffen ist und sich in einer Startschleife befindet, können Sie die in diesem FAQ-Artikel aufgeführten Instruktionen verwenden, um das System zurückzusetzen: http://www.provisio.com/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=60.

Solutions to Fix the Compatibility Issue with SiteKiosk and IE10 on Windows 7

The compatibility issue that affected SiteKiosk versions 7.1 to 8.6 under Windows 7 systems with Internet Explorer 10 (Windows 8 systems are not affected) has been fixed in SiteKiosk version 8.7 and higher. The recommended solution to the problem is therefore to update SiteKiosk to at least version 8.7. This update is free for all users that already run a previous version 8 of SiteKiosk and for all customers with SiteKiosk 7.8 that have bought their license since August 2011.

Customers who cannot or do not want to update to SiteKiosk 8.7 or higher can use the following solutions to fix the problem:

  1. 1) Download the small fix we provide here on our website and then just run the executable.

    You can also run the fix silently via the command line if you use the /s parameter (IE10patch.exe /s).

    NOTE: User who are running SiteKiosk 7.1 under Windows 7 64Bit systems need to update to at least SiteKiosk 7.5 before applying the fix.

  2. 2) The second solution is available for all users who use www.siteremote.net to remotely manage their kiosks or use their own SiteRemote server. When you log in to your team on www.siteremote.net and go to the Jobs tab you will find a new system job template named Windows 7 IE 10 Fix. Apply this job to your Windows 7 terminals, make sure to read the job description first.
    The following only applies to customers who run their own SiteRemote server. Customers with their own SiteRemote server can create the above job template themselves. Under a team on the SiteRemote server go to the Jobs tab and at the bottom of the page click on the New Template button. Use a job name and description as desired and set the client type to SiteKiosk. Select File Upload as action type and click on Add. Upload the win7ie10fix.js from this zip archive and use %SiteKioskPath%\ as destination path. Make sure to select to overwrite existing files. Next select Run Executable as action type and click Add again to create a second job step. Use wscript.exe "%SiteKioskPath%\win7ie10fix.js" as the command line. Select Visible execution with user rights. As an optional step you can select Evaluate the process's exit code, set the value to 0 and use completed successfully. Save the job template and assign it your Windows 7 machines.

 

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

Compatibility Issue with SiteKiosk and IE10 on Windows 7 Resolved

We just released SiteKiosk 8.7 which fixes a bug that occurs when SiteKiosk is used on a Windows 7 system with Internet Explorer 10. Under the restricted SiteKiosk user the SiteKiosk browser may not be able to start properly because of problems with the new Webcache folder introduced by IE10.

You can download SiteKiosk 8.7 from here.

A list of all new features and bug fixes can be found here.

 

It is recommended to upgrade to SiteKiosk 8.7. Users who for whatever reason do not want to upgrade should not install Internet Explorer 10 on Windows 7 systems. Microsoft provides a toolkit to prevent systems from automatically receiving the IE10: http://www.microsoft.com/en-us/download/details.aspx?id=36512.

 

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

 

Please note that Windows 8 with IE10 was not affected.

Compatibility Issue with SiteKiosk and IE10 on Windows 7

We are currently investigating a SiteKiosk startup issue that occurs when SiteKiosk is used on a Windows 7 system with Internet Explorer 10. Under the restricted SiteKiosk user the SiteKiosk browser may not be able to start properly because of problems with the new Webcache folder introduced by IE10.

 

It is recommended to not upgrade to Internet Explorer 10 on Windows 7 systems. Microsoft provides a toolkit to prevent systems from automatically receiving the IE10: http://www.microsoft.com/en-us/download/details.aspx?id=36512.

 

We are working on this issue and try to resolve it as soon as possible.

People who are already affected and experience a loop during SiteKiosk startup can use the instructions from this FAQ to reset the system: http://www.provisio.com/en-US/CustomerSupportCenter/ArticleDetails.aspx?ArticleID=364.

 

Please note that Windows 8 with IE10 is not affected.

Changing the User Agent of the SiteKiosk Browser

The user agent string is used to identify the browser with which a client contacts a server. This information can be utilized to decide what kind of content is delivered to the client in return, to make sure the browser receives data that is optimized for exactly that type of browser. 

SiteKiosk uses the public WebBrowser control of the Microsoft Internet Explorer installed on the system. This means that SiteKiosk identifies itself with the same user agent string as the IE. When a standard configuration is used SiteKiosk will add SiteKiosk Version Number at the end of the user agent string, e.g. SiteKiosk 8.6.1251. A full user agent string under SiteKiosk will look like this:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SiteKiosk 8.6 Build 1251)

Adding SiteKiosk to the user agent can be used for example to let a server deliver SiteKiosk Object Model code to a client. You can deactivate this behaviour in the SiteKiosk configuration and you can also add your own identifiers. You can find more information on this topic here: http://www.provisio.com/helpconsole/SiteKiosk%20Help/en-US/default.htm?advanced_settings.htm#three.

Ideally the above means that your client browser receives the content it is supposed to display in the most suitable form. If a kiosk project is created from scratch, the content can be optimized to fit the kiosk. Even in projects where content has already been created, it will usually run without modifications on the kiosk, because the content has already been designed for usage in a standard browser like IE.

In some cases though, it might come in handy if your browser could pose as something completely different, for example in a kiosk project where touchscreens should be used. The web pages that should be displayed are already existing in a version for normal browsers and in a version for mobile phones. The mobile phone version would fit perfectly but the server dynamically delivers its content based on the user agent. This means on a normal Windows system you would get the version for standard desktop browsers and not the version for mobile phones. The solution is to completely change the user agent string to one of a mobile phone.

Microsoft already provides this option by means of editing the Windows registry using the registry editor (regedit.exe). Note that changing the registry is always done at your own risk. Making the browser pose as another may also cause script errors or corrupted page layouts. You should carefully experiment with the values described next before applying it to live systems.

The registry key we will have a look at is for the Internet Explorer, but as SiteKiosk is based on the Internet Explorer it also uses it. That means changing the key will change the behaviour for IE and SiteKiosk. A detailed article on the topic of the user agent string on Windows systems can be found here: http://msdn.microsoft.com/en-us/library/ms537503%28v=vs.85%29.aspx. The registry key can be found at two different locations in the Windows registry.

One location is under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Note: on a 64-Bit system the location is slightly different

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key changes the behaviour for all users on the system.

The other location is under

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key only changes the behaviour for the current user. This means to edit this key you must be logged in with the user you want to change the behaviour for.

On most systems the above key only contains the default value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Default). For the desired effect we need to add two additional string values (unless they are already there). One is called Platform and the other Version. As an example we will add the following data to Platform (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Platform)

Linux; U; Android 4.0.4;

and the following data to Version (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Version)

AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

These are values an Android smartphone uses. When the changes are done, we can see the effect by opening the SiteKiosk browser (or IE, as both are using that registry key) and going to www.nytimes.com. With the changes we will be directly transferred to the mobile version of the page. The SiteKiosk user string now looks like this:

Mozilla/5.0 (compatible; AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30; Linux; U; Android 4.0.4;; Trident/5.0; SiteKiosk 8.6 Build 1251)

If the above workaround is suitable for your project and you want to spare yourself the hassle of manually editing the registry on all your kiosk systems, you can use the SiteKiosk ProgramPatcher tool to automatically apply the registry changes.

Starting the SiteKiosk File Manager from a Link

The SiteKiosk file manager is usually started from the Start button in the task manager or the programs page. But it can be handy to start the file manager from a link or button link, especially when using the SiteKiosk Portal Startpage.

The file manager is built using HTML, but because of its capabilities it is hosted in a special dialog window. As a consequence just starting the selector.html, which is the base file for the file manager, is not an option. You can of course edit the code of the Portal Startpage, but there is a much simpler approach to it. We will just create a simple html page that will take care of opening the file manager. You can either put the file on the local machine (recommended location: ..\SiteKiosk\html\) or a web server and then create a new link in the settings of the Portal Startpage that uses this page.

Our example page will consist of two methods. The first one is not really required to start the file manager, but it will make the process more complete. It basically checks if SiteKiosk payment options are used and if they apply to starting the file manager. If that should be the case the process of opening the file manager will be aborted and the SiteKiosk payment information dialog shown. More information about this part of the code is available here. Now this is what the first method looks like:

function OpenMediaWindow()
{
	try
	{
		var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
		if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
		{
			OpenIntWindow();
		}
		else
		{
			SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
		}
	}
	catch (e)
	{
		OpenIntWindow();
	}
}

As you can see in the above code, it tries to open another method named OpenIntWindow once the prerequisites are met (or in case of an error, when it goes to the catch part). The OpenIntWindow method deals with opening the actual file manager window. It looks like this:

function OpenIntWindow()
{
	var WS_OVERLAPPED = 0x00000000;
	var WS_MAXIMIZEBOX = 0x00010000;
	var WS_MINIMIZEBOX = 0x00020000;
	var WS_THICKFRAME = 0x00040000;
	var WS_SYSMENU = 0x00080000;
	var WS_BORDER = 0x00800000;
	var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
	var WS_MAXIMIZE = 0x01000000;
	var WS_MINIMIZE = 0x20000000;
	var WS_POPUP = 0x80000000;
	var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
	var WS_EX_TOOLWINDOW = 0x00000080;

	var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
	mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
	mediabox.Styles = 13565952;
	mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
	mediabox.Width = screen.width > 800 ? 1024 : 800;
	mediabox.Height = screen.height > 600 ? 700 : 550;
	mediabox.ExStyles = 0;
	mediabox.Border = true;
	mediabox.Type = "FileManagerDlg";
	mediabox.TopMostWindow = false;
	mediabox.CloseOnInput = false;
	mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
	mediabox.ShowDialog();

	window.close();
}

The first part of the method sets the different window styles used for the file manager dialog. The second part creates an HTML dialog object (SiteKiosk.SiteKioskUI.CreateHTMLDialog();) and assigns window styles, height, width etc. to it. You can learn more about this part here in the SiteKiosk Object Model help. The last line of the method tries to close the window or html page is using now that it has done its purpose of opening the file manager. This will of course only work if the link opened in a new window, which is the default behaviour for the SiteKiosk Portal Startpage.

Now we just put the two methods together and place it in some simple HTML. This is what we get:

<html>
	<script type='text/JScript'>
		window.external.InitScriptInterface();

		function OpenMediaWindow()
		{
			try
			{
				var lk_SiteCash = SiteKiosk.Plugins("SiteCash");
				if (lk_SiteCash == null || lk_SiteCash == undefined || lk_SiteCash.Enabled && !lk_SiteCash.PayApplications || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || lk_SiteCash.Enabled && lk_SiteCash.CurrentBalance > 0.0 || lk_SiteCash.Enabled && lk_SiteCash.ApplicationPrice == 0.0 || lk_SiteCash.Enabled && lk_SiteCash.AccessStatus || !lk_SiteCash.Enabled)
				{
					OpenIntWindow();
				}
				else
				{
					SiteKiosk.Plugins("SiteCash").ShowPaymentInfoDialog(0, "", false);
				}
			}
			catch (e)
			{
				OpenIntWindow();
			}
		}

		function OpenIntWindow()
		{
			var WS_OVERLAPPED = 0x00000000;
			var WS_MAXIMIZEBOX = 0x00010000;
			var WS_MINIMIZEBOX = 0x00020000;
			var WS_THICKFRAME = 0x00040000;
			var WS_SYSMENU = 0x00080000;
			var WS_BORDER = 0x00800000;
			var WS_CAPTION = 0x00C00000;     // WS_BORDER | WS_DLGFRAME
			var WS_MAXIMIZE = 0x01000000;
			var WS_MINIMIZE = 0x20000000;
			var WS_POPUP = 0x80000000;
			var WS_OVERLAPPEDWINDOW = WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX;
			var WS_EX_TOOLWINDOW = 0x00000080;

			var mediabox = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
			mediabox.URL = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Selector.html";
			mediabox.Styles = 13565952;
			mediabox.Icon = SiteKiosk.SiteKioskDirectory + "skins\\public\\Media\\FileManager\\Img\\Icons\\fms_ico.ico";
			mediabox.Width = screen.width > 800 ? 1024 : 800;
			mediabox.Height = screen.height > 600 ? 700 : 550;
			mediabox.ExStyles = 0;
			mediabox.Border = true;
			mediabox.Type = "FileManagerDlg";
			mediabox.TopMostWindow = false;
			mediabox.CloseOnInput = false;
			mediabox.Parent = SiteKiosk.WindowList.MainWindow.SiteKioskWindow.Window;
			mediabox.ShowDialog();

			window.close();
		}
	</script>
	<body onload="OpenMediaWindow();">
	</body>
</html>

Note the extra line at the beginning of the script part (window.external.InitScriptInterface()). It tells SiteKiosk that SiteKiosk Object Model code follows. If you allowed this page to use such code, it will be executed. Once the page is loaded it calls the first method using onload. The script checks whether payment is required and then opens the file manager (or the payment information dialog).

That's it. The above should help in all cases, where you want to start the file manger from a link/button link. This includes the SiteKiosk Portal Startpage but could even used on any html page, including pages located on the Internet.

Please be aware, that you should activate the file manager in the configuration of SiteKiosk to make full use of this code example.

Manipulating the DOM with the SiteKiosk Object Model

Web pages that are used for a kiosk project are often ones that have been created before the kiosk project started and have not necessarily been created with kiosk usage in mind. In most cases this does not matter. But sometimes the requirements of a kiosk project may ask for special handling if a page is displayed on a kiosk (e.g. change button size). Ideally the web pages are then adapted, but this may not always be possible, e.g. because direct access to edit the pages is not possible.

With the help of the SiteKiosk Object Model pages displayed within the SiteKiosk browser (Internet Explorer engine, for the Chrome variant please have a look here) can be altered by directly editing the DOM of a page. For that you need to look at the source code of a page, e.g. by using the developer tools of IE, Chrome or Firefox, and find the appropriate places that need to be changed.

The following example demonstrates this by changing the Google page to show SiteKiosk as the search term and to use 'Search for SiteKiosk' as the caption of the search button. Copy the code example to Notepad and save it as a .js script file with whatever name you like, e.g. manipulatedom.js. Open the SiteKiosk configuration, go to Start Page & Browser or Browser Design (depending on the SiteKiosk version you are using), click on the Advanced button and add the script as an external script file. Save the configuration, start it with SiteKiosk and go to www.google.com to see the effect.

SiteKiosk.Logfile.OnMessage = OnMessage;
function OnMessage(seq, time, utcoff, awtype, awlevel, facility, text)
{
    if(text.indexOf("Navigation:") !== -1 && text.indexOf("google.") !== -1)
        evtid = SiteKiosk.Scheduler.AddDelayedEvent(1000, ManipulateDOM);
}
 
function ManipulateDOM()
{
    for (var i=1;i<=SiteKiosk.WindowList.Windows.Count;i++)
    {
        try
        {
            if(SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.LocationURL.indexOf("https://www.google.") !== -1)
            {
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('q').item(0).value = "SiteKiosk";
                SiteKiosk.WindowList.Windows(i).SiteKioskWindow.SiteKioskWebBrowser.WebBrowser.Document.getElementsByName('btnK').item(1).value = "Search for SiteKiosk";
            }
        }
        catch(e)
        {
            //SiteKiosk.Logfile.Notification("Editing the DOM failed for window: " + SiteKiosk.WindowList.Windows(i).ItemText); //Debug
        }
    }
}

The for part of the above code goes through all open windows to find the one that shows the Google page and apply the code.

Note that when using the above example you should make sure to take care of local laws, ownership rights, copyright etc. Also note that the above example only works as long as Google does not change the code of their page.