I put some code that happens on a Form OnResize event. But it Seems to only call the event when the resize is bigger. Is there any way to change this?
Say i have
procedure TForm1.Resize(Sender: TObject);
begin
RePaint();
end
I would like to run repaint every time the form is re-sized (big or small). I guess you could add a check that checks width / height but if your going to do that why even use the event resize? Maybe there is another event besides resize that does both?
thanks
Glen
There are two questions being asked here.
First, OnResize is triggered when the form resizes, in either direction. Period.
Second, on why Repaint does not work when the form gets smaller is probably because you do your own painting. Normally, only Canvas.Cliprect needs to be repainted. When the form gets smaller, the shown area is not changed and the clipping area is empty. After all, there is not more to paint than there was before. When the form gets bigger in one direction, a similar thing happens: the clipping area consists of only the part which is added to the form's surface. Again, the previous shown area remains intact and is not updated. Only when the form expands in both directions, the clipping area cannot be made of a single rectangle any more, and so it becomes the complete surface.
The solution for you is to signal Windows to repaint the whole contents of the form at any resize, by calling Invalidate (or Update when it has to be repainted instantly), and to perform your custom drawing in the OnPaint event.
The OnResize event is triggered when the form is resized by any means, despite it is larger or smaller than before.
To prove this, create a new project, put a Memo on a clean form and add this code to the OnResize event:
procedure TForm1.FormResize(Sender: TObject);
begin
Memo1.Lines.Add(Format('%d,%d', [Width, Height]));
end;
Execute your project, and drag an edge of the form to make it greater and smaller, you'll notice it is fired always, and how many times the event is triggered also.
Notice also the form has a OnPaint event that maybe is what you're after.
Related
I have noticed something very strange. I am persisting the top, left, width, and height properties of a form when it is closing, and using this information to restore the form's last position when it is once again opened by calling SetBounds using the previously stored information. This works well, but only if the form's Position property is set to poDefault at design time. If set to something else, such as poDesigned, poScreenCenter, or poMainFormCenter, SetBounds does not restore the form's previous position and size.
Here's the strange part. What appears to matter is what the Position property is set to at design time. I can change the value of this property at runtime to poDefault and the call to SetBounds still does not work correctly. I have tried something like the following
if Self.Position <> poDefault then
Self.Position := poDefault;
in both the form's OnCreate event handler, as well as from an overridden constructor (and have set Position to poDefault in the constructor, and called SetBounds in the OnCreate event handler). In all cases, changing the form's Position property to poDefault at runtime does not fix the problem that I've observed with SetBounds. The only consistent pattern that I have found is that SetBounds works as it should only if the form's Position property was poDefault at design time.
There are other things that I've noticed with respect to how SetBounds works when a form's Position property is not set to poDefault at design time. For example, a form whose Position property is set to poScreenCenter at design time will not necessarily appear centered on the screen if you call SetBounds. However, it does not appear in the top-left location defined by SetBounds, nor does it respect the width and height specified in the call to SetBounds. Let me repeat, however, that I am setting the Position property of the form to poDefault before calling SetBounds. I've even stuck a call to Application.ProcessMessages between the two operations, but that doesn't fix the problem.
I have tested this extensively with Delphi 10.1 Berlin running on Windows 10. I have also tested it using Delphi XE6 on Windows 7. Same results.
If you have doubts, create a VCL application with four forms. On the first form place three buttons, and add something like the following OnClick to each button:
with TForm2.Create(nil) do
try
ShowModal;
finally
Release;
end;
where the constructor creates TForm2, then TForm3 and TForm4.
On the OnCreate of forms 2 through 4, add the following code:
if Self.Position <> poDefault then
Self.Position := poDefault;
Self.SetBounds(500,500,500,500);
On form2, set Position to poDefault, on form3 set Position to poScreenCenter, and on form4 leave Position set to the default, poDefaultPosOnly. Only form2 will appear at 500, 500, with a width of 500 and a height of 500.
Does anyone have a logical explanation for this result?
poDefault and friends mean "let Microsoft Windows position this form's window when the form would create and show it".
You just created Delphi object - but I wonder if it also has created/shown Windows object (HWND handle and all corresponding Windows internal structures). Especially with themed applications, not ones using standard pre-XP look and feel - they tend to ReCreateHWND when showing, because pre-loading those fancy Windows Themes is relatively expensive operation and only should be done when needed.
I think your default bounds (every property value set in the constructor might be considered a default non-tuned value, to be tuned later after object being constructed) are correctly ignored when you (or TApplication - that makes little difference for the topic) finally do FormXXX.Show.
It is during "make me a window and display it" sequence when your form looks at its properties and tells to MS Windows something like "now I want to create your internal HWND-object and position it at default coordinates/size at your discretion".
And that is absolutely correct behaviour - otherwise WHEN and HOW could TForm apply the Position property??? It just makes no sense to ask Windows for coordinates of a window that does not exists on the screen yet and maybe never would. Windows offers default coords/sizes for the this very second it being asked, looking how many other windows are there and where they are positioned ( and AMD/NVidia video drivers might also apply their correction to it).
It would make little sense, to acquire defaults now, and apply them two hours later when everything would probably be different - different amount of other windows and different positions of those, different set of monitors attached and with different resolutions, etc.
Just consider a "desktop replacement" type of notebook. It was set upon the table connected to large stationary external monitor. Then - let's imagine it - I run your application and it created the tform Delphi object and in the constructor it asked MS Windows for position - and Windows rightfully offered the position at that very secondary large monitor. But then an hour later I unplugged the notebook and walked away with it. Now an hour later I tell your application to show the form - and it will do what? display it with coordinates belonging to that now-detached external display? Outside of the viewport of the notebook's internal display that I only have at the moment? Should this form be displayed in the now "invisible" position just because when I started the application back then that spot was still visible there yet??? Way to confuse users for no gain, I think.
So the only correct behaviour would be to ask Windows for default coords this very second WHEN the form is going from hidden to visible and not a second earlier.
And that means that if you want to move your form - you should do it after it was being show. Place your Self.SetBounds(500,500,500,500); into OnShow event handler. So let the MS Windows materialize your form into default position like required by poDefault in Position property - and move your Window after that. Attempts to move the window that does not exist yet look correctly futile to me.
Either PRESET your form ( in constructing sequence) to explicitly ignore MS Windows defaults and use pre-set cords (via poDesigned value), or let the form ask Windows coordinates, but MOVE it with SetBounds after it got visible via OnShow handler.
I have two 100% overlapping panels with different contents on a form.
The first (static display of information) should be visible by default, but the other (user interaction) should replace it if the user moves the mouse near the two - and if the mouse moves away, it should switch back.
Something like this:
if (*the mouse is near*) then
begin
Panel1.Hide;
Panel2.Show;
end
else
begin
Panel2.Hide;
Panel1.Show;
end;
My problem is: where to capture mouse movement?
Each component has its own OnMouseMove handler - of course I could forward each of them to the forms handler, but I'd rather have something a bit more elegant (and easier to maintain).
The perfect solution would be something like Form1.MousePreview := true;.
Another solution would be assigning a generic handler that translates coordinates and calls the forms handler; The assigning could be done in FormCreate.
But that's not as easy as it seems, because one TImage already has its own mouse event handlers.
I have tried OnMouseEnter and OnMouseLeave of the two panels but it didn't work; #1 disappeared, but #2 did not appear. I guess that's because if the mouse leaves Panel2, it should disappear - but it also leaves it if it enters a button on it.
That's why I'd like to use a coordinate based approach to make the check more reliable.
Maybe the two panel method is completely wrong?
Update: Yes, it is, as Remy said.
I am now using a TJVPageList because a TPageControl has visual tabs.
The OnMouseEnter handler of the PageList sets one page, the OnMouseLeave sets the other; But once the mouse moves over the PageList, both pages start flickering.
I have tried adding the event handlers to each page, too, but that made no difference.
Should I check all OnMouseEnter / Leave events to filter out the PageList, the two pages and all components sitting on the pages?
Another update: I am using a TPageControl now, but the behaviour is similar.
It doesn't flicker, but if I move the mouse ontop the TPageControl, no TTabSheet is displayed at all.
Only if I press down the left mousebutton, the UI sheet is displayed. The other sheet is displayed normally if I move away the mouse. (The TJVPageList displays the UI page if I press the left mousebutton, too.)
I have used the mouse event handlers (enter/leave) of the TPageControl and both TTabSheets.
Update 3:
Done it.
The static Panel / TabSheet / JvStandardPage (#1) must not trigger the OnMouseLeave handler.
What you describe might be better served using a single TPageControl instead of two TPanel controls. Use the TPageControl's own OnMouseEnter/Leave events (or intercept the CM_MOUSEENTER/LEAVE messages) to switch the TPageControl.ActivePage as needed.
TMS's DBStringGrid component has a built in method which auto sizes row heights. I understand the property settings required for the method to work, and when called it works well.
I would like my grid's rows autosized anytime the grid is displayed, and I can't figure out where to place the method call. I thought the component's OnCustomCellDraw event would be the proper choice, but that just causes the flickering and memory usage associated with an endless loop (even when grid.doubleBuffering is set to true).
Where would you suggest I place the call to AutoSizeRows if I would like it to be called anytime the grid is being displayed?
UPDATE: Ken's answer is good but I'm also finding placing the call in the DataSource's OnDataChange event, whenever the DB kicks into Edit mode, may be as good for my purposes.
You can use the parent (containing) form's OnShow event:
procedure TForm1.FormShow(Sender: TObject);
begin
// Make sure grid's data is available by opening the
// dataset first, and then call your AUtoSizeRows here.
end;
In Delphi, I've added a Scrollbar component (oriented vertical) to the right side of my form.
I've added a Scrollbar OnChange event so I can change the view of the form and the position of the scrollbar thumb when the user clicks on the UpArrow or DownArrow button with his mouse, and this works fine.
But the OnChange event only seems to get triggered when the mouse button is initially pressed on the arrow.
I notice all scrollbar controls repeat the command and continue scrolling while the mouse remains pressed on the arrow, and I'd like to implement this behavior.
So how can I easily detect if the user has not moved the mouse and continues to press the mouse button while the mouse remains over the arrow?
Conclusion. Somehow something in the scrollbar in my project got corrupted. After I deleted the ScrollBar, and added it again, the problem vanished.
This is one of those tricky ones that took me a lot of time to solve. Thanks for your help. I'm closing this question.
Use the OnScroll event.
The following code adds 'xxx' to a memo as long as the mouse is held down on the scrollbar arrow button. Tested with Delphi 6.
procedure TForm1.ScrollBar1Scroll(Sender: TObject; ScrollCode: TScrollCode;
var ScrollPos: Integer);
begin
Memo1.Lines.Add( 'xxx' );
end;
The usual way to handle auto-repeating is to enable a TTimer and check in the OnTimer() event handler whether the action needs to be performed again, and to deactivate the timer if not. If you need sample code, I seem to remember that the SynEdit control used a similar technique for autoscrolling in drag and drop operations.
If a component does not encapsulate the behaviour you are looking for and you can't easily simulate the behaviour with the methods available you should really subclass the closest component that does most of what you need and add the behaviours that are missing.
I know that some extra work is involved but it really is the better way to go. Now with Delphi, I seem to recall that subclassed components needed a bit of extra work as well to be able to be used from the IDE for form design, maybe this has changed since version 7.
I have a problem I am unable to solve even though I spend long time trying to do it.
I usually use GridPanels to align controls on forms. It has, however, an annoying bug. When the GridPanel align mode is alClient and I maximize its parent window, the GridPanel adjusts to the new size of that window, however, the controls laying on the grid do not. They stay in the same position they were before window resize.
It happens only at the first window's maximization. If the window is first resized manually, everyting is OK. I think the grid adjusts its child controls after the second resize event (??).
What to to do make GridPanel work properly if it comes to this bug? It might be enough to send a message to it (but what message?), I do not know. I tried to use Realign, Refresh etc., but they did not help.
Thanks for your help in advance,
Mariusz.
Ah, I've had similar issues as well. It might be related to a resizing problem in the VCL. You might want to try the fix by Andreas Hausladen. It seems to work for me in most of the cases.
Changing the width / invalidating the control doesn't work for me (something changed with recent versions of RAD Studio?).
Anyway a similar, simple workaround along that line is:
procedure TForm1.FormResize(Sender: TObject);
begin
GridPanel1.ControlCollection.BeginUpdate;
GridPanel1.ControlCollection.EndUpdate;
end;
I found one trick.
in OnResize event of parent of gridpanel, change gridpanel's width by 1 pixel.
then gridPanel will notice size changed, then rearrange sub-controls in gridpanel..
sample is below..
procedure TForm1.FormResize(Sender: TObject);
begin
GridPanel1.Width := GridPanel1.Width - 1; // subtract 1
GridPanel1.Width := GridPanel1.Width + 1; // recover width by adding 1
end;
I have had this error too, on several projects. I'm not sure how I solved this (it was on projects for my previous employer, I don't have access to this source code anymore). I think I had te redraw / refresh that parent frame or form on which the GridPanel was placed.
on the resize of the owner call GridPanel.Invalidate.
I didn't test it. I hope it's work.