I'm new in win32 programming and I've some questions about resources.
Must I use a resource editor (from Visual Studio) to make controls? I know it can be post-edited using a Resource Hacker editor. How to prevent it?
GUI created in Windows Forms (.net) or Borland Delphi (VCL) can't be edited using res hacker, maybe it creates controls at runtime.
Is a pointless work make all controls by runtime to prevent it to be edited by res hacker?
HWND hButton = CreateWindowEx(
0,
_T("BUTTON"),
_T("Click!"),
WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON | BS_LEFTTEXT,
5, 5, 80, 25, hwnd, (HMENU)IDC_BUTTON1,
GetModuleHandle(NULL),
NULL
);
Second question: isn't there a easy way to set position of a control in top right of parent window?
Today I'm doing it in this way:
case WM_SIZE:
{
HWND hButton;
RECT rcParent, rcButton;
hButton = GetDlgItem(hwnd, IDC_BUTTON1);
GetClientRect(hwnd, &rcParent);
GetClientRect(hButton, &rcButton);
if(!SetWindowPos(hButton, 0, rcParent.right - (rcButton.right - rcButton.left + 5), 5, 0, 0, SWP_NOSIZE))
{
MessageBox(hwnd, _T("Error at WM_SIZE"), _T("Error!"), MB_OK | MB_ICONERROR);
}
}
break;
Are there something like Anchors in pure win32 programming?
The resource file format for dialogs is ancient. The only thing in its favor is the dialog unit abstraction that means that dialogs automatically scale to take account of the users preferred font face and display dpi settings.
Other than that, there is no support in the dialog format for anchors. Microsoft have sadly not released a new UI building toolkit however for native development so for Native Win32 apps you are stuck creating / positioning your controls at runtime manually for any task that dialog resources cannot cater for.
WPF is clearly superior, but requires .NET
I don't see the point of disallowing res hacking one way or another. What do you gain by preventing it? If your own layout skills are so bad that people will want to re-layout their dialogs "illegally" then... well wtf is all I can say.
To Summarize:
It IS pointless to try and protect dialog layouts. What can you possibly hope to achieve by limiting something people would only resort to if your own layouts were ##%^ anyway.
You WILL however probably want to create the controls at runtime anyway as the dialog resource format lacks modern features like anchors. Allthough it is a good idea to continue the practice of designing forms in units based on font metrics rather than pixels.
If you want a pre-build "form" layout system with anchors, Win32 cannot help you. The QT framework if you want a cross platform c++ solution, or switching to .NET's WPF are both powerful alternatives that may allow you to leverage your existing non UI code.
Is a pointless work make all controls
by runtime to prevent it to be edited
by res hacker?
It's not pointless, it's only extra work. You will need also to code a resource editor and/or a layout manager to ease your work. You can define and handle your own resource definition file, and put it as a custom resource.
Are there something like Anchors in
pure win32 programming?
No layout manager in pure win32. But you may find some free source code to do this. It's rather easy to do some minimal layout manager.
Hi probably no becouse win32 api is base for most all graphics libs in windows. What can i recommend you its use some graphics libs if you can do it in your project.
Related
I am writing a small GUI library in OpenGL for fun and profit. When it comes to font handling, so far I require the client application to explicitly load all fonts and set them on the widgets. So far this is ok, I also have a means to set them once as a default for all widgets of a certain type.
Although this is feasible, I though, would it not be dandy to use the system's default font as a default instead. In the case of Windows this would be the fonts that are configured though the Color and Appearance dialog.
After warming up my rusted Win32 programming knowledge and souring the MSDN I can't find an awnser to this question. I can load a font by name and set it on any widget, but figuring out what font Win32 would use as a default eludes me.
So far the best I have found is the SystemParametersInfo function with SPI_GETNONCLIENTMETRICS. But these are just the settings for the "non client" area, such as window title bar and such.
DEFAULT_GUI_FONT is not your solution. The name certainly sounds good, and indeed it was the default GUI font at some point in history, but that font hasn't been used in years.
You already stumbled upon the correct solution: calling SystemParametersInfo with the SPI_GETNONCLIENTMETRICS option. This will fill in a NONCLIENTMETRICS structure with information about the standard system fonts.
The "standard UI font" in that structure is called lfMessageFont. It is the one used for text in message boxes, dialog boxes, and elsewhere in the client area of windows. It is the same one configurable in the "Appearance" properties.
I wrote out a very detailed answer about fonts in Windows applications a few years ago. That one kind of focuses on MFC, so I've chosen not to mark this question as a duplicate of that other one and compose a separate answer, but really all of the information you need is there.
For fun, I'll throw in that you can get the system colors by calling the GetSysColor function. Pass one of the COLOR_* values to indicate which color you want; you'll get back a COLORREF value (typedefed as a 32-bit unsigned integer into which are packed the red, green, and blue component values of the color). Use the GetRValue, GetGValue, and GetBValue macros to extract the individual components; I doubt OpenGL wants COLORREF values.
I have a video playing of lines being drawn on the screen. Is it possible to create a pixel shader (for WPF) that turns newly colored pixels a certain color for N milliseconds?
That way, there can be some indication to the user to movement on the screen when the lines don't move often and the user isn't always looking at the screen.
You can use DirectShow. Its written in unmanaged code, so you need to use this wrapper DirectShow.NET in order to use it in your C# application which is running in managed environment (samples are included, even with EVR which stands for Enhanced video Renderer which means MUCH better video quality). And when you will be passing a control handle to wrapper method for setting the video output, you need a WinForms control, because only from them you can get your desired control handle. That WinForms control you can then host in your WPF application using the WindowsFormsHost control provided for such situations when you need to use some WinForms control(s) in a WPF application. Its just theory, so i dont know if its an ultimate solution for you.
BTW: The whole idea is based on fact, that DirectShow is just some query constructed from separated filters. Renderer is a filter (EVR, VMR-7, VMR-9). Sound player is a filter. And they are connected through their pins. Its like a diagram. Electronic schema or something like that. And you can put for example Grey scale filter in there. And voila, video output will be greyscale. There is a bunch of tutorials for that. And completed simple filters as well. Unfortunately, filters must be written in C++:(
PS: I never said its gonna be easy:D
In Windows Phone UI Design Principle, MS recommended use solid color rectangle or coding-gradient for Control Background to avoid incompatible in multi-screen. But in many requirements, using image as Control Background is necessary. Then, 9-patch image technique is used. In Android and IOs, it was support in core, but in WP it is lacking. I try to use it in WP by 3 approaches:
Using 9-cells Grid: clip image into 9 patch and lay them into cells. It works ok, but i afraid app performance reduce when has many control.
Using Custom Brush: only custom Brush to draw 9-patch image as ImageBrush, but seem MS not allow for custom Brush.
Using FramworkElement: like Rectangle, Ellipse... i want to create a FrameworkElement can draw a 9-patch image. But, can't use low-level render.
How can i implement 2nd and 3th approach?
I created a lib for Windows Phone which do exactly as Android NinePatchDrawable. You just need to set a bitmap image.9.png, the width and heigh... And done!!! you have you new image scale to the size you want. Enjoy it :). In the future I will add more option :).
GitHub link
You can compensate for the lack of low-level rendering and custom brush by using a WriteableBitmap: http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.writeablebitmap(v=vs.95).aspx
This way, you have complete control on how to render your background, then you can assign it to a single Image control. But it's way more complicated than the "use a grid with 9 image controls" method, and the performance improvement is probably insignificant.
In Vista/7, the Windows Explorer shell window makes use of a special kind of static progress bar to display hard drive space.
With default styles, this bar is blue colored and non-animated. It also turns red colored when it gets close to being full (low disk space).
Using messaging, I can tell the Windows Forms ProgressBar control to update its state to Paused and Error (yellow and red colored, respectively), which works fine, but these are still specific to progress.
In the Windows User Experience Guidelines, it specifically points out this "meter" variant of the Progress Bar:
This pattern isn't a progress bar, but
it is implemented using the progress
bar control. Meters have a distinct
look to differentiate them from true
progress bars.
They say it "is implemented using the progress bar control", so... how? What message could I send to the control to have it behave this way?
I've seen that you can send messages for setting the bar color, but the documentation says these calls are ignored when visual styles are enabled. Nothing else in the Windows API documentation for raw ProgressBar controls seemed to suggest a way to do this. Am I just stuck making a custom drawn bar? I'd really like to utilize the OS whenever possible so that the application will appear consistent throughout different OS versions. I realize that pre-Vista versions probably won't support this, though.
I'm looking for a Windows Forms solution, but I wonder if it is even exposed at all via Win32 API.
It is possible, but not through ProgressBar. Nor does Win7 use a PB to draw those meters, there is no window handle associated with the bar. It must be using custom drawing. That's possible in WinForms as well with the VisualStyleRenderer class. One thing that doesn't help however is that the required visual style parts and states are not declared, not even in .NET 4.0.
This sample form reproduces the meter bar:
using System;
using System.Drawing;
using System.Windows.Forms;
using System.Windows.Forms.VisualStyles;
namespace WindowsFormsApplication1 {
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
VisualStyleRenderer renderer = new VisualStyleRenderer(VisualStyleElement.ProgressBar.Bar.Normal);
protected override void OnPaint(PaintEventArgs e) {
renderer.SetParameters("PROGRESS", 11, 2);
renderer.DrawBackground(e.Graphics, new Rectangle(10, 10, 200, 15));
renderer.SetParameters("PROGRESS", 5, 4);
renderer.DrawBackground(e.Graphics, new Rectangle(10, 10, 100, 15));
}
}
}
I got the part and state numbers from the vsstyle.h SDK header file.
I have developed a 1024 *780 resolution screen in Windows Forms, but some say that it does not fit properly at higher resolutions. Is there any way to handle this?
Is there a way to make Windows Forms applications look the same at ALL resolutions?
My recommendation is not so much to "make it look the same" on all screens, but rather to design the GUI so it scales up and down more gracefully. Layout managers, docking, and anchors are your friends in Winforms. The TableLayoutPanel is quite useful for this sort of thing. Splitters also help...
Finally, this is one of those problems that WPF sets out to solve. WPF makes extensive use of layout managers. It feels much more like Java or GTK than Winforms or even VB (old school VB).
This is the sort of thing that makes you say "there's got to be a better way."
My solution for this one time was to declare a global ScalingFactor variable that was tied to the current screen resolution. Then, the sizes of every visual element were multiplied by that factor.
So, if I designed my form for resolution A, and resolution B is 1.2x larger, the width of window A will be with * 1.2, the fonts will be fontSize * 1.2, the textbox dimensions will be dimensions * 1.2.
Not fun.
There may be 3rd party tools that you can buy and will perform this scaling.
One other thing to check before you run down any of these roads is whether it is actually the screen resolution or the dpi settings that are causing it to look bad. Usually a higher resolution will only make it look smaller, but an atypical dpi, such as when the user selects "large fonts" will wreak havoc.
You can use anchor property of item, and autoScaleMode property of form set it equals 'None'.