I am responsible for the maintenance and development of some SiteKiosk client machines. Currently, we are running version 6 of the software, and do not have an intention of upgrading in the near future.
I have a demo machine where I can turn on whatever functionality I want to facilitate my debugging, but the embedded browser in SiteKiosk supports a very limited set of functionality. What's more, it enables custom Javascript objects, that prevent me from attempting to view my code in a non-embedded browser.
Anyway, what techniques do you use to code against this browswer?
You can run that software on your development machine and turn off all protection features (window management, keyboard filter, shell replacement etc.), enable the debug window and then using the SiteKiosk.Logfile.Notification() method to print output to the debug window.
Related
I'm interesting in gathering usage metrics for an application that I did not write and have no control over. This is a applicaiton running on Windows.
My plan for this is to register a global windows hook for mouse and keyboards events, and record those events for windows that have pre-determined titles or other identifable attributes.
Using this data, I hope to be able to determine how a user uses the application in question. What buttons they click and when, as well as common workflows. Etc.
Any thoughts on this idea? Are there 3rd party products or libraries that would facilitate this solutions that do not require modification of the existing application?
I assume (hope) this is for something like usability experimentation and not nefarious purposes.
The approach you outlined seems reasonable. The drawbacks of global hooking are:
It's a burden on every process, since your hook code will be injected into every process.
It can run into security barriers. For example, if you're hooking from a medium integrity level app, I don't think you'll be able to hook a high integrity level app. Also, you're essentially creating a keylogger, so don't be surprised if some anti-malware app flags you as possibly spyware.
You may need a 64-bit version and a 32-bit version.
One way to mitigate the impact you have on the machine is to use a more targeted hook: find the particular process you care about, enumerate its threads, and hook only those.
Spy++, a developer tool for tracking Windows messages, does much of what you want, but I'm not sure if you could leverage it for your purpose. I'm not aware of any other tools or frameworks for doing this kind of instrumentation.
We are developing C++ apps (lots of MFC) with Visual Studio 2005 on Windows.
From time to time it happens that our nightly builds and/or unit tests hang because some part of some app or helper tool opens a message box in a corner case that is hit by the build.
Since the automated stuff is run (by a Windows Service) without any desktop session attached, obviously no-one can confirm - or even read - the GUI messages.
Is there any way to have Windows prevent apps from opening dialogs? Or maybe a tool that watches a service session that auto-kills any app that opens a dialog box?
I'm thinking that most cases where apps display unexpected popup-messages, it will end up calling one of the MessageBox* functions from user32.dll and it might be just possible to "magically" have these functions fail for a certain login-session? (Just a wild idea.)
Obviously the "right" fix is to have stuff not opening any dialogs, but with 3rd party tools it ain't always possible and with our tools it would be nicer to have a failing unit test that tells me the test "illegally" opened a message box than have a hanging unit test.
(Side notes: We're using Boost.Test for our unit tests and FinalBuilder for our automatic build scripts.)
Note: Removed original tags [continuous-integration build-automation automated-tests] and rephrased question to be more process centric.
You can load a DLL in each of the processes which puts a hook onto MessageBoxA and MessageBoxW. You can either do this manually or via the Detours library. You can then either have it return straight away without calling the real function or you could even implement some form of logging to notify your CI of the error.
We use AutoIt to automatically dismiss dialogs in our commercial run-as-windows-service application. The concept is described and some sample scripts are available here:
http://www.coretechnologies.com/products/AlwaysUp/AutoIt/
Note that some of the AutoIt functions don't work properly in Session 0 (e.g. WinActivate) but you can usually find alternatives. Be sure to test in Session 0!
I have run into a case where a Windows Form application is being run regularly via a scheduled task on a Windows Server 2003 box. The GUI is, obviously, not being used to take in any user input, so it is at best pointless. But is it also dangerous? Could it cause anything to go pop on the box?
It should not really harm.
You may want to create a standard shortcut to the application then in "properties" select the "Run" -> "Minimized" option.
Don't forget to point the task sceduler to execute the new shortcut rather than the direct application.
The GUI is, obviously, not being used
to take in any user input, so it is at
best pointless.
Just because it doesn't take input doesn't mean it does nothing. While the GUI part of it is probably pointless, the application execution itself may not be.
A Windows Form application being run regularly is the same as any other process being run regularly, and it may have been for whatever reason that the developer of the app wanted a GUI to appear while it was doing its thing or may have had plans to allow users to interrupt the running process through the GUI.
The developer may even be using a GUI control for application execution. A "good" example of this would be using a web rendering control for its DOM processing capabilities.
Could it cause anything to go pop on
the box?
If it doesn't correctly dispose of any resources it uses then yes.
I wouldn't imagine GUI apps are any more notorious than console apps for this, but the fact that someone perhaps unnecessarily used a GUI app (maybe they had only been introduced to WinForms projects) is a strong indicator to check the code and make sure all appropriate resources are being disposed of correctly (think 'using' blocks).
Does anyone know of any tools out there that will let me run and debug a VXML application visually? There are a ton of VXML development tools, but they all require you to build your application within them.
I have an existing application that uses JSPs to generate VXML, and I'm looking for a way to navigate through and debug the rendered VXML in much the same way that Firebug allows one to do this with HTML. I have some proxy-like tools that let me inspect the rendered code as it is sent to the VXML browser, but there's a ton of JS, which makes traversing the code by hand rather difficult.
Has anyone worked with a product that allows for this?
Thanks!
IVR Avenger
There is JigSaw Test suite - has free trial license and reasonably priced.
There is IBM's debugger - part of WebSphere Voice Toolkit.
Many other products have debuggers - a very good summary is here
Disclaimer: I am the development manager for Voiyager (www.voiyager.com), a VoiceXML testing tool. It doesn't meet your criteria nor do I believe it is the type of tool you want, but I thought it was worth mentioning it.
As far as I know, there isn't such a test tool for VoiceXML. In fact there are very few VoiceXML tools on the market and hardly any of them test or analysis. The vendors that created development tools, have all been acquired by other companies. Some of them offered did offer various forms of debugging that were specific to their tool set or stayed at the Dialog (caller input) level. From your question, I'm assuming you need much lower level debugging capabilities.
I think the alternative paths are minimal and somewhat difficult. I believe your primary goal is to debug or rewrite an existing application, but you haven't provided any specific challenges beyond the JavaScript. Some thoughts or approaches that may help:
Isolate the JavaScript and place the code into a unit test harness. That will go a long way to understanding the logic of the application. Any encapsulation of the JavaScript you perform will probably go a long way towards better code maintainability.
Attempt to run the VoiceXML through a translation layer to HTML so you could use FireBug. The largest challenge would involve caller input (ie processing the SRGS grammars). You could probably cheat this by just having the form accept a JSON string the populates the field values. There are tools on the market to test grammars. Depending on the nature of your problems, you could take a simple and light approach and attempt this over just the trouble areas.
Plumb the application with a lot of logging. This can be done through the VoiceXML LOG element, or push the variable space back to the server. By adding intermediate forms, you may be able to provide a dump from each via the VoiceXML Data element.
See if your application will run in one of the open source VoiceXML browsers (not sure of the state of the open source browsers as we've built and bought for our various product lines). If you can get it mostly working, you can use the development debugger to provide some ability to step through the logic. However, it is probably one of the more difficult paths as you'll really need to understand the browser to know when and where to stick your breakpoints and to figure out how to expose the data you want.
Good luck on the challenge. If you find another approach, I would be interested in seeing it posted.
An alternative debug env is to use something like Asterisk with a voicexml browser plugin like the one from http://www.voiceglue.org/ or for a limited licence, i6net.
You can keep all the pieces separate(dynamic html and vxml application in php/jsp/j2ee/, tts processing, and optional asr processing as separate virtual machines with something like virtualbox. If the logic can be kept the same, then it is just a matter of changing the UI based on the channel.
A softphone is all you need to call a minimal asterisk machine, which has the voicexml browser with the url of the vxml in the call plan.
I just used Zend Framework as php is used in this environment, and changed view suffixes(phtml vs vxml) based on the user-agent string.
Flite for tts is fine for debugging, and when your app is ready you can either record phrases, and there was a page on the ubuntu forums with directions for how to increase flite quality with some additional sound files.
Do you have tried Eclipse VTP or InVision Studio?
Eclipse VTP
This is Eclipse plugin. But I feel that it is user-unfriendly a little (of Japanese viewpoint).
InVision Studio *Required create user account*
This is Convergys's IVR tool. It has to edit standard VXML mode. (Unfortunately, It's not exact matching.)
For just debugging vxml, I use Nuance Cafe's VoiceXML checker. It doesn't give you a visual tree or anything, but it's pretty good at spotting syntax errors and is free. I think they might also have more advanced debugging tools if you look into it, but I haven't had the need. (Note: I have no association with them)
http://cafe.bevocal.com/tools/vxmlchecker/vxmlchecker.jsp
I'm looking for the same problem that most of the links are down. I found a document where they propose an open source solution, which works as a plugin for Asterisk (https://www.researchgate.net/publication/228873959_Open_Source_VoiceXML_Interpreter_over_Asterisk_for_Use_in_IVR_Applications) and is available at https://sourceforge.net/projects/voxy/
I would like to know if there are current options to create a VXML structure graphically, like the next image.
I would like to automate a windows app that comes only with as a GUI app (no support for command-line). The automation itself is relatively straightforward with AutoIt.
Yet, I am wondering, is-it possible to launch the Windows App from with a windows service (that would simply call the AutoIt script)?
Even if Auto-it can work with UAC, you will most likely run into Session Isolation troubles - i.e services and desktop don't mix and send messages to each other, unless explicitely coded to pass through it.
So it's possible, but it's not a piece of cake either.
You probably want to look at : Launching a .Net winforms application interactively from a service
While not at all advised because of complications associated with Session 0 isolation in the latest versions of Windows, AutoIt scripts can certainly be invoked from a Windows Service. Please see this page for a few sample scripts that work as expected when called from a Windows Service.
Unfortunately though, not all of the AutoIt functions seem to work in Session 0. We ran into trouble with the "Win*" routines (WinActivate, WinExists) so you should probably avoid those if you can. And since the documentation does not highlight the problematic functions be sure test thoroughly!