Related
I created a Winforms dashboard for my team using Powershell and I've put alot of features into the the thing (a tab that does webscraping, another tab that uses an API, another tab that sends emails, etc) and I just realized that I am unable to run different features simultaneously.
Some of the functions take awhile to actually run (like 1 minute or so) and while one feature is running, the entire winforms application is frozen until it finishes, before users are able to move onto another feature.
Is there a way around this? I know I can't be the only one who's ran into this issue. I want users to be able to run different dashboard functions simultaneously.
All of my code is currently in 1 .PS1 file which has over 1500 lines of code. I was thinking of maybe segmenting it off into different scripts and then having my dashboard call those other scripts once a function is invoked? Although I'm not so sure that would do what I'm looking to accomplish.
Any suggestions would be much appreciated.
I currently have 3 very similar, but slightly different mfc applications, which would normally be opened at the same time as part of their workflow and usage in a Windows environment. I would like to keep them as 3 separate applications, but somehow group them together, under a single UI container to provide more clarity to the user.
I've so far considered using named pipes to send data from two of the applications to the third, the latter one being solely responsible for drawing the GUI (possibly having 3 different tabs at the highest GUI level, one for each application). I got this idea from SergeWautier's answer from this post. After looking into the possibility of doing this, there seems to be a lot of work involved in achieving this.
Is there any other (possibly simpler) way of achieving something similar?
Old answer
I have in the mean time come across the TaskSpace tool, which is the closest thing to what I'm looking for. It's liteware and getting the full functionality (e.g. saving a particular tabbing configuration, which I am most interested in) requires purchasing a licence. What would be really cool would be to restrict the user from adding any other windows apart from the 3 applications and have better control over the titles of the tabs & top-level window. At this point, writing a similar tool to TaskSpace would be the ideal solution.
I've also been playing around with tidytabs. It's not exactly what I want, because it doesn't provide a 'wrapper GUI', but I thought it's worth mentioning here in case it helps someone else.
Update
I've found exactly what I was looking for in Window Tabifier, which is open source and I can modify to fit my needs in accordance with the CPOL Licence provided. Very nicely written code too.
I have four small single-form utility applications that I have written in Delphi (Win32), that every once in awhile I want to use in a way that makes them "feel" as if they are all one application, mostly to make switching back and forth between them super-easy. It would be great, for instance, to be able to insert them as containers inside a TabSheet, or something along those lines.
AppControls makes a neat little component that does something similar with TForm descendents, allowing them to be inserted inside another container in a Delphi application (see acEmbeddedForm http://www.appcontrols.com/appcontrols/overview.html'>here ), but I don't see any way to do this with four separate applications unless I build a fifth application with this end result in mind, and compile in all the forms of the original four applications.
I could also imagine wanting to "contain" or embed some other application as well (say, for instance, Notepad).
Is this possible in Delphi? (all things are possible... <g>)... and if so, would it be super difficult, and require massive amounts of under-the-hood Windows API familiarity?
I'm thinking the respective answers to these are probably yes, and yes, but hoping the answers are yes, and no. Thought I would ask just to be sure. <g>
If I am dreaming here from a programming perspective, and this is way more work than it's worth; any recommendations for utilities that make switching back and forth between a standard set of three or four applications simpler than it normally is in Windows?
You could make your small apps into OLE servers and create a new application that hosts them in one main form. OLE is nicely supported by Delphi, so it should be both fairly easy and not require much API fiddling.
This other SO question could provide some hints. Basically it states that you use SetParent. You could also enumerate over existing windows (such as notepad.exe) using FindWindow and call SetParent on them to reparent under your own.
With regards to embedding programs you don't have control over: I suspect you'll have a lot of trouble trying to do what you're describing, and if it's even possible at all (something I doubt), it would rely on a lot of low-level API calls and general nastiness.
If you wanted to restructure your application somewhat, you could make your four programs into plugins, and create a fifth "host" application that could load any or all of them.
I suggest you take a look at the JEDI plugin system, available for free from http://delphi-jedi.org.
I went with the "make a fifth app" solution when I combined a number of internal apps into a single app with tabs to select between them.
frmShipRef := TfrmShipRef.Create(self);
frmShipRef.Parent := tabShipRef;
frmShipRef.BorderStyle := bsNone;
frmShipRef.Align := alClient;
frmShipRef.Show;
I just set up a new form with tabs, then create each other form with the code above. This has worked well, and with a little conditional compiling I was able to add a panel on the left which provides a sort of "meta-copy-and-paste" to allow them to pass data between themselves.
Since all of your other apps are single form, you could cut/paste/save all components in each app onto a separate "background" panel saved as a Component Template. Then you could load your Component Template onto its own PageControl/Tab.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This question isn't about unit-testing. And it is for a desktop product.
This is about testing of the gui and testing that the right stuff is input in the right text box at the right time.
A company I used to work at used WinRunner (different department so I don't know much more that that), but that has now been shutdown by HP but they don't seem that bothered whether you stay with HP or go elsewhere. You can't read about the product until you've signed up which is annoying.
The tool has to work with MFC (non-negotiable) and the ideal tool will also...
be automated.
be scriptable.
work with different screen resolutions automatically.
be able to 'spy' on individual static text boxes, etc.
intuitive enough so non-programmers can create the scripts.
have reporting tools, including email of individual users.
What do other SO users do for automated GUI testing?
We use the SAFS framework for Rational Robot (RRAFS). There are also SAFS implementations for WinRunner (WRAFS) and it looks like they have a new "Image-Based Testing" implementation, which I'm not familiar with.
This framework does a nice job of seperating the UI implementation from the test scripts. I've tested four releases of a web application developed by two different teams (one team using classic ASP, one using ASP.NET) and I only had to change the application map of my UI objects, the tests themselves didn't need to change.
That said, the language of the framework is cumbersome and takes getting used to. It's not very robust, in terms of language constructs, but with some effort you can do anything you need to. It's sort of like "programming" in Windows Batch language, but for tests ;)
To address your individual requirements above:
1) The tool has to work with MFC (non-negotiable).
The SAFS framework uses a 3rd party "record-playback" tool to drive the tests, like Rational Robot or Mercury WinRunner. If that tool can interact with MFC apps, then the framework can. I don't know how the "Image-Based Testing" implementation drives the tests, but I'd guess it can also work with MFC.
2) be automated.
The SAFS framework integrates with the STAF framework, which will allow you to automate the execution of your tests. I have a proof-of-concept test that uses STAF to start a VM image from a pool of images, install the application under test, run the RRAFS test, and put the results on a web server for others to get at.
3) be scriptable.
Yes, but as mentioned, it's not the most robust programming language. I wrote an Excel add-in that our testers use to write their tests that simplifies things a little bit.
4) work with different screen resolutions automatically.
Yes, since it's looking "under the covers" at the UI objects and not the screen. Except for maybe the "Image-based Testing" option...
5) be able to 'spy' on individual static text boxes, etc.
Yes, you can wait for a UI object to appear, disapper, to have a value, for a value to be changed, etc.
6) intuitive enough so non-programmers can create the scripts.
With some training. We've had limited success. Some QA folks can write the tests, some struggle.
7) have reporting tools, including email of individual users.
Yes, using the STAF framework you can post results to a web server, send out emails, etc.
Lots of good answers here, but I wanted to address this goal statement, specifically:
intuitive enough so non-programmers
can create the scripts
I can understand why you'd want this, but it's a lot harder than you might think. While you can find any number of tools out there that'll claim to make writing scripts easy, in practice, you're going to need at least some people on your automation team who understand programming. Writing scripts that are reasonably robust is going to involve one or more of looping, if/then/else, and subroutine calls. Not the kind of thing that non-programmers are going to find intuitive.
Be especially wary of the idea that you can "record" a person using a tool, then play it back for testing. That sort of "automation" is often so brittle that you'll end up modifying or re-recording the script for nearly every change in the software.
Coming from a strong Mercury/HP background, I would highly recommend using QuickTest Professional for your GUI testing. It has a lot of the same functionality as WinRunner, but without a lot of code. Simple GUI checks can be done through the QTP interface with minimal, if any, custom VB code. Checks for text next to boxes can be done with simple compares using the datasheet in QTP.
If you are used to WinRunner, and know VBScript (not so much TSL), then I would definantly look at QTP.
As far as your other requirements, QTP also has the Spy feature, like WinRunner, that will list all properties and actions you can perform on objects. And as for simplicity of use, at my old job, we would have business or system testers create simple smoke scripts, then I would take them and code them for more in-depth testing (multiple data values, error checking, etc). And as for reporting, QTP will do simple reporting of pass/fail/warning on tags that you put in, along with custom data you can input. So you could use a case statement to populate your output values based on your results. It won't do e-mail naitevly, but if you integrate with TestDirector/QualityCenter, you can setup through there, along with automating the kick-off of your scripts, and parameterizing data right from there (which is nice to send back to testers to have populate data without being involved in the script itseld).
Pat
See User Interface Testing.
Desktop or Web apps alike have the same testing pattern here (I've worked in both).
Place as little logic as possible in the UI and test everything below it. So you say, but what if I want to test that such and such happens when a button is clicked? The method that is called when that button is clicked should call out to another class that actually does the thinking.
You might say, but I'm using some static classes/methods that can only exist in my UI, wrap those with an adapter and utilize that interface in order to make your code testable.
The parts of your GUI tests that you want to automate should be automated below the UI. There are parts of your GUI that you can't automate. Checking to make sure things "look right", or testing that you can see certain elements, etc. All of that is what your humans should be doing. Ensuring that events are properly firing, and that values are being appropriately returned from your business objects, that's all unit tests.
I can see from your question that you've already pretty much decided you need an automated GUI tester, but that's not the right tool for this job. If you decide to use that you're trying to find the best way of doing the wrong thing.
If you think that this isn't about unit testing because you're testing GUI interactions, then I can guarantee you're not unit testing close enough to your UI. If you were, you'd feel like most of what you'd be testing was redundant.
If you disagree with me, please post some reasons and we'll hash this out.
There are a lot more (open source) alternatives if you are testing a web product. For a desktop product, some popular general purpose desktop GUI automation tools below (in no particular order). I've worked with all of these personally, and they all get the job done. If you choose to go with a vendor tool, get POCs for the ones you are considering, and make the decision based on what tool is the best fit for the company in general. One tool may be a better fit for a particular application, but there may be other projects/applications to consider.
QuickTest Pro (HP's successor to WinRunner)
Rational Functional Tester (IBM's successor to Robot)
TestPartner
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We are currently working on a new version of our main application. one thing that I really wish to work on is providing support for multiple monitors. Increasingly, our target users are adding second screens to their desktops and I think our product could leverage this extra space to improve user performance.
Our application is a financial package that supports leasing and fleet companies - a very specialised market. That being said, I am sure that many people with multiple monitors have a favourite bit of software that they think would be improved if it supported those extra screens better.
I'm looking for some opinions on those niggles that you have with current software, and how you think they could be improved to support multi-monitor setups. My aim is to then review these and decide how I can implement them and, hopefully, provide an even better environment for my users.
Your help is appreciated.
Thankyou.
Few random tips:
If multiple windows can be open at one time, allow users to have them on separate screens. Seems obvious, but some very popular apps (e.g. Visual Studio) fail miserably at this.
Remember the position of the last opened window, and open new windows on the same screen as before. However, sometimes users switch between multiple and single-display (e.g. docking a laptop with an external CRT), so watch cover this case as well.
Consider how your particular users work, and how having two maximized windows simultaneously might help. Often, there is a (fairly passive) window for reference (e.g. a web browser/help) and an active window for data entry (e.g. editor/database) that users switch between.
Do not put toolboxes/toolbars on a different window than objects they operate on (it's inconvenient to move the mouse so far).
Apple's Human Interface Guidelines for the Mac have covered window management on multiple displays since 1987, when the Mac II was introduced with six slots that could all contain a graphics card. The guidelines offer a few good guidelines that you might not think of at first when implementing multiple window support. For example, if a window spans multiple displays, which display should new windows be opened on? There's an answer around Figure 14-33 in the chapter dealing with Window behavior.
Microsoft may have something similar now for Windows developers to follow; if that's the case, check it out and follow their guidelines since you don't want to behave differently than the other apps on the system (or that your users are used to) for no good reason. However, if there are no guidelines, follow Apple's as they're fairly well thought-through and were originally developed through experimentation and research.
Please Please Please. If you remember window positions for multiple monitors. Please detect if the second monitor is connected. I have a laptop that is sometimes docked. It is very annoying when I try to open a window and it opens off screen.
It's annoying when I drag a window to another monitor, and then if the application generates a popup dialog, or spawns another window, if that popup/dialog gets displayed back on the primary monitor.
I haven't developed for multi-monitors, but I think this can be better handled if you position child windows/dialogs centered on their parent window, rather than on the desktop center (which I'm guessing is what happens in the case I describe above).
I'm going to have to a give a nod in dbkk's direction as they captured a couple of the major points that you need to remember.
Also, I would suggestion paying attention to how you use dual monitors and try to keep that in mind as you are developing. Generally you should try to avoid doing the things that applications you work do that annoy you. Also, don't assume that just because the user has dual monitors that they are going to want to work with your application on dual monitors.
The biggest thing that I would stress is keeping track of where the focus is in the application and making sure that any pop-ups occur within that region, one of the things that people seem to dislike the most is having a window pop-up in a different window then the one they are working on.
Definitely keep dialogs near where you clicked to bring them up. Remember what monitor the window is on between sessions. Be aware that if they have less monitors than the last time your app was run that you need to bring the windows back to a visible area. Provide an icon or button to switch monitors. Depending on the type of app it may be useful to be able to easily tile your app's windows on a monitor or on all.
One thing to keep in mind is that the user may have more than two monitors. My main system has six monitors, and I've run 4+ monitors on Linux, Windows, and Mac OS. Many applications--even multi-monitor utilities--will support 2 monitors but freak out over more than 2.
Applications work best when they know about where their windows are and relate to the locations of those windows. And as someone else mentioned, if you're going to remember where a window was, make sure that geometry still makes sense when the user comes back.
If the OS/window system dispatches an event related to the change of screen geometry, handle it if you're doing anything funky.
I think most applications that are well coded generally work these days.