I'm a complete novice in gui-programming and I'm looking for an easy way to visualize a data structure I have. I own another program that does a similar job and the component it uses seems like it would fulfill my purposes as well. So instead of testing out different components myself (Which would undoubtedly force me to learn a lot), I'm wondering if there's a fast way out of it.
Is there anyway to find out what specific wpf/winform component a program is using without asking author/having source code access?
Edit:
Looks like this, the area it's in is scrollable horizontally/vertically. The objects on it are selectable, moveable and have actions associated with their right-click menu. I want to visualize an undirected graph and have the possibility to interact with the nodes graphically.
Here's the control I'm talking about:
First step, I'd look at the assemblies the app references. If it references a dll from a component vendor (a simple search can figure this out), you can visit the vendor's website and check out their offerings.
If it is a custom control embedded within the application, and its a WPF app, I'd use Snoop.
(Image ganked from http://snoopwpf.codeplex.com/). Snoop can sniff out the visual tree of a WPF application at runtime and show you all the controls that make it up.
This is no standard control but some propritary one. You can have a look in the program folder of that program which dll's they use, chances are that you can use this dll in your own app. Note that the license of this application may forbid using the code!
Related
I am trying to create a new project with the new GUI BUilder (I've already made hand-coded project). I watched Steve Hannah's tutorial about creating a sign-in form. If the sign-in form was hand-coded then it would have to use eg a Y-BoxLayout Manager. However in the tutorial everything is laid-out without resorting explicitly to this layout manager what I understand because the designer provides the layout.
But I wonder why new the GUI Builder offers such containers with specific layout managers ? What are the use cases when they should be used, and are they meant to be used as is (as ready-to-use examples) or the designer should remove the components inside with custom ones ?
Thanks in advance for the shed lights ;-)
The current version (3.7.2 and earlier) works best with a flat layout (i.e. not nesting subcontainers). The next release will include improvements that make it easier to work with nested layouts.
There are many reasons why you might want to use a nested layout. A couple of use-cases that come to mind are:
If you're laying out a form that has more than one logical section and you want to be able to lay them out independently. In this case using a couple of sub-containers that both use LayeredLayout themselves can make things a little easier.
If the layout has a nested list (i.e. box-layout-y) that you will populate in code at runtime with content that you load from a web-service, etc..
I've done a lot of WPF and am now, for the first time, trying to get a grasp of Qt, so far fairly successful.
However, in WPF, I'm used to encapsulate self-enclosed parts of GUIs in User Controls so that I can then easily re-use them across dialogs or rearrange an entire block without having to touch every single element. If, for example, I was building a main window that would show information about a hospital, about the area it is in and about its manager, I would encapsulate each of the three blocks in a User Control and my main window would just contain three instances of those controls.
With Qt, I was as yet unable to identify the concept I should use for this type of encapsulation. Should I be 'casting' those building blocks as custom widgets? My guess is that Qt has a concept for that which I can't find because I don't know what it's called.
Thanks for your help!
FS
You would create custom classes based on QWidget or some other simple widget class (QFrame for instance). It's pretty standard practice, no need for another concept.
By modern menus I mean menus like those made using MFC or Windows Forms(MenuStrips). I know that it is possible since I have seen some apps that use it which are developed in the Windows Api. It has also been done in the Win32++ library, and MFC and WinForms are just Win Api wrappers so if they contain modern menus, Win Api must contain them too. But my question is... How can I make a menustrip directly in the Windows Api? Is it included in the CommonControls? Or do i have to implement it myself? If so then how? Example code needed, but not necessary.
Menus somewhat like this
MFC and Winforms use very similar approaches to implement these custom menus. They start with generic support in their ToolBar/ToolStrip classes and specialize them for the menu bar/item classes.
You'll find the MFC implementation in vc/atlmfc/src/mfc. The afxtoolbarxxx.cpp source code files are about 24,000 lines of C++ code. Menu class specializations are in afxmenuxxx.cpp, another couple of thousand source code lines.
You can obtain the source code for the Winform classes from the Reference source. The ToolStripxxx.cs source code files are about 40,000 lines of C# code. Menu class specializations are in Menuxxx.cs, another couple of thousand source code lines.
Both use lots of support classes provided in their respective frameworks, basic stuff like window wrappers and image/text rendering support. Hard to guess how much of that they pull in.
Numbers like this are about an order of magnitude beyond what most programmers would consider feasible to rewrite themselves. You can certainly do better by shaving off features, both the MFC and the Winforms implementations have a lot of bells and whistles. Winforms more so, the basic reason it has so much more source code. This kind of feature support was however added with the express intent to provide a class library that you'd use instead of try to replace. Recommended.
MFC and WinForms are just Win Api wrappers so if they contain modern menus, Win Api must contain them too
This is not true. The basic menu handling code exists in the Win32 code libraries (basically user32.dll), and this enables you to create, draw, and handle messages to make the menus work, but they are very basic menus (just plain text). MFC works by calling the Win32 functions and handling the messages just as anyone else would, but it uses custom drawing routines to spice up how they look. And this is exactly how every other library does it. The only other way to do it is to draw the entire menu yourself (it's just another window), drawing any icons, handling the highlighting as the mouse moves over it, handling button clicks, etc, all yourself, which is a waste of time if you can get Win32 to do it.
So, if you want to have menus that look like that, you either have to code it yourself, or use a library that others have coded. It's as simple as that.
You probably have to implement it yourself, or use some 3rd party implementation.
See: How can i change the appearance of Windows 7 menus?
go to http://www.winprog.org/tutorial/simple_window.html you will find everything about window api programming tutorials
You'll need a 3rd party library such as CodeJock's Extreme Toolkit.
If you can't afford the budget, you may want to dig Code Project for some free source code.
I'm very much new to Test Automation kind of thing. Recently I've been assigned to a project where I have to write an application (or, a script may be, I'm not sure) that will automate the UI testing of a CAD-like WPF application which misses lots of AutomationIds.
After doing a little searching on MSDN and other sources I'm a bit confused about whether I should use the Microsoft UI Automation Library or the new Coded UI Test feature included in VS2010. I'm not getting the clear picture of which one of these two applies in which scenarios, what advantages one has over the other and which one suits my purpose.
Please shade some light if you have experience/knowledge on the matter. Thanks in advance.
Basically Microsoft UIA is the new accesibility library in .Net 4.0. WPF applications and controls have built-in support for UIA through the AutomationPeer class.
Coded-UI test is a Record & Play automation tool which uses the Microsoft UIA Library underneath. Since being a tool compared to writing code in C# it improves QA productivity for recording more test cases.
For applications with automation support planned into it, Coded-Ui should be sufficient. If the AutomationIDs are missing make sure the controls have some unique property like Name. Use UIVerify or Inspect to check for this.
If NO unique property is avialble, there are the other below mentioned techniques you can use in combination with Coded-UI.
From an Event
When your application receives a UI Automation event, the source object passed to your event handler is an AutomationElement. For example, if you have subscribed to focus-changed events, the source passed to your AutomationFocusChangedEventHandler is the element that received the focus. For more information, see Subscribe to UI Automation Events.
From a Point:
If you have screen coordinates (for example, a cursor position), you can retrieve an AutomationElement by using the static FromPoint method.
From a Window Handle:
To retrieve an AutomationElement from an HWND, use the static FromHandle method.
From the Focused Control:
You can retrieve an AutomationElement that represents the focused control from the static FocusedElement property.
If you can leverage and use the Coded UI Test then go that route. Make sure to verify that your given configuration is supported.
The UI Automation Library resolves everything in the code behind. This then forces you to use a tool like UISpy to gain access to the controls internals so that you can then build out your test.
A Coded UI Test on the other hand still has code behind however it allows for the recording of steps through the given application which you are testing which will greatly increase the number of tests you can create.
UI Automation library is a low-level library. Usually, you don't want to write tests against it directly as it requires a pretty decent amount of work.
I would recommend looking at more high-level libraries. You mentioned one of them - Coded UI; another good choice would be White from TestStack. They both suits different kinds of projects. Coded UI is good when you don't want to invest a lot of efforts into your test suite. At the same time, it doesn't scale much so if you are going to write a lot of tests, you are better of choosing White.
Here I compare the two frameworks in more detail: Coded UI vs White
To complement the above responses, please look at CUITE that helps quite a bit and may be an appropriate approach for you.
I began 'rolling-my-own' 'semi-framework' using the CodedUITest library and devised a paradigm for separating the details of automation from the (C#) code.
Basically, I am creating a driver that reads what needs to be done from spreadsheet(s) where each line in it is a test step (or a pointer to a scenario in a different worksheet).
At present, incomplete, but promising, I have it working against a WPF application with partial success.
One of the main problems is that the developers neglected to identify controls uniquely and consistently.
Bey
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai