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.
Related
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.
On some programs there is an interesting possibility:
in case the work area is very large, there is the overall picture, which provided by the plan of all component.
Which component allows you to add this capability to my program?
I would like to implement this, at least for StringGrid and TChart.
To do this in a generic way, you have to do off-screen painting.
That is a lot of work, especially getting the details right.
JED Software once write something similar to show previews of forms in the IDE called Visual Forms and it took them a long time.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Replacing a component class in delphi
Does anyone have any tips for modifying the VCL components and making them so they are relatively default within the IDE? This means not necessarily descending from them, but changing functionality in places that don't seem to allow such things in a descendant object. And if they can be used in place of the standard components, that's a bonus as well.
For example, one of the things I'd like to do is an alpha blended mouseover on a TButton. I notice no OwnerDraw event and the code to modify how the button was drawn seems to not be in a place that I can override. Any suggestions, or would I have to strip TButton and all its ancestors out of the VCL code and modify it directly?
You can choose one of the following methods:
Override ReadState of your form, as explained here
Use an interposer class, as explained here and here
Assign a new WindowProc, as explained here.
You are making several questions related to developing custom V.C.L. controls.
Since, its a very extended topic, you may want to browse or search the internet about it.
As a fast question, there are several ways to develop or extend a control.
Sometimes, the same control can be developed in different ways,
other, it depends the kind of control, that you want to develop.
You also mention how to make a control, interact with the Delphi I.D.E.
Delphi controls work with packages, you can make a package with plain libraries without controls, you may want to start doing that, before making a control.
You can make a control, that doesn't interact at all, and only works by running the application, and later add interaction with the Delphi I.D.E.
In Delphi, when you develop a control and want to put it on form, while designing, internally, its like Delphi was your application, and already have your control.
If you want to change the appearance of all TButtons in your application, you can do it without modifying the VCL at all. I see no necessity to modify or even subclass a VCL control yourself, when a few hundred button components exist out there. For example, for alpha-blended mouseovers, just check out the TMS controls.
However, for do-it-yourself techniques; Method one (recommended as simple) is to simply take all the TButtons out of your application and replace it with something else. VCL component replacement (globally) is easily done via gExperts. To see how to combine a standard control appearance (how a button looks) with some overlaid elements drawn in Delphi code, see TBitBtn as a sample. Rather than subclassing TButton or TCustomButton, I recommend you examine TBitBtn sources, and start from it.
Method two (not recommended as simple) is to start using a skinning system which can draw a completely different appearance over standard controls.
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.
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