AutoIt send command in IE in Kiosk mode - autoit

I'm really new to coding (like very new) but I managed to do what I wanted with AutoIt. That means: Launch IE automatically on a certain web page in Kiosk mode. So far so good.
But before I was not in kiosk mode the input sent worked but now I can't find the problem why it does not work any more.
ShellExecuteWait("c:\Program Files\Internet Explorer\iexplore.exe", "-k http://website.com", "")
WinWaitActive("website.com  Login - Internet Explorer","")
Send("login{TAB}password{ENTER}")
The website is launched, I'm directly in the login box, but nothing is typed in it. Any ideas?

Like #Steve said in the comments, you can try to use ControlFocus when the window is shown, then send the credentials.
ShellExecuteWait("c:\Program Files\Internet Explorer\iexplore.exe", "-k http://website.com", "")
; store the returned window handle to use it in the ControlFocus call
Local $hWnd = WinWaitActive("website.com Login - Internet Explorer","")
ControlFocus($hWnd, "", "Edit1")
Send("login{TAB}password{ENTER}")

Related

Bot acts differently in Microsoft Teams

I've deployed my Bot to Webchat, Skype and MS Teams.
In OnTurnAsync method I check, if the user input begins with bnr then I call a specific method.
if (turnContext.Activity.Text.ToLower().StartsWith("bnr"))
{
string msg = RequestHandler.BnrCaller(turnContext.Activity.Text);
await turnContext.SendActivityAsync(msg);
return;
}
It works fine with Skype and Webchat but with teams it does not work 100%, It works just sometimes.
[Edit]
I found out, that it does not work if I copied the input into the input field but when I type it, it works fine!
The Messages coming from the Teams are having a different structure.
The message text begins with the words <at>...</at>.
You need to delete this beginning in a Middleware component, etc.
Try to look at your incoming messages through NGROK at localhost:4040 in your web browser.
So, I found out the issue by dint of app-insights.
I've added a middleware, which logs the request body into app-insights and just realized, that when I copy/paste a message like: "Hello", it would be logged in app-insights as something like this "\r\n\n\rHello\r\n\n\r\n". When I type it, it would be logged just fine.
So I jsut remove these symboles from the request and it works!

Got the "My test app isn't responding right now. Try again soon." error message even a clean start from Google Assistant Simulator

I am still quite new to this topic, so sorry if I didn't provide enough information.
For the first time, I copoed everything from https://developers.google.com/actions/dialogflow/first-app to learn about it, which works great.
After, I tried to create my own one, then at the end, I got this message "My test app isn't responding right now. Try again soon." from https://console.actions.google.com/project/[[PROJECT-ID]]/simulator/.
Therefore, I tried to delete everything and make a complete new start, including all the projects on https://console.actions.google.com/ and https://console.dialogflow.com.
I then copied the exact same thing from https://developers.google.com/actions/dialogflow/first-app again, but this time, I still got "My test app isn't responding right now. Try again soon." from https://console.actions.google.com/project/[[PROJECT-ID]]/simulator/.
I tried to look at firebase log, no error indeed
I tried to use the web demo from the integration tab, everything works (which means the server side code or the connection have no problem) as expected, firebase also logged the request.
I tried to use a different browser (chrome -> firefox) still not working.
Here is the response code from the Google Assistant Simulator (its kinda nothing):
{
"audioResponse": "//NExAARqQ...",
"conversationToken": "GidzaW11bG...",
"response": "My test app isn't responding right now. Try again soon.",
"visualResponse": {
"visualElements": []
}
}
And here is the debug message (yes, its nothing in there, so I'm stuck):
{
"agentToAssistantDebug": {},
"assistantToAgentDebug": {}
}
Any help would be appreciated. Thanks!
In Actions Console..
Go to Develop -> Invocation
Set a display name (Eg: Hello World) and click Save
Go to Test and type "Talk to Hello World"
Fixed the issue for me.
Make sure your Actions on Google project has a name.
I spent almost 2 days scratching my head on this. Just go to Activity controls of the relevant google account (The account that you are using for the simulator) and turn on all those switches (You may leave out Youtube related stuff).
And.....Voila, it works!
Usually, these are turned off for non-personal accounts.
Faced the same issue when I tried to change the language of app to a locale.
Try the following,
Check if the welcome intent and fallback intents have responses and training phrases
All contexts are mapped
Disable and enable testing
At least in my case, I've added 'Suggestions' for an ending scene, like below:
You can see the error on the right side log of 'Test' page:
Fix is to remove 'Suggestions' in ending scene.
I had the exact same issue and after struggling for hours I found the stupid error on my side: In my Dialogflow Agent settings, I accidentally turned on the V2 API. So my firebase function kept complaining about null intent. Hope this help.

PostMessage interferes with user input

I'm trying to send key stroke to an external application in java using jna.
It sends VK_DOWN key, also that application has a shortcut for ctrl+down which makes something very different. My application sends around ~15 down key with 1 sec in between, and if user happens to click CTRL during it while working on a different window, it breaks the application(treats it as ctrl+down).
I checked the keyboard messages via Spy++, compared mine with AutoIt, they are exactly same messages.
ControlSend("window_title", "", "", "{DOWN}")
This AutoIt code works perfect, even if I click ctrl when window is active or inactive, it does not interfere with down key.
My code on the other hand:
User32.INSTANCE.PostMessage(handle, WM_KEYDOWN, wparam, lparamDown);
User32.INSTANCE.PostMessage(handle, WM_KEYUP, wparam, lparamUp);
has exactly same messages, but it doesn't work.
I tried sending control up before sending down key but to no avail.
Spy++ output:
<14335> 00011456 P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 ScanCode:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
<14336> 00011456 P WM_KEYUP nVirtKey:VK_DOWN cRepeat:1 ScanCode:50 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
My ctrl clicks are not even on target application so why does it treat it as such? Should I use a hook?

ShellExecute fails for local html or file URLs

Our company is migrating our help systems over to HTML5 format under Flare. We've also added Topic based access to the help systems using Flare CSHID's on the URI command line for accessing the topic directly, such as index.html#CSHID=GettingStarted to launch the GettingStarted.html help page.
Our apps are written in C++ and leverage the Win32 ShellExecute() function to spawn the default application associated with HTTP to display the help system. We've noticed that ShellExecute() works fine when no hashtag is specified, such as
ShellExecute(NULL, _T("open"), _T("c:\\Help\\index.html"), NULL, NULL, SW_SHOWNORMAL);
This function will launch the default browser associated with viewing HTML pages and in this case, the File:/// protocol handler will kick in, the browser will launch and you will see file:///c:/Help/index.html in the address bar.
However, once you add the # information for the topic, ShellExecute() fails to open the page
ShellExecute(NULL,_T("open"),_T("c:\\Help\\index.html#cshid=GettingStarted"),NULL,NULL,SW_SHOWNORMAL);
If the browser opens at all, you'll be directed to file:///c:/Help/index.html without the #cshid=GettingStarted topic identification.
Note that this is only a problem if the File protocol handler is engaged through ShellExecute(), if the help system lives out on the web, and the Http or Https protocol handler is engaged, everything works great.
For our customers, some of whom are on a private LAN, we cannot always rely on Internet access, so our help systems must ship with the application.
After some back-and-forth with Microsoft's MSDN team, they reviewed the source code to the ShellExecute() call and it was determined that yes, when processing File:/// based URLs in ShellExecute(), the ShellExecute() call will strip off the # and any data it finds after the # before launching the default browser and sending in the HTML page to open. MS's stance is that they do this deliberately to prevent injections into the function.
The solution was to beef up the ShellExecute() call by searching the URL for a # and if one was found, then we would manually launch the default browser with the URL. Here's the pseudocode
void WebDrive_ShellExecute(LPCTSTR szURL)
{
if ( _tcschr(szURL,_T('#')) )
{
//
//Get Default Browser from Registry, then launch it.
//
::RegGetStr(HKCR,_T("HTTP\\Shell\\Open\\Command"),szBrowser);
::CreateProcess ( NULL, szBrowser + _T(" ") + szURL, NULL, NULL, FALSE, 0, NULL, NULL, &sui, &pi);
}
else
ShellExecute(NULL,_T("open"),szURL,NULL,NULL,SW_SHOWNORMAL);
}
Granted there's a bit more to the c++ code, but this general design worked for us.
I tried WebDrive's solution and it didn't really work on Windows 10.
"HTTP\Shell\Open\Command" default value is set to Internet Explorer path, regardless of what my default browser setting. However, for Internet Explorer that solution DOES work.
Process to fetch default browser path on Windows 10 is a bit different (How to determine the Windows default browser (at the top of the start menu)) but even then the solution is not guaranteed to work, depending on the browser. E.g. for me it didn't work with Edge.
To get it to work with Edge I had to add "file:///" to the URL -- but that also makes the URL work with ShellExecute(). So, at least on Windows 10, all I needed to do was this:
ShellExecute(NULL,_T("open"),_T("file:///c:/Help/Default.html#cshid=1648"),NULL,NULL,NULL);
UPDATE:
The above stopped working months ago. What I eventually did was go through temporary file, as described here: https://forums.madcapsoftware.com/viewtopic.php?f=9&t=28376#p130613
Use FindExecutable() to get the default browser and pass the full help file path with its queries (?) and fragments (#) as the lpParameters parameter to ShellExecute(). They won't get stripped off there.
Then handle the case if it is a Store App (most likely Microsoft Edge).
Pseudo C code:
if (FindExecutable(_T("c:\Help\index.html"), NULL, szBrowser)
{
if (szBrowser == _T("C:\WINDOWS\system32\LaunchWinApp.exe"))
{
// default browser is a Windows Store App
szBrowser = _T("shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge");
}
}
else
{
szBrowser = szURL;
szURL = NULL;
}
ShellExecute(NULL, NULL, szBrowser, szURL, NULL, SW_SHOWNORMAL);
I solved the problem without using any method other than ShellExecute in a Qt Application
QString currentpath = QDir::currentPath();
QString url = "/help//html/index.html#current";
QString full_url = "file:///" + currentpath + url;
QByteArray full_url_arr= full_url.toLocal8Bit();
LPCSTR lp = LPCSTR(full_url_arr.constData());
ShellExecute(NULL, "open", lp, NULL, NULL, SW_SHOWNORMAL);

VLC-Player in adobe Air App does not stop/quit

Well i have an adobe air , downloaded from below link.. it is wonderful app..
http://www.adobe.com/devnet/air/flex/articles/air_screenrecording.html
and this works fine. It captures my screen , record audio but it just does not stop or quit as vlc-player.exe continues to run in the task manager.
i tried lots of vlc- commands but it just does not stop once it starts capturing screen video.
I need help on it..
I know this is a old thread, but just in case someone wants to know...
You can't use rc-fake-tty because Windows doesn't support terminal. For Windows, tell VLC to run with only one instance, then send it the quit command as a separate NativeProcess call.
So, in the linked article, change the stopRecording() method to this:
public function stopRecording():void{
var startupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
startupInfo.executable = vlcFile;
var processArgs:Vector.<String> = new Vector.<String>();
processArgs.push("-I");
processArgs.push("rc"); //Remote control
processArgs.push("--one-instance");
processArgs.push("vlc://quit");
startupInfo.arguments = processArgs;
var killSwitch:NativeProcess = new NativeProcess();
killSwitch.start(startupInfo);
}
And make sure to add this:
processArgs.push("--one-instance");
To your initial screen record startupInfo in startRecording() method.
I quit using vlc for the same reason and started to write my recording application using .Net 4, but i am having less performance using c# now.
Edit:
VLC for windows does not support fake rc control so setting rc-fake-tty is useless. As the very last try, i wanna control is via socket. If you got it working this way, please make me informed.

Resources