I have a Label that is indicating a file size with
FormatFloat('##.## KB',BytesIn/OneKB);
and it all worked fine when the files were all under about 2MB. Now I am sometimes using files 2GB and up.
FormatFloat('##.##### MB',BytesIn/OneMB);
The Caption is being updated about every 1-KB and the flickering is fierce.
Any way to stop that or minimize it some?
The Delphi TLabel can indeed be a flickery beast. Many people will recommend double buffering, but I don't like that. It brings other problems. In particular, if you are using themes then double buffering can interfere with the themed rendering.
My trick for dealing with label flicker is to use a TStaticText instead of a TLabel. This is a windowed control, a wrapper around the Windows STATIC control, and in my experience it invariably will not flicker in the scenario where TLabel would.
As others mention, throttling update rate is a sound idea, and is wise irrespective of flickering. There's no need to spend resources updating the UI any faster than the human eye can absorb. For something like download progress you should not really need any more than 5Hz in my view. This may very well be the root cause of your problem, and if throttling update rate solves the problem then you can stick with TLabel.
My answer here has some more general anti-flicker tips: TLabel and TGroupbox Captions Flicker on Resize.
Related
Windows 7 appears to only support 48x48 pixel mouse cursors natively. My dad is half blind, so this isn't good enough.
Looking around a little, I see that there is High DPI Cursor Changer Beta on SourceForge. Unfortunately, it states that it is limited to Windows 8 and above. Even if he did have Windows 8, I still don't think it would be big enough.
I've been thinking about some other alternatives which might get the job done. One is to use AutoHotKey to track the mouse position and type, and using that information, put up a larger bitmap under the cursor that is displayed on a click through window.
This seems doable, but I would like it if I could invert the information beneath the cursor as the inverted mouse cursor does. I'm thinking that this would require using the DirectX API, which I'm totally unfamiliar with. As I don't have a whole lot of time to devote to this, it would be great if someone could point out some key concepts and API calls so that I can move through this project as fast as possible.
I've also looked into zooming in, but seems using that is also problematic as it requires that he get it in and out of that state and zoom in and out fairly easily, which he can't as he can't really touch type and his fingertips don't have very much sensation, making it hard to navigate the keyboard effectively.
If there are any other ideas, I'd be interested in hearing about them as well.
I haven't tried Bill Myers solution, so I think that the cursors are still the max. size, but check out Bill's link: https://www.bmyers.com/public/high_visibility_cursors.cfm
I'm experiencing painting issues when combining TScaledLayout and custom styles created from the bitmap style designer in fmx.
To demonstrate, I loaded the default custom style created by chosing "New style for VCL / FMX" -> "save as .style" in the bitmap style designer. I dropped several standard controls on some colored rectangles: The red & green ones on a TScaledLayout, the blue one directly on the form. As I stretch the form, colored lines appear on the controls on the ScaledLayout; the background is partially visible:
If I size the form to exactly match the design-time dimensions, the lines disappear. That seems like a pretty significant issue, I certainly can't use those two together like that. Does anybody have an idea for a possible fix or workaround?
Looks like this is a known issue with scaling and bitmaps. See the Google+ discussion here - https://plus.google.com/+PaulThornton/posts/ACAHkJD3a84. I'll quote Marco Cantu's thoughts:
I've found an internally reported issue of a similar case, but haven't
found one that matches this scenario. Certainly worth adding to quality
portal. Having said this, I fear that bitmap-based operations and
scaling don't really fit together very well, and it might be difficult
to have an all encompassing solution.
Let me explain with an example. Take a button. This is painted by FMX
with 9 sections (borders, corners, central part) so that regardless of
the size the bitmap elements are stretched in one direction at most,
often just draw. Stretching a single bitmap for the button to the
target size would break anti-aliasing and create a blurred image when
using colors.
This is example what happens with a ScaledLayout, given it takes the
complete final image and transforms it. ScaledLayout was originally
introduced with vector styles, and worked very well in that scenario.
With todays's bitmap styles things get a bit more complex.
Regardless of this explanation of there the issue lies, I'd recommend
reporting it on QC, and I'll make sure it doesn't get closed as design
(it could naturally happen, this is how the system works) but that we
do some investigation to address the issue -- turning this into a
feature request.
I thought scaling an application in FireMonkey should be easy as it is supposed to work an a Retina-Mac too. It seems there is some background magic which chooses another style than, but this doesn't seem to be the case in Windows.
In VCL there was TForm.Scaled which does the job (more or less).
For FireMonkey I found this Article by Embarcadero but it seems Embarcadero is not quite sure if this approach is useful as in XE5 the sampleproject "ControlsDemo" doesn't contain the scale-trackbar anymore. It also requires to have a root-TLayout present in all forms for which the scale factor can be set. I don't have such a element in my forms (and I'm afraid to add one as I cannot be sure if I run in another firemonkey bug than).
So how do I account for different DPI-Settings using FireMonkey?
Edit: I tried hacking TPlatFormWin and set CurrentScreenScale to 2 but it didn't work: I got black toolbars, but no scaling, but at least it used the HighRes alternative from the provided TImage.MultiResBitmap.
If anyone reads this... my experience with Windows desktop Firemonkey is that you have to take care of OS DPI setting manually and it's OK to put your controls in a top container (a TLayout) that's Scale is set according to the OS screen DPI settings (determined with some low level code).
However there are cases when you need to reverse this scaling - for example a Viewport3D must be scaled back 1/X to correctly show inside the scaled up container. Otherwise pixel level artifacts will show, image quality will be awful.
This scale up/scale back technique works nicely.
U can do something like this to change the root TLayout:
with 100 being the default
if windowsscale>0 then begin
LayoutScale.height:=ClientHeight*100/windowsscale;
LayoutScale.Width :=Clientwidth*100/windowsscale;
LayoutScale.Scale.X:=windowsscale/100;
LayoutScale.Scale.Y:=windowsscale/100;
end;
Recently I've discovered that TCanvas.StretchDraw will not work as expected for object which is a TIcon instance (quick look at TIcon.Draw and DrawIconEx method tells why). Delphi help acknowledges that fact. I know the workaround but I do not know the reason behind such design decision in VCL. Does anyone know why they decided to left TIcon untouched in this matter?
Icons are not regular bitmaps. This is mostly due to historical design and technical reasons.
It did make sense at time when icons were small 32x32 pixels large and 16 colors (good old days!) that icons were never to be stretched on screen.
But there is also a "common sense" technical reason. Such small bitmaps are usually very hard to be re-sized by an algorithm (and default GDI strech algoritm is very fast but produces also very bad result in respect to other interpolation modes, e.g. available with GDI+), so it was decided to embed a set of icons within the executable, as resources: one icon per size. The strech process benefits of being done at design time, at pixel level, by an icon designer. And - back those days - it was also much less resource consuming to use dedicated icons, with a reduced color palette.
Since you are supposed to have a set of icons with a pre-defined size for each, you do not need to use StrechDraw, but just select the right icon to display.
So if you want to display an icon with a given size, ensure you pickup the right size, or get the biggest icon and upsize it, using a temporary bitmap - or DrawIconEx(). Or, even better, do not use icons, but a bitmap, or a vectorial drawing if you expect huge picture size.
I use a non-default Windows colour scheme on most of my machines, and have a laptop with a 124 DPI screen, which Windows is set to.
A lot of programs I tested or even use daily seem to have problems with that, showing for example non-standard sizes of controls, cut-off UI elements, unreadable text and so on. There is the whole range from slightly annoying to (nearly) unusable.
Now I feel that a lot of these issues are unnecessary. A simple test run on a high-resolution screen in a few colour schemes would show them, some of them are even very easy to correct (like always using clWindow, clWindowText and clBtnFace instead of clWhite, clBlack and clSilver). Some of them are harder, like proper control sizing.
So my question is: Do you try to follow the recommendations in the UI guidelines regarding system colours, sizing and spacing of UI elements, and font sizes and faces? Is testing for compliance to them part of your QA process? Do you even try to lay out your forms in dialog units instead of pixels, even though most of the IDEs (Delphi in my case) have pixel-oriented designers?
[EDIT]: On re-reading this after sleeping I notice that this question may look like an invitation for fruitless discussion. It is not meant that way, I'd definitely be interested in tools to help me create applications that conform to the UI interface guidelines, an area where I feel Delphi is letting me down a little. See also my own answer.
I definitely don't. It costs time that I prefer spending on improving the experience of many rather than the few who use non-standard windows settings. A few things I usually do, which should still fix some of these issues:
use clWindows etc. because that's the standard for Delphi controls anyway, so why change it?
place labels above entry fields rather than to the left, which should solve many size problems
make sure the forms resize properly, by setting the anchors
make sure the tab order is correct (which can become a major annoyance if not done)
But I certainly don't take the time to set up test computers with odd resolutions and colors, or even worse, change my development box to use them (which will screw lots of things that again take time to reset properly).
If a paying customer reports problems with non-standard settings, it depends on the customer whether they will be addressed. If he orders 100 licenses, his chances are good. If he uses these settings because he is visually impaired, his chances are good. If he makes it part of the requirement, I will do it, but charge for the additional work.
Today, so much software doesn't work properly at a non-standard DPI that I don't think it's worth trying to fix it. The trouble-shooting FAQs for many applications just instruct users to switch to a normal font size for related problems. Microsoft acknowledged lack of proper DPI support in 3rd-party software and redesigned the display scaling methods in Windows Vista, where all GDI operations are scaled on a low level instead of relying on applications being aware of the DPI setting.
Final answer: it depends on your software's audience. If your software is likely to be used by disabled users, it might be worth the effort.
Apart from using the proper colour constants for standard colours I invest some extra effort for applications that we need to use internally on high DPI screens, or where customers may need this.
I have a unit with helper functions for determining proper sizes and placement margins, which compute these from the default GUI font and the standard values in dialog units as given in the UI guidelines, and with helper functions to compute the maximum width / height of an array of controls, place controls, things like that. For fixed size forms and dialogs I calculate the placement of controls once after translating their text with GNU gettext, for resizable forms I do this in an OnResize handler.
This gives good results, is however time-consuming. I would like to have something like the wxWidgets sizer functionality, which automates resizing once the minimum size of a control is set. I have never seen something similar for Delphi, though.
I occasionally test it myself for large fonts, because my Vista laptop is set to Large Fonts. Colors, not so much, but I rarely specify colors on controls.
However, proper resizing is pretty hard. I usually set Forms scale to false, so as that they won't resize wrong.
There are a few tools for auto-resizing forms. I did look into them, but never got around to testing them properly:
TFormResizer
ElasticForm - ironically (given the component's area) most of the text in this page won't show up in Chrome...
JVAutoFormSize (in JVCL - doesn't seem to be very useful from what I read)