I want to use tabs in a FMX form. In VCL all is functioning as expected. In FMX I tried tabs with labels and buttons without success. HitTest is true, no other controls are on the form. The surrounding frame does not appear and pressing the TAB key does nothing. With edit fields it is working. Did I miss something? Current system is Windows 11 Pro 21H2 and Delphi 10.4.2.
To tab to a TLabel, set its CanFocus property to True. As this property is public, not published, you'll need to do that in code, such as in the form's OnCreate event or by overriding the form's Loaded method.
Related
I have a form with a speedbutton linked to a TMultiView component.
On the multiview I have some buttons. When clicking on any of the buttons I want the multiview to close and depending on the clicked button, different functions to be called. I have tried to set the Visible property of my MultiView to false, but the shadow over the form then remains. If I click on the speedbutton again, then menu disappears, and also the shadow, as expected.
Is there a way to solve this?
I'm using Deplhi XE 8.1
Multiview.HideMaster will close the multi view. Call this whenever/wherever you want the multiview to close.
I am trying to add a ToolTip (or hint as Delphi refers to it) to the buttons on the ribbon. I am using the TRibbon that comes with Delphi XE7. I am developing in the VCL framework.
I did find a Hint property in the Action that is linked to the button on the Ribbon, but I cannot get the Hint to display.
So it seems that the correct answer is to set ShowHint = True on the form.
First, I'd check if the form (and possibly the ribbon) have ShowHint = True.
I use Delphi7. I use custom memo control, TSyntaxMemo component.
I see that many apps (Notepad, Notepad++, uTorrent, ...) use standard popup menu for scrollbars:
scroll here
up
down
page up
page down
scroll up
scroll down
(this is list for a vertical bar).
How can I use such menus for scrollbars in "my" memo? W/o doing these menus by hands.
You don't have to do anything at all to make that menu show in a Windows EDIT control. That's a standard system menu implemented by the control. It appears on a TMemo added to a vanilla VCL forms app, since TMemo is simple a wrapper of the multi-line variant of the EDIT control.
Here's all I needed in my .dfm file:
object Form1: TForm1
object Memo1: TMemo
Align = alClient
ScrollBars = ssVertical
end
end
This is functionality provided by the system. If your control is not behaving that way then I can think of the following reasons why that happens:
Your control is not a Windows EDIT control.
Your control is an EDIT control but it is not using the default message handler that results in this menu.
If item 1 is the reason, then there's nothing you can do to get the system display the menu. If your control is not an EDIT control you can hardly expect it to magically behave like one. In the case of item 2, you need to work out how the control is stopping the message that leads to the menu being handled by the control's default message handler.
I have inherited an application that was started as an MDI program, but the necessary background work was never put in place to fully support MDI. I'm trying to build in just enough MDI support to make the application look good and work properly as an SDI application.
Here's what I am observing, and I don't know how this is happening or how to fix it.
The MDIchild form's border is shown above the MDIparent form's menu strip.
The MDIchild form has two icons in the upper left.
The MDIchild form has two ControlBoxes in the upper right.
Any ideas why this would be?
I'd be really happy if the MDIChild window border (including the icons and control boxes) was removed entirely.
Thanks,
SH
I created the child form but showed it in normal state instead of maximized. It's as if showing the parent form in the same process as the maximized child form caused the form to be constructed out of order. My code looked something like this...
frmChild.WindowState = FormWindowState.Normal
frmParent.Show() 'frmChild.Show called within form_load of parent
frmChild.WindowState = FormWindowState.Maximized
And yes, I set the Child window's FormBorderStyle to None, but like I said, I didn't want an MDI application.
I think this must be a bug in Visual Studio. For so many people to have difficulty with it, it can't be right.
I found:
Call Show() on your MDI form before setting the WindowState property on your child form to get rid of the multiple control boxes.
Do not set the WindowState to Maximized in the designer -- do it in code after you've shown the parent.
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.