As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am planning to automate some of the functionality of the GUI developed in Microsoft Visual C#.
I am new to Automation with GUI. Would be glad if you share your experience regarding GUI Automation and some of the tools available for the automation.
I plan to develop some programms / scripts in order to realise some of the functionality of the GUI
For automating Windows OS itself, the free AutoIT uses a BASIC type syntax for automation. It is not open source but development is continuing on AutoHotkey, which is open source. Either of these two can be used for Windows GUI Automation without much effort.
I think Microsoft would suggest you use Windows PowerShell, a task automation framework with support for WMI and COM for local and remote computers. Powershell is free. See this guide on performing Windows® UI automation tasks.
You tagged this question with Windows, Shell and Automation. None of these suggestions I made use C#, although AutoHotkey has community support for C# and Powershell is a .NET scripting/programming language.
I've recently done a research on exactly the same topic. I haven't found an ideal tool. Here are the tools I looked at:
QTP. This is the most famous, and so, you can find most answers to your questions in web. It supports function library, object repository, and various technologies. Developing scripts in QTP is slow because of different factors. Licenses cost big $$$. Uses VBscript (pah!)
Coded UI Test. It is a part of Visual Studio 2010 Premium and Ultimate editions. Also costs $$$. Provides function library and object repository features. You'll need some understanding of programming. Uses C# for developing tests (VB as an alt). Microsoft strictly recommends using their recorder to generate tests. Although, if you have some experience in automation, you understand, that using a recorder only is impossible for developing good tests. So you'll need to get into details of the generated code. And it generates a LOT of code. Anyway, it's nice.
Ruby + AutoIt. Costs 0$. I like using Ruby+Rspec+Watir for automating web interface. Very customizable, fast in learning, developing, and executing. Although, couldn't make Ruby+Rspec work with .NET good enough. I tried to use AutoIt to access WindowsForms, but it was very hard to debug and search why something doesn't work.
Ranorex. I didn't look at it much. It seems nice, works similar to QTP, costs $$$. I didn't have time to work with it more closely, and decided not to use it, because I didn't know what problem could arise during real automation (and I already had a QTP license).
I have had some success with the free, open source White. It's support is limited, but the docs have a good guidance section so you'll know pretty quickly it's right for you.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm using Sikuli for Screen automation. i.e for clicking of GUI elements according to their appearance on the screen. This works all right, but Sikuli has one major disadvantage for me:
Slow start-up for each script (because the whole JVM is loaded each time).
Further more on Sikuli is not much development happening since last year, so I am looking for a replacement automation tool. The big ticket I need is screen awareness: The tool has to "look" for certain UI elements on the screen, than move the mouse there and issue a click.
Any suggestion for a faster and maybe better maintained tool than Sikuli?
If you want to automate anything under Windows, I would recommend you Automa - new lightweight GUI automation tool. It simply "finds" UI elements - all you need to do is to provide their names as human user would see them. And it's actually easier to use than Sikuli - you don't have take any screenshots. For instance, if you want to automatically sign in to Windows Live Messenger, you can run the following script:
start("messenger")
write("my.email#domain.com", into="Email address")
write("secret", into="Password")
click("Sign in")
or, similarly, in order to type in credentials and automatically log in to Facebook, all you need to do is execute the following commands:
start("firefox")
write("facebook.com", into="Location")
press(ENTER)
write("my.email#domain.com", into="Email or Phone")
write("secret", into="Password")
click("Log in")
The tool works on most Windows applications (including web browsers), no matter what technology they are written in. It's written in Python and can be used from within any Python application through importable api library.
About Automa vs Sikuli: Automa is as high-level as Sikuli, but does not require screenshots. This has several advantages:
Automa scripts are easier to store in a version control system.
Automa scripts being purely text based makes them easier to maintain: Imagine a label changing somewhere. This label might appear in several Sikuli screenshots, which you will then have to re-take. With Automa, all you have to do is a simple search-and-replace across files.
It is more stable with respect to changes in the user interface - imagine a colour changing or a button moving by just a few pixels.
Other nice features such as being able to write the scripts/tests before the application exists - you can always write a script saying click "here", type this, click "there", already from the spec of a feature/program. With screenshots that isn't possible.
Disclosure: I work on Automa.
Are you looking to automate WinForms applications or WPF applications? If you're looking at WPF I can recommend Telerik's free Testing Framework. (Disclosure: I am the Test Studio evangelist for Telerik.)
The testing framework (or the full Test Studio product) work very well with WPF as the scripts/tests are element based, not positional.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Someone told me to use MFC,but it seems that MFC will be dead,although its not already...
so if i want to learn windows programming now, which one should i choose? thx.
I encourage you to learn C#, personally is one of the best programming languages for windows nowadays (personal opinion)
If you want to go to the raw Win32API (Which I think you will learn the most and a must-have for your bookshelf)... Charles Petzold's Bible is a must-have... MFC, ATL, C# Winforms are all basically wrappers for the true API architecture using nice properties/events....
If you really want to learn windows programming, start with Petzold's Programming Windows book. You'll get a good understanding of how Windows actually works, which is invaluable when dealing with the more abstracted frameworks.
Then skip over to Windows Forms or WPF. MFC isn't worth the headache.
If you are going to program at the windows api level, you would be better off using something like Qt.
learn plain win32 API not waste your time on MFC ... that is my opinion
I'm with Andres on this one, learn C#.
Additionally you might consider working with java some. There is a huge knowledge base there and in my experience it and C# cross over a lot in syntax and form.
If you are looking for problems consider Project Euler or Programming Praxis
If your goal is to learn the Windows API, MFC isn't a bad place to start. It's a really thin wrapper around the API, nearly transparent in most cases. Perhaps the biggest difference is in the message handling mechanism. In MFC you use macros to generate a table of message handling functions, and many messages get rerouted automatically from parent to child or vice versa. In a raw API program you'll typically see a message loop with a huge switch statement, and it all gets handled in one place.
Depends on the type of application you want to create? The latest forms-based programming is WPF... that is the latest and greatest, but Windows Forms programming is also an option too (there's a lot leveraged in this still).
HTH.
Depends, like everything in the IT world depends of what you need.
But C# or Java is a good start!.
WPF or WinForms with C#.
With WPF you can create very flexible GUIs, WinForms is more traditional.
Try Expression Blend for creating GUI (WPF) and Visual Studio for coding :)
Well it depends on what you want to do. Are you new to programming in general? If so then I would suggest picking up a good programming book or going to a college and enrolling in a CS degree program.
If you already know how to program and just want to write windows programs you have several options. Which one you pick depends on what you want to do and who your target audience is.
Win32 API - The lowest level you can get. It's OLD OLD OLD school C code, but you can write small fast good looking programs. You have to do pretty much everything yourself. The Win32 API is pretty complicated and you have to know the ins and outs to write the best code possible.
MFC (Microsoft Foundation Classes) - Takes the Win32 API and encapsulates it in C++ classes. It's again OLD OLD school but has recently been upgraded from MS with the new 2008 feature pack so it's far from dead.
.NET (C#, VB) - The brand spanking new stuff from MS. It's incredibly easy to write code and create programs. However it does hide all the lower level stuff from you so you just write C# or whatever and it always works.
And of course you can always write in Delphi, Qt, WxWidgets but these are simply wrappers for the win32 API.
As far as my personal choice goes it depends on what I'm doing. At my job I write C# because the hardware/software is under my control. I know what version of the framework is going to be installed, how much RAM, hard disk space, etc. For my own projects I create I almost always use MFC. It hides the nastiness of the Win32 API and gives me C++ power. Would I prefer to make everything .net, absolutely but I've found not a lot of people have the .net framework installed so I was severely limiting my user base.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Background: I'm a windows developer at MegaCorp(tm) and I am getting new hardware soon.
Question: Are there best practices around setting up my developer software installs?
Details: I've got my main IDE (Visual Studio/SQL Management Studio), but there are also tools that I'm testing out, additional tools I can't live without, and future accomodations.
All my code is stored on a remote server in SourceSafe so I don't need to really accommodate for that, but I'll regularly jump into perl/python/php for separate/side tasks.
The only advice I can give you is set up your machine in a way you need it and you can work with and then save an image so that you can return to that state easily.
Also, don't forget to go and get all your SysInternals goodies. Oh, also remember to export your rss feeds before you upgrade.
You should also install the Windows SDK (which usually doesn't come with VS), as there are many useful tools there that can help during development.
If you plan to use .NET, look into Reflector and LINQPad.
If you plan to use ASP.NET or do any web development at all, look into Fiddler and Firebug
Use a VM image, then the project has a VM image that is version controlled.
Tools and OS are recoverable years later.
Your name will shine on asa voice of sanity and configuration management.
Get rid of SourceSafe
Seriously, don't store anything in SourceSafe. There are many other, better Version Management Systems out there. What's wrong with SourceSafe? I strongly urge you to consider reading the following posts:
http://www.codinghorror.com/blog/archives/000660.html
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html
Especially the last one - it goes into lots of detail about the problems with VisualSourceSafe. What should you use instead? Wikipedia has a great comparison of many different Version Management Systems for you to compare. You can look here to find out which ones integrate nicely with Visual Studio.
vim - VI Improved
Beyond Compare - best diff tool.
If you use multiple machines (like
one for dev one for test)
Synergy is invaluable.
If you occasionally need to edit
icons Paint.NET is pretty good.
As everyone else says kill source safe.
I have to agree regarding SourceSafe, whether or not you have the ability to opt-out of using it or not will obviously affect your ability to addopt a new SCM tool but if you can I highly recommenf the free VisualSVN Server for managing subversion and / or hosting repositories.
If you are prepared to pay for the licence you can also buy the VisualSVN plugin for visual studio, as a student I can't afford that but I have used AnkhSVN which integrates with VS through the source control provider APIs providing a nice native looking interface in VS 08
Other tools I can't live without:
TestDriven.NET
DocProject for easy generation of MSDN-style code documentation. I believe it uses sandcastle to do the real work but sandcastle itself is difficult to use and this is the most sane UI over it I've seen and managed to get working without massive amounts of work.
Paint.NET for graphics work
TortoiseSVN is another really good SVN client that I use for doing things like merging to trunk because I am more familiar with the interface and I think it's nicer than AnkhSVN in some areas
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When it comes to scripting the Mac, are there alternatives to Applescript? Its API seems awesome, but the language itself, from what I've read so far, seems aimed more at non-programmers.
Insights into this would be greatly helpful.
(At the moment, I'm thinking of writing a tiling window manager for the Mac.
Yes, I know some exist, but this will be open source.
Yes, I know of Xmonad, but it only does X11 windows.)
Thanks!
When it comes to scripting the Mac, are there alternatives to Applescript?
Depends what you want to do. If you want to send Apple events to other applications, yes; for running scripts from OSA-aware applications (Mail rules, folder actions, etc.), not really.
The best technical alternative is appscript (my baby), which is available for Python, Ruby and Objective-C on 10.4+. (There's also a MacRuby version, but I've yet to do a public release of that.) Feature-wise appscript's slightly better than AppleScript and its application compatibility is very nearly as good. Third-party project, so you'll need to install it yourself (but that's easy enough as long as you've got Xcode) and MIT licensed so you can redistribute it as needed (e.g. included in your application bundle). Fairly decent tool and documentation support, including an online book by Matt Neuburg, with mailing list support for the Python and Ruby versions and direct email support for the others.
The 'official' alternative is Apple's Scripting Bridge. The API looks very Cocoa-like, but that's really just a lot of smoke and mirrors which ultimately makes it less capable than AppleScript and significantly more prone to application compatibility problems (and tricky to troubleshoot when it does go wrong). Tool, documentation and community support is not so great either (appscript's is better; AppleScript's is better still). SB's main advantage is that it's included in 10.5+ so requires no additional installation to use. I wouldn't recommend it for heavy-duty automation work due to its technical shortcomings, but for modest automation tasks involving obliging apps it may suffice.
Other bridges do exist (e.g. Perl's Mac::Glue, RubyOSA), but they are not as capable, popular and/or actively supported.
All that said, if you want to do any serious application scripting, you will still have to learn AppleScript as that's where you'll find the vast bulk of literature, sample scripts and community expertise. All of which you will need, since the great majority of scriptable applications are notoriously under-documented.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to implement an "automatic update" system for a windows application.
Right now I'm semi-manually creating an "appcast" which my program checks, and notifies the user that a new version is available. (I'm using
NSIS for my installers).
Is there software that I can use that will handle the "automatic" part of the updates, perhaps similar to Sparkle on the mac? Any issues/pitfalls that I should be aware of?
There's now a Windows port of Sparkle, see http://winsparkle.org.
There is no solution quite as smooth as Sparkle (that I know of).
If you need an easy means of deployment and updating applications, ClickOnce is an option. Unfortunately, it's inflexible (e.g., no per-machine installation instead of per-user), opaque (you have very little influence and clarity and control over how its deployment actually works) and non-standard (the paths it stores the installed app in are unlike anything else on Windows).
Much closer to what you're asking would be ClickThrough, a side project of WiX, but I'm not sure it's still in development (if it is, they should be clearer about that…) — and it would use MSI in any case, not NSIS.
You're likely best off rolling something on your own. I'd love to see a Sparkle-like project for Windows, but nobody seems to have given it a shot thus far.
Google Chrome auto-update is based on Omaha:
http://code.google.com/p/omaha/
Their overview has a great section on why it was needed:
The browser typically prompted the user with a long series of techy, confusing and scary dialogs all trying to convince the user not to install. Then the user was prompted with a wizard filled with choices that they did not need to or know how to decide amongst. These factors combined to form a bad user experience and large drop-off during the app installation process
It's a good idea to use a third-party solution, cause autoupdates can be a pain, especially with Windows Vista/7 (UAC). For what it's worth, the product my company uses is AutoUpdate+ and it seems to work fairly well.
For .NET, a while back Microsoft Patterns + Practices published the Application Updater Block. This was (to my mind) rather overblown and over-engineered, but did the job quite well.
In essence it used a "stub loader" to check a manifest and a Web service to see if a later version of the program than the one installed was available, then used the BITS background downloader technology to download a new version if one was available on the server.
Once the new version was downloaded and installed (with .NET this is as simple as an xcopy to the relevant folder), the application would update the manifest. The next time the program was loaded the new version would be launched.
While the Patterns + Practices code is .NET specific, there's nothing there that couldn't be copied for a non-.NET application, especially if you have the ability to silently run the install process in the background.
If your application is written in .Net, you could try ClickOnce. However, it's difficult to perform administrative or custom actions during install using this approach.
wyUpdate looks really nice. See video here:
http://wyday.com/wybuild/help/automatic-updates/
For .NET applications you might want to have a look at NetSparkle, a Sparkle variant for .NET programs. It is pretty new (from 2011) and developed actively.
Just came here from an answer to my own question on the same subject - I mention one other updating solution in my question. It uses a stub loader, and an xml file to point to the latest executable.