Powershell/Commandline in Modern UI - powershell

Is there (or is possible) a standard Powershell or commandline in Modern UI in Win 8.x?
It would be pretty nice to have this app "docked" on a part of screen only (for SSH, etc...) and other desktop apps still could be in fullscreen.

You couldn't do this directly. The PowerShell engine isn't available on WinRT. You might be able to do something like create a WinRT app that uses sockets to communicate to a service on the localhost that executes PowerShell for you and returns the results. That would require you to build that service and install it on machines. If this is for a Windows RT device that won't work because only Microsoft can install desktop apps.

Related

Porting a pywinauto script from Windows to X11/Xlib

In my organization, I have been using pywinauto to automate some UI procedures that could not be done using the sole command line interface.
In an effort to move away from windows, I am evaluating the effort to port the UI automation script to a Linux environment (our tool has a Linux version, including a similar GUI).
I have had a look at the python-xlib project. But I have the feeling that it is more a framework to develop native X11 applications rather than perform tests on an existing application (I could not find anything like find_window etc...).
Do you have any advice for an X11 framework to automate UI procedures?
Based on several inputs, I finally came up with the following suggestions:
use pywinauto which has some beta level of Linux support (this support is based on pyatspi2).
use directly pyatspi2 to interact with the widgets if they are exposed. To browse through the exposed widgets of the application you want to automate, you can use accerciser.
finally, many framework exist to use only click + keys + mouse locations and are based on image comparison. There are many around, I have not yet tested any of them.
Finally, since my script is meant to run in a docker environment in CI, I installed Xvfb to run the automation in headless mode, without graphics HW.

REST Server without GUI

I've started working with delphi quite some while ago but I would say I'm still a newbie in all this.
So basically I tried creating REST Server, which can validate license keys. I got in working with Indy, but one thing bothers me. The GUI. The Server shouldn't have any kind of gui so it can work on any OS (Win, Linux, etc). Is there a way to make a REST Server without any GUI/FMX/VCL?
BTW: Working in Delphi 10.2.3 Professional.
Any advice is appreciated.
EDIT: I forgot to mention one thing: the server is supposed to run on an independent Data Center away from any user.
You can create the WebServer as a Windows Service.
You can use DelphiMVCFramework or any other Framework to create it.
With DMVC you can create console application, Windows Service, Linux daemon, Apache module (Windows and Linux) and IIS ISAPI (Windows).
With Intraweb you can also create Services.
Take a look at our mORMot Open Source REST framework, which works on Delphi but also on FPC/Lazarus.
FPC support ensures that you can target Linux with this free compiler. No need to upgrade to a newer version of Delphi Architect, which supports Linux, and is very pricey - and less stable (to my knowledge) since Linux support is quite new.
As you requested, the mORMot REST server has no UI part. You define your services as interface and class - like you do e.g. with DotNet - and you will have full JSON/REST support generated.
mORMot is used on production since years for very high performance and stability, hosted on both Windows and Linux. A version 2 is on its way, which would be even easier to use for new projects.
And you can create a Windows service or Linux daemon without using any third party framework. Delphi include everything you need. However, it is possible that third party framework will facilitate your programming. Don't forget you'll have to learn those third party framework.
Creating a Linux daemon service in Delphi
Creating a Windows Service in Delphi
In both cases, you can use the sample code you've found that make use of TIdTCPServer.

BluePrism runtime inside Citrix desktop

I am looking at an architecture where we have the BluePrism runtime running inside a Citrix Desktop.
I see plenty of articles that talk about processing a Citrix desktop as part of an automation process, but as far as I can see they talk about firing up a Citrix app from within a process. In other words they have a physical laptop that runs the BluePrism runtime, and part of the process requires it to run a citrix desktop, and automate that. I understand that this scenario is problemtic, and requires you to use Surface Automation.
In my case we have a set of physical laptops, and we would like to completely replace these laptops with VMs. So the runtime will be in the same desktop as the target apps.
Question is, does this work, or are we still faced with having to convert all our BluePrism processes to use Surface Automation to get this architecture to work?
This works with VMs and Surface Automation isn't necessary in that case. All your objects will be doing is attach the target apps by calling their runtime process names on the VM desktop, or launch them from the parent (i.e. folder in the root desktop/server) by providing the path in your application model, and then have your BP objects launch attach to them. Surface Auto may be necessary if you are planning to interact with the actual Citrix Receiver (e.g. icons), but not the apps themselves once they are active on the VM desktop. Of course, all this assuming BP will be also on the VM desktop environment.

Controlling Google Chrome via Perl script

I was looking for a way to check for changes in a specific URL provided by the user. I wrote a script that I ran at home that can do that successfully using WWW::Mechanize. The thing is, I need to run it in another computer network that has a group policy that blocks all $mech->get($url) requests (it's not firewall problems, I let Perl through), so I thought I'll try and work around this problem by letting Perl control the web browser.
The computers in the network run Google Chrome and IE8 only and I can't install Firefox due to another policy (thought of using WWW::Mechanize::Firefox). I don't want to invoke IE8 in the script because most of the URLs that will be provided will be of websites that don't work well with it, so that leaves me with Chrome only.
Searching for a module that can do that, I only found AnyEvent::Chromi:
which exposes all of the Chrome Extensions API via a websocket connection.
This doesn't work (the policy probably blocks that websocket as well).
Is there another way to work around this problem/control Chrome from within a Perl script?
Is there another way to work around this problem/control Chrome from
within a Perl script?
WWW::Mechanize::Chrome
Like WWW::Mechanize, this module automates web browsing with a Perl object. Fetching and rendering of web pages is delegated to the Chrome (or Chromium) browser by starting an instance of the browser and controlling it with Chrome DevTools.
You can also do this from scratch without using any CPAN modules.
I tested this on Linux (Ubuntu 16.04, Google Chrome version 53) using Unix Domain (UD)
sockets. Unfortunately, it seems Windows does not have UD sockets, but
it should be possible to do same from Windows using named pipes.
First, make sure google-chrome is running in the background. We will
need to create a Chrome App
that will communicate
with a native host through the native messaging
API. The
native host can be any script that reads messages from its STDIN and
returns replies through its STDOUT. I tested both a Python
script and a Perl script.
Now, in order for a standalone Perl script to communicate with the
Chrome browser, it will send request through a UD socket (created by
the native host) to the native host; the native host will then
forward the request to google-chrome through its standard output
pipe. Then the Chrome App (written in JavaScript)
will receive the request. The Chrome App will use the Chrome
JavaScript APIs to get the requested data and return it to the native
host. Finally, the native host forwards the result through the socket to
the Perl script.
As you can see, there are some details required for setting this up, but I can
confirm that it works on my Linux platform. Please let me know if you need more
details.
Since you mentioned IE8, I'm assuming that you're dealing with a Windows system. And since you mentioned that you had considered WWW:Mechanix::Firefox, it sounds like you are not being restricted to just core modules.
Based on that, the only way that I can think of to automate the Chrome broswer would be to use Win32::GuiTest to control the Chrome browser. If you can figure out how to manually drive your testing using only keyboard input (i.e. no mouse), that would make things easier than trying to figure out the mouse emulation to get the cursor to the correct position for various tasks.
I'm not sure if that's necessarily a route that you will like to use or not. It's just the only way that I can think of to accomplish what you want to do with the restrictions that you have to deal with.

Can winform C# applications run from citrix?

Can winform C# applications run from citrix?
If the application is kept on Citrix server, can it be viewed in windows OS machines?
Will the same be viewable via iPad?
-Karthick
The only real issue I've seen with home-grown .Net apps on Citrix is the occasional problem with code access security.
Yes to all of your questions.
Winform applications can be written in C# and run on Citrix
Once you publish the application it can be run on windows OS via the Citrix client. It will appear that the app is running locally.
Right now there is a client for the iPad available in the app store. Using this you should be able to connect to your apps via Citrix
I don't see why it wouldn't run on Citrix. If the corresponding framework is installed on the Citrix servers, it will run on it.
I don't know about iPad, since I believe it has to be from the App Store, but maybe.
Of course yes to all of your questions, Citrix is only an environment.