I've got an app that runs a long set of operations, and I'm trying to use a TProgressBar to keep track of what's going on. I set a number of steps, and call .StepIt to increment the progress bar.
Problem is, it doesn't keep up very well. Instead of jumping directly to the correct position, it seems to like to slide gradually up to it. That's all well and good if it's eye candy you're after, but when I'm trying to get an accurate representation of my routine's progress, this makes it appear to be constantly lagging behind the true status. How can I turn that "feature" off?
I only notice this happening under Windows Vista. Not sure if it's also going on on XP or not, because when I test it on XP, the process goes a lot faster and it's over too quickly. :P But this may or may not be Vista-specific. Either way, it's driving me nuts. Does anyone know how to fix it?
I have a quick but partial and inelegant solution, if you don't mind having the progressbar yellow instead of green:
ProgressBar1.SmoothReverse := True;
ProgressBar1.State := pbsPaused; // for yellow or pbsError for red
Or if you don't mind loosing the vista/theme look and go back to a flat blue one:
UxTheme.SetWindowTheme(ProgressBar1.Handle, ' ', ' ');
The real "problem" according to Microsoft is that you try to "pervert" a ProgressBar into a Meter which they claim it is not.
You could also try to draw it yourself ;-)
Same problem on Windows7 !!
But the answer was already in one of the older posts:
If tou make the progressbar step backwards there will NO delay !!!
So I implemented this..... (and get instant updates)
if(progress < ProgressBar.Max)
then
begin
ProgressBar.Position := progress+1;
ProgressBar.Position := progress; //This will set Progress backwards and give an instant update....
end
else
begin //cannot set position beyond max...
ProgressBar.Max := progress + 1;
ProgressBar.Position := progress + 1;
ProgressBar.Max := progress; //This will also set Progress backwards also so instant update........
end;
I ran into exactly the same problem a while ago. After searching Google for a long time, I found that it is a Vista-specific problem. It seems to boil down to this: Microsoft added fancy animations to the progress bar control in Vista (i.e., the moving 'highlight'). To make updates more smooth, they implemented some sort of 'lagging' in the repaint of the control --- and this basically screws the whole progress bar control. Rather annoying, I'd say, especially since there doesn't seem to be a decent solution.
See for more details the replies by Arvid Winkelsdorf to this Embarcadero Discussion Forum post:
It's the same for VB, C++ and C#
somehow as the problem lies in the
Vista drawing of the new animated
ProgressBars. To provide a smoother
visual feedback drawing is delayed
when moving forward. Your application
cannot be sure that 100% will be
reached at any given time.
By setting the position back to a
smaller value, the ProgressBar drawing
is forced to jump back. No delay in
getting to a position smaller than the
current. So you'll have nearly 100%
immediately. Afterwards set to the
maximum and you'll have exactly 100%.
[...]
There is a similar glitch when using
the new Vista ProgressBar Styles like
PB Paused or PB Error. If the bar is
still moving (MS part) and your app
sets the color to paused by
SendMessage (like in D2009) the
message will be ignored by the
ProgressBar.
Maybe you can try to set the position of the ProgressBar directly instead of using the StepIt procedure. I'm on XP with Delphi 7 here, so I can't test it, but looking at the code of TProgressBar it uses a different message (PBM_SETPOS instead of PBM_STEPIT). So maybe it sets the position of the progressbar without an animation.
Additionally there are several 3rd party components which provide better Progress bar implementations that still render nice on Vista. Personally, I prefer the one from Raize components which works quite well. It doesn't "lag" like the windows control does and works independent of any theming.
If you don't really want anything fancy, then you can always build one yourself using a panel and a tshape aligned left inside the panel. Resize the tshape to be a % of the panel it sets on.
I had the same problem, my solution was to switch to another control available in the VCL :
I choose to use the Range of TTrackBar to display the progression.
(with slider off and control resized to hide the range marks).
Not the same visual (particulary if themed), but it fit well my need (no lag).
Here is a simple solution:
ProgressBar.max := ProgressBar.max +1;
ProgressBar.StepBy(2);
ProgressBar.StepBy(-1);
ProgressBar.max := ProgressBar.max -1;
Related
I'd like to highlight my toolbar icons when their associated action has it's "checked" property set to true. I'd like to do it in a manner similar to how Microsoft Office 2003 did it, e.g. see the Bold and Align Left icons in this image:
The image is drawn with a box around it and the background has been changed to orange.
How could I implement this using Delphi 2009?
As a bonus, is there also a way to do the same thing with the icon in the menu for the associated item? e.g. as below with the Ruler and Markup entries:
Followup:
Thank you Andreas, for what is a simple and correct answer to my question. As a Delphi 4 programmer converted to Delphi 2009, I was not familiar enough with the VCL additions of Delphi 5 to 7, so the TActionManager, TActionToolbar and their workings were not in my Delphi vocabulary. And this is based on Delphi's ability to use a style that is akin to a Microsoft O/S's theme.
However, with your answer, and a bit of research using it, I confirm that I do not want to do this in this manner. An illuminating Embarcadero thread re: Popup menus: "Checked" items with icon no longer shown as sunken? with Peter Below contributing his expertise, made me realize that I don't want to change to the XP theme at all, since that will do baaaaad things to Vista and Windows 7 users, taking them back to the Bronze Age.
The true culprit here is that there are certain things that the O/S themes want you to respect. Delphi tries to follow the rules. I can go back to XP, the XP style/theme, and the XP Color Map. In this mode, checked items will be hilighted. And this is really all I wanted - to highlight the checked items. I used Office 2003 as an example, because it was the sort of hilighting I wanted. But I really didn't want to entirely change themes and force an entire new look on my program. It would especially make things look unnatural for Vista and Windows 7 users.
What would be ideal is if I could have another set of Images that would apply when the object is Checked ... but there is not a "CheckedImages" property. Or a way of programmatically or automatically modifying the image if it is checked (e.g. like disabled images get a grayscale version of their enabled image).
I still wouldn't mind hearing from anyone if there are any ways to implement this or something else that might work equally well, without changing the entire look of my program.
Add a TActionManager to the form, and create some actions (e.g., bold, italic, and underline). Make sure to set the AutoCheck property to true for each action. Then add a TActionToolbar. Double-click the action manager, and drag the three actions to the toolbar. Now add a TXPColorMap to the form, and assign it to the action manager. Also add a TImageList and add icons for bold, italic, and underline (from C:\Program Files (x86)\Common Files\CodeGear Shared\Images\GlyFX\Icons\BMP\16x16). Assign the image list to the action manager.
Set the toolbar icons to show only the glyph and not the caption. Finally, set the ActionManager's Style property to XP Style. The end result is what you seek.
One can also use an ordinary TToolBar, with DrawingStyle set to dsGradient, I just found out.
Without changing the entire theme, I think this is something that might work half decently:
Add extra images to the ImageList, so that for a given action, there are two (or more) images to choose from.
Instead of changing the "checked" property to true or false, change the ImageIndex to the alternative image, e.g.:
if WS = 1 then begin
ElTree.Align := alTop;
// TileTopBottomAction.Checked := true; --- take this out
// TileLeftRightAction.Checked := false; --- take this out
TileTopBottomAction.ImageIndex := 47; { hilighted image }
TileLeftRightAction.ImageIndex := 14; { regular image }
end
else begin
ElTree.Align := alLeft;
// TileTopBottomAction.Checked := false; --- take this out
// TileLeftRightAction.Checked := true; --- take this out
TileTopBottomAction.ImageIndex := 13; { regular image }
TileLeftRightAction.ImageIndex := 48; { hilighted image }
end;
Now the images will look like this on the toolbar:
and like this on the menu:
The nice things about this method is that it also works on the menu, and you can have multiple images to represent what you want. Also, it will not wreck the theme (XP, Vista, Windows 7, etc) that the program has taken on.
The disadvantage of this method is: You are limited to 16x16 image area to play with and cannot draw a box around it that are outside those limits as happens when you set the "checked" property to true.
Is there a way to change the position of the window that pops up when cv::imshow is called?
For me, the window seems to appear partially off-screen, so I have to drag it around before I can see entire image. It's very annoying to have to do this every single time.
I had a look at the reference manual -- it seems you have control over what goes into the title of the window, but I can't see anything relating to window position.
Oh, and the behavior is the same if I use the old C interface (cvShowImage).
Any ideas?
As of OpenCV 2.1 this is possible also in C++ API using the moveWindow function:
cv::moveWindow(std::string winName, int x, int y)
For example:
cv::namedWindow("WindowName");
cv::moveWindow("WindowName", 10, 50);
Using C++ API it is not possible at the moment.
You can use C API instead; it is cvMoveWindow().
UPDATE: Now it is possible in C++ with cv::moveWindow()
So, Im using D3D in a windowed application.
I inited D3D with the following parameters:
windowed: true;
backbufferformat: D3DFMT_X8R8G8B8;
presentinterval: D3DPRESENT_INTERVAL_ONE;
swapeffect: DISCARD
Each time OnPaint is called, I render the image to the backbuffer and present it to front.
As far as I know (and so does MSDN say), once I set D3DPRESENT_INTERVAL_ONE, vsync will work.
But in this case, the image is teared when dragging horizontally.
(It seems there's a line across the image, image below the line shows on the monitor and the above part follows.)
Some sites say D3DPRESENT_INTERVAL_ONE will not work in windowed applications.
How can I enable vsync anyway?
p.s. I finally found D3D vsync is enabled, while some window settings are not right that perhaps the window itself is not sync ed. though, I haven't peek the settings out.
I assume you're using D3D9? Should add that tag. On your D3DPRESENT_PARAMS variable:
if (bVysncEnabled)
{
presentParams.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
presentParams.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
}
else
{
presentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
presentParams.FullScreen_RefreshRateInHz = 0;
}
If you've done this and you're using the old GDI stuff, it's not your vsync setting that's wrong, but the window settings. You must enable double buffering or you'll still get tearing.
You cannot vsync while in windowed, only in fullscreen. However, you could potentially ghetto it by getting info from the default display and finding the refresh rate, and then nerfing your renderer to only render at that rate...although I wouldn't suggest that route.
Windowed historically haven't been able to be vsynced for d3d, and only recently has this been possible, when aero is enabled in WinVista or Win7 and the app isn't running in presentation mode immidiate.
How often do you call ::OnPaint ? The reason I am asking is, that you must be calling ::OnPaint more often than the refresh rate of your attached monitor.
For me, I solved the refresh issue by forcing an ::OnPaint whenever the message loop is idle with invalidating the window. What will happen if you do that, is, that the RenderPresent command for D3D will WAIT until the graphic card finished rendering, which gives you a very precise timing of the ::OnPaint in sync with the actual monitor refresh rate !
I am having good success with this, and the statements above that windowed mode cannot vsync is definitely not true. Even in DirectX 9 Win XP, this just works.
Oh and last but not least, if you have more than one display attached, make sure to vsync with the actual display which presents your window. This seems a bit more tricky.
not exactly D3D, but AntiTearing.html describes how MPC-HC uses windowed EVR et al to try and avoid tearing of a windowed display. The links here: http://betterlogic.com/roger/2012/05/gdi-vsync-to-avoid-tearing/ may be useful for synchronizing, too (albeit something of a work around).
My application does automated screenshots of several dynamically created forms. This works perfectly under Windows XP, but doesn't work well under Vista Aero. Most of the forms appear semitransparent in the screenshots. The problem lies in the window animation of Aero.
How can I check/disable/enable this animation from inside a Delphi (2007+) program?
Or as an alternative: How can I make sure the form is displayed properly before making the screenshot?
The link in the comment from Shoban led me in the right direction. A quick check showed a wrapper for the DwmApi in the VCL and from that it went straight forward. Here is the code I successfully use now:
uses DwmApi;
...
SaveDwmCompositionEnabled := DwmCompositionEnabled;
if SaveDwmCompositionEnabled then
DwmEnableComposition(DWM_EC_DISABLECOMPOSITION);
...
if SaveDwmCompositionEnabled then
DwmEnableComposition(DWM_EC_ENABLECOMPOSITION);
Disabling Aero would be a pity - in general it's not a good idea to change the user's choice of UI style.
You may be able to draw the form another way. One thing that comes to mind is using the PaintTo method to paint it to a canvas. (In fact, if you're taking screenshots of the forms as a way of getting what it looks like you probably don't need to show the forms at all - created them with Visible set to false and paint them to a bitmap. Only show them if the user needs to interact with them.)
I was trying to solve the same problem and found this question, but came up with a completely different solution. It doesn't disable the animation, but it allows you to make the window disappear without animation effect.
var oldWidth := Self.Width;
var oldHeight := Self.Height;
try
if Visible and (Self.WindowState <> wsMinimized) then
begin
Self.BorderStyle := bsNone; // do this first
Self.Width := 0;
Self.Height := 0;
end;
//.. Do your screen capture here
finally
if Visible and (Self.WindowState <> wsMinimized) then
begin
Self.BorderStyle := bsSizeable; // or whatever it was
Width := oldWidth;
Height := oldHeight;
end;
end;
You could also move the window to -maxint for X & Y, but I like this better.
You can add a manifest resource to the exe file, to notify Vista you want that the application runs without Aero
http://www.google.be/search?q=vista+manifest+resource+delphi
I have a bit of a problem setting up my DirectX10 (Win32/c++) application for fullscreen mode. The problem is that I want to have my app running in fullscreen right from the start. This can be done by taking the DXGISwapChain::SetFullScreenState function. This works, but i get a small notice in my Visualc++ 2008 debugger which states:
"DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH."
What this means is that DirectX will not take full ownership of the graphicscard and flip the images from front to backbuffer but instead blit them which is much slower.
Now, i do have the DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH enabled and i did try to resize my buffers but i have absolutely no idea what would be the best way to go into fullscreen mode. I have looked on MSDN but there they mostly assume you will only go into Fullscreen by pressing Alt+Enter which lest DXGI do all the work. If someone please could post a bit of code which takes DirectX10 into fullscreen mode and takes full advantage of the "flipping" it would be greatly appriciated!
For anybody interested in the code used on resize:
ReleaseCOM(m_pD3DRenderTargetView);
ReleaseCOM(m_pD3DDepthStencilView);
ReleaseCOM(m_pD3DDepthStencilBuffer);
DXGI_MODE_DESC* mod = new DXGI_MODE_DESC;
mod->Format = DXGI_FORMAT_R8G8B8A8_UNORM;
mod->Height = m_ScreenHeight;
mod->Width = m_ScreenWidth;
mod->RefreshRate.Denominator = 0;
mod->RefreshRate.Numerator = 0;
mod->ScanlineOrdering = DXGI_MODE_SCANLINE_ORDER_UNSPECIFIED;
mod->Scaling = DXGI_MODE_SCALING_UNSPECIFIED;
delete mod; mod = 0;
m_pSwapChain->ResizeTarget(mod);
HR(m_pSwapChain->ResizeBuffers(1, m_ScreenWidth, m_ScreenHeight, DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH))
throw(Exception(GET_BUFFER_FAIL, AT));
//problem area
m_pSwapChain->SetFullscreenState(TRUE, NULL);
ID3D10Texture2D* pBackBuffer;
HR( m_pSwapChain->GetBuffer(0, __uuidof(ID3D10Texture2D), (LPVOID*)&pBackBuffer))
throw(Exception(GET_BUFFER_FAIL, AT)); //continues as usual
Is there any reason you delete your mode desc?
Have you also tried putting your mode desc through "FindClosestMatchingMode"?
Check out http://msdn.microsoft.com/en-us/library/cc627095(VS.85).aspx The "Full-Screen issues" section contains a lot of useful information.
There are some prerequisites for enabling flipping in DXGI (which is the most efficient fullscreen presentation mode):
1) You should go into fullscreen state specifying a mode that exists in the system (you could do that either by using mode from IDXGIOutput::GetDisplayModeList or finding it using IDXGIOutput::FindClosestMatchingMode). Your code just specifies screen resolution, so most likely mode is set correctly.
2) After SetFullscreenState, you should call ResizeBuffers with the right buffer size matching mode, this is where DXGI would setup flipping mode.
Typically, it should happen naturally as reaction to WM_SIZE message send by SetFullscreenState transition, so if your app doesn't call ResizeBuffers on WM_SIZE, it probably should.
You can call ResizeBuffers manually after SetFullscreenState and that should work as well.
And yeah, MSDN has a good article about DXGI practices, including fullscreen transition:
http://msdn.microsoft.com/en-us/library/cc627095(VS.85).aspx#Full_Screen_Issues