I have positioned a nested form on the applications main form along with another control and a TSplitter, as stated in my previous question. If you look at that question, the part labelled "design forms here" needs scrollbars.
No matter whether I set scroll bars programatically to be visible or use the AutoScroll property - I never see the scroll bars !! Grrrr!! I was wondering if something else that I am doing could be removing the scroll bars. For instance BorderStyle := bsNone;
It's not that - when I comment it out I still don't see scrollbars, but that has got me thinking .... any ideas?
Is there a reason to use a nested Form on the right side? I tried it with a TScrollBox instead (alclient) and the scrollbars appear as expected...
Related
I do not want to show the dots in a TabControl interface, when I change the properties of TabControl, TabPosition: Dots ... I just want to handle it with gestures.
Set the TabPosition property to None.
It can seem misleading because the dots still show up in design mode to simplify moving from page to page when designing, but they will not show when running.
I noticed that the resize flicker gets much better when I set TPanel.FullRepaint to False. Since the property exists and is True by default, there must be some reason for that.
How to decide whether it should be set or not?
The help just states:
FullRepaint controls how the panel responds when it is resized. When FullRepaint is true, the entire panel, including the beveled border repaints when the size changes. When FullRepaint is false, only the area inside the beveled border repaints.
http://docwiki.embarcadero.com/Libraries/XE3/en/Vcl.ExtCtrls.TPanel.FullRepaint
That text says what it does, but not why ...
The effect of a missing Fullrepaint can be shown and you will have to decide if you need it or not.
Place a panel on a form, set anchors to all directions
Set PaintCaption to false or use a empty caption
Place another panel on the form, so that if you are resizing the
form, parts of the first panel will be covered by the second panel.
Run the program and size the form, somtimes the borders of the first panel will not be refreshed.
This happens because in WMWindowPosChanged in case of (FullRepaint or (ShowCaption and (Caption <> ''))) a invalidate will be called, otherwise only InvalidateRect(Handle, Rect, True) of a rects only containing the right and/or bottom border are invalidated. (thanks to Sertac Akyuz for correction)
As you mentioned avoiding invalidate reduces flicker and in many cases the need for a full invalidate is not given, so the user can decide on his own how to proceed.
Panels as the rarely will be used, upper without Fullrepaint
In previous versions of Windows (not sure up to which version, exactly) FullRepaint was required to prevent graphical artefacting on panel borders when a form was resized.
To the best of my knowledge, this hasn't been an issue since at least Windows XP.
I have a form with several splitters and panels. In the middle is a panel that ends up with a TWebBrowser set to align alClient.
In the past this has worked well. However, on Windows 7 with Internet Explorer 8 the the browser is not correctly resized. Everything else (i.e. the panels) are the correct size, just not the web browser. Sometimes when you click into the browser, or more often when you scroll the browser will jump to the correct size. That does not happen 100% of the time though.
I'm trying to deal with the resize directly and force the control to change size. I can't seem to find a method that makes any difference (i.e. .Invalidate; .Repaint; .Update;)
TWebBrowser is an OLE control (ActiveX) that wraps the Internet Explorer control. Any ideas on how I can make the resize happen?
Updated Background:
I narrowed this down to only happening when I have a child form that I change the parent to site it inside another form. My TWebBrowser control is on a child form that I use anytime I need to show an HTML document.
In my parent form I have a Grid, a splitter, and a panel with the grid set to Align top and the panel set to align client. My child form (called THtmlViewer) has its parent set to the panel. The THtmlViewer form is set to alClient and TWebBrowser control on the child form is also set to align client.
If I do anything in the form resize of the THtmlViewer form I run into this issue. Anything being directly in FormResize or indirectly using the align properties. However, if I call my resize from the parent form everything works fine.
The key seems to be turning off the resize code in the THtmlViewer form. If I leave a OnResize handler or the alignment set then it does not matter what I do in the parent, the resize is not done correctly.
I am still confused why this is needed and why I can't force it to update in the correct resize (THtmlViewer).
As a side note I also noticed that Delphi 2007 on Windows 7 has the exactly same problem with the "Welcome Page" in the IDE.
I have worked around the issue by adding a method to set OnResize of the child form to nil and then call my internal ForceResize from the parent's OnResize handler. I would still like to deal with this all from the THtmlViewer form and would accept an answer that let's me avoid this hack.
To resize controls when their container changes size, you have two other options besides using "just" the Align property:
Use the Anchors property without the Align property, that is, set the Align property to alCustom or alNone, then set the anchors according to your needs. As the Align property is sort of short-hand for setting the Anchors, this is dependent upon the same alignment processing so may not work in your case.
Provide a handler for the OnResize event of the container on which the TWebBrowser sits and manually set the TWebBrowser's height and width to those of the container (optionally adjusted for any margins you want to have within the container).
That said, I don't have Windows7, so I can't vouch that this won't take more twiddling.
If your TWebBrowser jumps to the correct size on a scroll or click, it indicates that the control was sized correctly, just never received or processed the messages to actually respond to the changes.
This can be because realigning controls tries to prevent unnecessary repaints and recursions and somehow got mixed up. Using the OnResize method may then get better results as it "speaks to the TWebBrowser directly".
Repaint is "just" shorthand for Invalidate and Update unless the control has csOpaque in its ControlStyle, in which case painting seems more immediate. So you could try to fiddle with the Transparent property of the TWebBrowser and/or the container it sits on.
If all else fails, you could try to send a WM_PAINT (or similar) to the TWebBrowser directly. For exmample in the OnResize event of the TWebBrowser or the container it sits on. The a WM_Paint handler of the TWebBrowser calls OleDraw, which talks to the ActiveX directly using the ClientRect, which should have the correct dimensions when called from an OnResize event.
I had a similar problem.
It was solved by putting a TPanel "underneath" the TWebBrowser, and aligning the web browser to alClient.
Maybe the same solution for this question works: Resize problem using AcroPDF in Delphi
In OnResize:
if Visible and (WebBrowser1 <> nil) then
begin
FocusControl(nil);
FocusControl(WebBrowser1);
end;
I'd try something like
changing WebBrowser1.Align to alLeft,
setting WebBrowser1.Width to WebBrowser1.Width - 1 and
setting WebBrowser1.Align to alClient again
in an OnResize handler.
I have an application that uses a frame extensively and needs to hide/show certain buttons depending on which form is active at the time. In order to keep the buttons neat and organized appropriately, I have put them on panels and show or hide the panels as needed for each form. My problem is when each form is initially created, the panels on the frame are out of order even though I am explicitly telling them which order to put themselves into. After I hide and re-show the form, the panels are in the correct order. Any suggestions on how to keep them in the proper order from the very beginning?
Instead of giving the panels explicit positions, try giving them alignments. They tend to stick better than way, and they do a better job of resizing if you resize the form.
You can also try using a stackpanel (or was it flowpanel?) as parent for the panels. Then you will have a order instead of a position to manipulate.
Maybe you can have a look at the DevExpress LAyoutControl? It helps us creating interfaces that always look good, no matter if we show or hide certain groups / panels. It even allows for run-time customization of the interface, if you want that!
You may try to organize them by coordinates i.e.: setting Top and Left. Unless your panels are aligned, this will always work (but it takes bit lot of work).
I had this problem and I found that the solution was to do this in FormCreate (or in a CMShowingChanged method of your frame):
MyPanel1.Align := alNone;
MyPanel2.Align := alNone;
MyPanel1.Align := alBottom;
MyPanel2.Align := alBottom;
Restore in the order that you need - this seemed to sort out the order visually.
I'm having a problem with a component I use.Its aligned to bottom ,and ,when form is maximized,the control is placed at the correct position,but when I attempt to minimize the form,the control stays at the position where it is.
I tried using a timer that always sets the align to bottom,but I'm sure a timer is the worst solution to my issue.
Please suggest a way to set the align to Bottom when the form is restored from maximize.(maximize->restore only).
My current idea is to check if form is maximized at FormResize event,but that won't work,because I need to do it when its restored,not maximized.
You can check if a form is maximised by using
Self.WindowState = wsMaximized
Other states are
wsNormal
wsMinimized
wsMaximized
Depending on what you are doing, you could also place the control on a panel and align the panel to the bottom of the form, if you turn the borders off and use the parent colour, you cant see the panel, that way it will stay at the bottom of the form without additional code.