Hi all I used Selenium some time ago to create a program to carry out automated actions on a website I enjoy using.
I managed to use Selenium to do what I wanted before without much trouble the only issue I had was using it in the background.
I couldn't use it without it effecting other things I was doing on the PC, I did think of using virtual machines but I would like to try and avoid this.
Last night I was playing around with the WebBrowser class in C# and its nice but limited, I like how it was self contained within the windows form application so this is what I am looking for.
Dose anyone know the best way integrating a visual representation of a browser within a windows form application but still allow me to mimic key entry etc but would run in the background.
I have heard of things like WaitN, GekoFX, MozNet etc but from what I read I am not sure any of these would work.
In general, when you are attempting to automate a web page using a browser, you have two options for simulating user events. You can either simulate them via JavaScript, or you can use OS-level mechanisms (so-called "native events") for simulating mouse and keyboard events. Both approaches have their pitfalls.
Simulated events using JavaScript only would probably allow the window being automated to remain in the background, without system focus, while carrying out the tasks you desire. Selenium RC used this method, and Selenium WebDriver offers the ability to use simulated events for Firefox and IE. However, there are some drawbacks to this approach. Simulated events may lack the fidelity and accuracy you require. For example, "drop-down menus" on a page that work via the CSS :hover pseudoselector cannot be triggered via JavaScript, so this approach is doomed to failure in these cases. Additionally, since you're using JavaScript, you're restricted to the JavaScript sandbox, which means that cross-domain frames and the like may be strictly out of bounds.
Native events, on the other hand, are far more closely representational of a user's actual mouse and keyboard operations. In general, they'll allow the correct events to fire on the web page, and in the correct order, without you having to guess which events to fire on which elements. The downside to using them is that to implement them correctly, the window being automated must have the system focus to receive the events properly. You can attempt to hack around this using the SendMessage API if you're on Windows, but this is the Wrong Thing to do, as it's error prone and absolutely not guaranteed to work. The correct way to use native events is to use the SendInput API, but that API sends the input to the window with the system focus. WebDriver defaults to using native events for simulating user input, but it defaults to the flawed SendMessage approach. For IE, at least, it does provide an option to use the more correct SendInput approach.
If you're dead set on not requiring a browser window in the foreground, you really ought to look into a headless option. PhantomJS is a great option, and WebDriver also has a driver for it, which means you can still write your automation code in C#. Otherwise, you're limited to one of the other approaches outlined above.
Does the application need to be hosted within a window?
I have used selenium, Watin for automation, unfortunately they do interfere with what you are doing and I have not managed to find a way around this.
I have used the .Net WebBrowser class too, but for automating I am not sure without testing if it is a fully featured IE, with regard to JavaScript running inside it. I think it does execute JavaScripts though, but you would need to check.
If you do not need to see what is happening there are headless options available too, even for Selenium I think:
Is it possible to hide the browser in Selenium RC?
Here is a list of headless versions if that is viable for you:
https://gist.github.com/evandrix/3694955
From https://learn.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2022
Visual Studio 2019 is the last version where Coded UI Test will be
fully available. We recommend using Playwright for testing web apps
and Appium with WinAppDriver for testing desktop and UWP apps.
Consider Xamarin.UITest for testing iOS and Android apps using the
NUnit test framework. To reduce the impact on users some minimum
support will still be available in Visual Studio 2022 Preview 4 or
later.
Related
I have to create a webbroswer in wpf that supports all the sites and scripts and play video , I have created but some site got crashed and not supporting .
Please provide solution.
What you ran into are probably error dialogs caused by JavaScript script errors. WPF WebBrowser control currently doesn't support disabling these dialogs and ignoring the errors. The WebBrowser control is based on Internet Explorer core and will have a hard time dealing with broken JavaScript, webpages will also sometimes report the web browser as old and inform the visitor about it, like FlipKart does.
One solution is to use WindowsFormsHost and host a Windows Forms equivalent - WebBrowser control - in it. The WF WebBrowser offers a property called SupressScriptErrors, which is not implemented by the WPF WebBrowser. That will hide the error dialogs for you, but you will still occasionaly receive a warning from the website saying they don't support the web browser used. That is out of your control unless you want to take a route of hacking the control to send a different User-Agent string and that will only fool broken UA detection, feature detection will still fail for things like HTML5 video, WebRTC and the like. More on this here.
You can also choose to embed Gecko (Firefox rendering engine) or Chromium. see here for more information on embedding alternative rendering cores as an alternative to IE COM wrapper offered by the framework.
Edit: this is also a possible solution, as it would seem. You will have to test it for yourself, though. I expect it to have less overhead than the WindowsFromHost element and although this uses reflection to develop against implementation, not interface, my opinion is it's safe to say the underlaying API in unlikely to change.
I'm trying to automate a hidden .NET application, with another .NET application (written in c#) using the easiest way possible. It's NOT for testing purposes, it's a way to fulfill the lack of scripting for this application.
I already tried white framework, but there is one major problems with it: the way it's working. It's slow and it's not working on hidden windows and controls (like the winAPI does). Whats more, when "clicking" white moves the mouse, brings it's targeted window to the front and so on.
I was also thinking about using a user32.dll wrapper, because the way it's handling it's target is what I need, but I've red it's not working with .NET applications. It also would be a problem working with it, because my targeted application got 5 button labeled "...", and would be really hard finding 2 of them I need. I also would like to use the controls .NET id (the name the developer gave to it's controls when designing the GUI).
BTW, my targeted application is MeGUI if that helps. We do a lot of video encoding and a tool like this would help us a lot. I need the MeGUI to be hidden, because I'm the only programmer, others using my tool shouldn't see what happens in the background, not to talk about the many windows popping all around.
You can add a reference to the exe from your project and then create an AppDomain to run its main method. From there, it should be possible to queue delegates to its main thread's loop. With a bit of reflection, you could have those delegates invoke the click events and whatnot directly.
I've never attempted this approach, but it should work.
You should try Stephens idea instead of scripting a hidden app. A .NET Windows Forms App (EXE) is still a .NET Assembly and that means you can use that the same way as a DLL, just add a reference and use the public classes.
If you still want to try some scripting, take a look on the "Microsoft UI Automation" API and the "System.Windows.Automation" namespace.
Nice article here: http://msdn.microsoft.com/en-us/magazine/cc163465.aspx
MSDN Doc: http://msdn.microsoft.com/en-us/library/system.windows.automation.aspx
I think it's possible to somehow hook with the windows environment (specifically explorer.exe) and trigger specific things, for example launching control panel and using it as if I had mouse (meaning I'm clicking the interface from the code).
Basically what I'm trying to do is automate some redundant tasks I do often, just I don't know how it's done, or even how it's called. Anyone can point me in right direction?
Thanks!
Forget about "automated clicking". GUI tools are just front-ends to control the system. You can control the system like they do, it will be much easier.
Huge possibilities can give you Microsoft Management Console. Each "snap-in" can be accessed via COM model. Some of them have GUI front-ends, find and fire "*.msc" files (somewhere in Windows directory) to try them.
There is many command line tools i.e. "net" command has huge abilities related to networking.
PowerShell may be a better choice instead of C# or C++, it's designed for task automation. You can easily use COM, .NET, MMC ...
Windows Explorer has a COM object model that you can call from both C# and C++. (Most of the examples on MSDN are in Javascript or VBScript, which I guess aren't your languages of choice, but they demonstrate that the API is straightforward to call.)
AutoHotKey is a scripting environment specifically designed for this sort of task
If you want mostly to launch control panel you can do using RunDll32 interface existing in the most control panel applets. See http://www.osattack.com/windows-7/huge-list-of-windows-7-shell-commands/ , http://support.microsoft.com/kb/167012 or http://www.winvistaclub.com/t57.html for example. For the corresponding API see http://support.microsoft.com/kb/164787.
Another option is usage of control.exe (see http://msdn.microsoft.com/en-us/library/cc144191.aspx and http://vlaurie.com/computers2/Articles/control.htm).
If you google more you will find much more examples which you can to automate a lot of things without using of some general ways to automate GUI.
At more or less the lowest level within Win32, you can use the SendMessage() API to send raw click messages to windows of interest. This will rely on a lot of intrusive knowledge about the apps you intend to drive. However, you could easily implement a "click recorder" that could replay click sequences captured from user interaction.
we are tasked with basically emulating a browser to fetch webpages, looking to automate tests on different web pages. This will be used for (ideally) console-ish applications that run in the background and generate reports.
We tried going with .NET and the WatiN library, but it was built on a Marshalled IE, and so it lacked many features that we hacked in with calls to unmanaged native code, but at the end of the day IE is not thread safe nor process safe, and many of the needed features could only be implemented by changing registry values and it was just terribly unflexible.
Proxy support
JavaScript support- we have to be able to parse the actual DOM after any javascript has executed (and hopefully an event is raised to handle any ajax calls)
Ability to save entire contents of page including images FROM THE loaded page's CACHE to a separate location
ability to clear cookies/cache, get the cookies/cache, etc.
Ability to set headers and alter post data for any browser call
Process and/or thread safe would be ideal
And for the love of drogs, an API that isn't completely cryptic
Languages acceptable C++, C#, Python, anything that can be a simple little background application that is somewhat bearable and doesn't have a completely "untraditional" syntax like Ruby.
From my own research, and believe me I am terrible at google searches, I have heard good things about WebKit... would the Qt module QtWebKit handle all these features?
You might try one of these:
http://code.google.com/p/spynner/
http://code.google.com/p/pywebkitgtk/
I know you mentioned you don't like Ruby syntax (neither do I), but I just have to chime in and say that Watir is probably the best thing out there for what you are trying to do.
EDIT: There appears to be a Java counter-part called Watij
I've only been digging into this recently myself, so I couldn't say that this does everything you've listed, but check out GeckoFx.
From the site: GeckoFX is an open-source component which makes it easy to embed Mozilla Gecko (Firefox) into any .NET Windows Forms application. Written in clean, fully commented C#, GeckoFX is the perfect replacement for the default Internet Explorer-based WebBrowser control.
As for my own impressions: it has blown away the default .NET WebBrowser in both performance and stability.
I need JavaScript working almost perfectly in my application that should be able to access web content and let user take a control of it. However, webbrowser component pops new windows in separate instance / application of Internet Explorer and dotBrowser doesn't work with JavaScript properly.
Please, give me some advice - I'd even take some working example and enhance it with function I need it for.
Give a look to GeckoFX, is on open-source component for embedding the Mozilla Gecko (Firefox) in .NET applications.
I could be mistaken, but I believe new windows can be controlled (or at least suppressed) using the Web Browser control in .NET. Have a look at the NewWindow event.
I have had experience embedding both WebKit (Apple Core, used in Chrome) and XULRunner (Gecko) cores in .NET winforms applications. Let me give you some advice:
GeckoFX is your best bet. It is licensed under MPL and it works pretty much out of the box.
Follow the instructions carefully and pull the exact XUL version that is indicated. I would say it works better than the WebBrowser control. There is some talk of a significant delay when loading XUL for the first time but I've found it to be negligible. Branding and the like is fully customizable via external files.
WebKit is embeddable with SwiftDotNet. If all you need is solid javascript performance then this may be an option. If you need to be able to download files, then you have some work cut out for you.
Your downside with both routes is a nasty ~7-8mb overhead, even with compression (although I was able to get 6.5mb with lz compression in NSIS). If you are not creating distributable consumer-facing software then this may not be a problem for you.