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.
Related
I read that WPF uses DirectX under the hood to perform its rendering, that it doesn't rely on the dinosaurian libraries that WinForms uses to render controls.
So I made my Presentation layer with WPF and it looks the way it should under Win8.
Then I deployed the project to Windows Server 2003... to find out that my nice little custom message box looks awfully WinForms-like and somewhat clunky; the button controls are VERY similar to the WinForms ones, the expander control is no longer shown as a circled ^ arrow and looks like it was drawn in 1998 (picture the ^ arrow on an ugly square flat button that pops up when your mouse hovers over it).
From the Pro WPF in C# 2010 Bible:
Part of the promise of WPF is that you don't need to worry about the details and idiosyncrasies of specific hardware. WPF is intelligent enough to use hardware optimizations where possible, but it has a software fallback for everything. So if you run a WPF application on a computer with a legacy video card, the interface will still appear the way you designed it.
So, is this a lie? To me it is, because it doesn't appear the way I designed it.
If not, then why/how doesn't the thing render identically regardless of the machine that's running it? Is the software fallback somehow designed to mimick Win32/GDI rendering? Is there a way to get my little custom message box to look identical on Win8 and WinServer2K3?
That has NOTHING to do with DirectX / Rendering / video card / any of that.
and EVERYTHING to do with WPF taking the DEFAULT appearance of ALL UI Elements from the Windows Theme.
If you don't want this behavior, you'll have to provide Styles and Templates for ALL UI element types, or otherwise find a way to include PresentationFramework.Aero.dll in your application and use that as the default theme library.
Take a look at this answer
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 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
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.
I am working on a demo application for a library me and two colleagues are writing to allow GNOME applications that run audio events though libCanberra to allow users to select visual events to replace them. This is an accessibility-minded effort to help both visually and aurally impaired users gain the benefits of audio alerts and such.
For our first demo we're simply trying to make the entire screen flash with a color when a button is pressed in our simple GTK sample app. I've been looking at the GTK documentation and all drawing that I've seen has had to do with drawing directly to a window or other widget. I want to control the entire screen's hue. Would this be a GDK thing? Am I completely off base?
Any links/help will be much appreciated! Thanks.
PS: This is being written in C, though functions should be the same between languages with proper bindings, I assume.
You cannot. Your application has access only to its own window, and does not (and should not) know anything about other windows, or the screen. The "screen" is managed by whatever back-end GTK uses (X? Win32? DirectFB?).
That said, you could try to create a "full-screen" window that covers the entire screen area. That is the way full-screen apps are implemented in most windowing systems.
GTK doesn't have such option AFAIK, you probably want to use the backend: Xlib (or Xcb) for that.