This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Windows 7 Aero Theme Progress Bar Bug?
Ever since Windows Vista, I have noticed a bug/problem with the TProgressBar in Delphi.
The problem is the progressbar never seems to fill up to 100%, sometimes it gets to maybe 70% - 80% before the progressbar thinks its hit the max, i.e 100%
I have been reading on various websites and infact, the progressbar has complete its operation. But it seems that there is a bug in the Delphi VCL which is not rendering the progressbar accurately, so when it appears to be complete but is actually not, this is because the painting of the progressbar is not accurate.
If the above is true, which seems a valid reason - I have not found a solution to this. Whatever the operation which involves a TProgressBar, it never fills up 100%, it only fill maybe 75% of the way.
How can I get the TProgressBar to fill up accurately?
To add, I have tried replacing the TProgressBar with say a progressbar from the JVCL and those non standard VCL components work correctly. So it is not a problem with how I am dealing with the progress, it is either Delphi or Windows - or both.
Yes, I could just use said alternative but if possible I would like to know how to fix the standard TProgressBar.
Thanks, Craig.
This is a feature of Vista themes. The only known way to work around this feature is to go backwards during an update.
Every time you set the progress bar counter to N immediately afterwards set it to N-1.
There's nothing wrong with the Delphi code, it's a feature of the common control.
Related
I am using Embarcadero C++ 10.3.2.
I switched my VCL buttons to use TVirtualImageList, and this greatly improved their scaling behavior.
Unfortunately, now the buttons appear on the Form at runtime extremely slowly, one by one. I am guessing this is due to the internal scaling of the icon images, as regular buttons behave normally.
I made the buttons the same size as one of the standard image sizes in the TVirtualImageList, but this made little difference. It happens whether the screen is scaled by Windows or not.
Is there any way of speeding this up?
I have a Delphi XE2 Firemonkey application that I want to run on both iPad and iPhone. The iPad and iPhone real estate is different of course and I have been experimenting repositioning and resizing (visual) components according to the platform they are running on - triggered by the forms OnResize event. Started out changing the component "Margins" property with not much success (maybe that relates more to adjacent components...?) and then found the component "Position" property seems to do the job.
Question: Is the Position property the way to go? Or is there a more appropriate way using "Margins" (I seem to have read something about this somewhere, but can no longer find it). Or is there some other method, maybe not based on the OnResize event? (Yes, I am sure this is just 1 question.)
Brief details of the project - displays a costomer database record on the screen using around 30 components, mostly TLabel components, some buttons and search fields or 2 using TEdit's.
Thanks
Really depends on how differently you want to use the extra real-estate.
Do you want to display additional information, or just stretch everything out to use the space? If the latter, then you can use the Scale property.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Windows 7 Aero Theme Progress Bar Bug?
Ever since Windows Vista, I have noticed a bug/problem with the TProgressBar in Delphi.
The problem is the progressbar never seems to fill up to 100%, sometimes it gets to maybe 70% - 80% before the progressbar thinks its hit the max, i.e 100%
I have been reading on various websites and infact, the progressbar has complete its operation. But it seems that there is a bug in the Delphi VCL which is not rendering the progressbar accurately, so when it appears to be complete but is actually not, this is because the painting of the progressbar is not accurate.
If the above is true, which seems a valid reason - I have not found a solution to this. Whatever the operation which involves a TProgressBar, it never fills up 100%, it only fill maybe 75% of the way.
How can I get the TProgressBar to fill up accurately?
To add, I have tried replacing the TProgressBar with say a progressbar from the JVCL and those non standard VCL components work correctly. So it is not a problem with how I am dealing with the progress, it is either Delphi or Windows - or both.
Yes, I could just use said alternative but if possible I would like to know how to fix the standard TProgressBar.
Thanks, Craig.
This is a feature of Vista themes. The only known way to work around this feature is to go backwards during an update.
Every time you set the progress bar counter to N immediately afterwards set it to N-1.
There's nothing wrong with the Delphi code, it's a feature of the common control.
I wondered if you have a work around for the problems with docking forms in Vista, such as the close button being partially obscured, and the gray border when being dragged rendering extremely slow, making a appearing / disappearing appearance?
Delphi 2007 & Vista (64 bit)
I believe you have two different bugs here.
The obscured button thing is new to me. Don't think I've seen that one.
The second bug (resizing) is a known one, ie it was fixed in D2009, but there is a solution.
I found it in a JEDI VCL bug fix report and when I it applied to my code it worked great.
JEDI Issue Tracker Report
The fix can be non trivial for users of the native Delphi VCL docking system. If you're using a third-party docking system such as JvDock from the JEDI VCL it already has it supported. I implemented it in one of my major applications but I'm using a mixture of native VCL docking and third-party components.
I wanted to post you the solution I have but I got looking into my code and it spans a bunch of units and parts of the main code tree.
There is no simple answer except maybe you want to look at the JEDI docking system.
There is also another known bug with DockingTabs under vista, in that the obscured areas of a "docked" window when they slide closed doesn't repaint properly. Slide out works fine, slide in (hide) doesn't there is a solution to this one as well, but it requires modifying VCL source to make it work.
Sorry,
Ryan
Update: I've looked into the JVCL implementation of the docking, and I think it will work quite nicely, as it doesn't have either of the problems. Thanks again for your help.
Seams like this one is for real Delphi geeks only.
This is how it looks (sorry, can't post images)
Delphi IDE ugly toolbar
(source: piccy.info)
What's wrong - disabled Delphi IDE toolbar and menu buttons are ugly black/white images.
What I want to do - make them look gray-scaled.
How? I made some research. Main problem in virtual TCustomImageList.DoDraw method. When paramater Enabled = False it paints ugly things (see disabled buttons on screenshot). I created my own override for this function and it paints gray-scaled images when Enabled = False
Now I want to replace default DoDraw with my own in IDE (using design-time package):
I figured out that unit ImgList is compiled-in bds.exe, so trick with patching this function in rtlXXX.bpl will not work.
Searching for function's body content gave no result. Looks like bds.exe's implementation (I'm talikng about machine codes) of DoDraw is a bit different.
Any suggestions or ideas of how can I make this possible? As base example of runtime code patching I took Andy's Midas Speed Fix: FindMethodPtr, HookProc, UnhookProc
I made it :) Thanks to everyone who participated or viewed this question!
This is how my IDE looks now:
Fixed toolbar http://blog.frantic.im/wp-content/uploads/2009/11/delphi-ide-after.PNG
I just messed up with vclXXX.pbl, my fault. Sources can be found here. Gradient toolbars must be enabled to make it work. If you are interested in further development of this idea - read this topic
Maybe I'm understanding the problem badly but if you just want to override the DoDraw function why don't you just create your own component that inherits from TCustomImageList, override the desired function so that it does what you want and register it into the IDE?
If you don't want to make your own overriden components, you can change the realization directly in [DelphiPath]\source\Win32\vcl\ImgList.pas.
But it is really not a good way.
I've always disliked the way Delphi creates default disabled images from enabled one. This not only manifests itself in the IDE, but it does persist down to the application you're developing. The disabled images in your application look just as bad.
I have in the past tried to figure out what Delphi did to derive the disabled images and build on that. But it still is on my "things to do" list to finish that off.
None-the-less, these are some articles about the Delphi "glitch" that I encountered quite a while ago that may or may not help you:
Indistinguishable gray blobs in disabled menu items, by Vladimir S.
MenuImgList.pas
Fixing a Buttons Drawing Glitch in Delphi 5
Fixing a Menu Drawing Glitch in Delphi 4