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.
Related
This might be a stupid question, but there are soo many combinations of approach (wpf, silverlight, winforms, html5) with incompatibility at mscorlib level, that I got completely lost.
I would like to be able to have a few windows mainly displaying realtime charts.
Probably with interaction among the windows (click in one, pop and display a new windows)
If it can be viewed on the web, perfect.
But I dont want to have to deal with another layer of nasty stuff for those features (like having to setup some "WCF" on a "IIS", kill me first)
In the end I was thinking of using FSharpChart on Silverlight.
Is that possible and/ or the best option ?
Thanks for your suggestions
update
I see that system.drawing which fsharpchart relies on is not silverlight supported..
Try Dynamic Data Display instead of FSharpChart. It runs on Silverlight: http://research.microsoft.com/en-us/um/cambridge/groups/science/tools/d3/dynamicdatadisplay.htm
It's not as F# Interactive friendly as FSharpChart, but you can easily wrap it in a handful of functions to make it more usable
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!
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 am developing a CAD like application. This application is cross platform in the sense that I have a main window which is native to the platform it is running on (Linux, Windows and Apple). Within this window I have an OpenGL context and there I do all my rendering. The application in question does not really rely on common controls (radio buttons, check-boxes, labels etc), however there is the need for the user to be able to enter/edit some text. This text could be a few lines long but not more than one hundred.
How would I go about implementing such a control, I don't want to go as deep as developing my own text editor but it would be nice if it had some basic editor controls (cursor movement, delete, insert etc). I also don't want to use the native systems common controls as my own none cross platform code at the moment is the main window.
Any ideas?
Edit: This is informative
OPENGL User Interface Programming
Thank you
I think you are taking a longer approach here.
Rather than providing an interface through OpenGL and writing my own controls, I would go for a cross-platform GUI toolkit such as wxWindows, and use the GLCanvas provided to do my rendering. You'll have all the might and flexibility of common controls, you'll still be able to OpenGLize whatever you want, and the look of your application will be more standard, thus friendlier.
My program has a static interface, but I don't know what's the best way to make my interface. With resource files or with the CreateWindow function using the WM_CREATE message?
Thanks
Id recommend starting with dialog resources first. Then, if/when that is insufficient, make your own windows directly.
As a hardcore native developer, if you really want to make applications with a nice GUI, i hate to say this, but you'll get much more bang for your buck if you go with .NET's WPF - or even Windows Forms as a window layout language.
MS have made a concerted (and to my mind, somewhat malicious) effort to not add necessary new features for native applications so we are left building everything from scratch: the native controls don't support alpha aware painting, don't support back buffering, havn't been upgraded with the new Windows 7 widgets like ribbon bars, havn't been given any kind of animation system, and the dialog template based layout system is inflexible at best.