I am trying to animate a checkbox through stylebook by;
Making a layout and naming it 'ch_style1'
Adding another layout naming it 'layout' ( Align = Left )
Adding a TRectangle ( Align = Left; HitTest = False )
Setting fill color to animate through TColorAnimation
The TColorAnimation ( Enabled = True; Inverse = True; Trigger = IsMouseOver=true; InverseTrigger = IsMouseOver=false )
Adding a TText and a TShadowEffect
The problem only shows up in my main application where there are a lot of controls though hidden. Each view can contain up to 30-40 controls. There are no performance issues at all. The style designer IDE even shows the animations on the control but running the application suggests as if the IsMouseOver trigger doesn't fire. I have faced success, only if I do it for controls on a new form.
As its all in the IDE, I can't give any code to help my case, the dfm even sits above 600KB... So please enlighten me with your experiences and any possible areas I may look for the solution. Thank you.
There's an inherent bug in FireMonkey (both the original from XE2 and FM2 from XE3) where the animations fail mid-way. It's not you, it's FireMonkey!
Related
What is the correct procedure for Scaling a TFrame in C++Builder?
I am developing in PixelsPerInch=120 (aka. Windows font size 125%), but want my forms to work in PixelsPerInch=96 also (aka. default).
My main form loads fine: the VCL code to create a TForm includes a check of whether the design PPI differs from runtime PPI and it scales everything correctly at that point.
However when loading a TFrame, no automatic scaling occurs. So far as I have been able to discover, I have to manually call Frame1->ScaleBy(M, D);.
This mostly works however it has a bug (which I will describe below) so the result is a frame that is not scaled correctly.
What is the proper way to create a Frame and have it scale on load, like a Form does?
I am currently using the following:
// class member
TFrame *f;
// called just before Application->Run()
f = new TFrame(fMain);
int M = fMain->PixelsPerInch;
int D = 120; // Matt's development
if ( M != D )
{
f->ScaleBy(M, D);
}
and then when I want to activate the frame, `f->Parent = fMain->Panel1;
(*f)->ScaleBy(M, D);
I have also tried writing f->Parent = fMain->Panel1; before calling ScaleBy, based on the theory that the Frame has controls using ParentFont and so on, so it might be better if this info is available during scaling; however this introduces other bugs.
The bug is that when calling ScaleBy on a Frame or a Form which has a TLabel which has AutoSize=true and ParentFont=false and Anchors including akBottom, then the Label is displayed much higher up on the window than it should be (maybe even off the top of the window).
I have tracked down the problem: the TControl.ChangeScale function includes a call to ScaleMargins, and the Margin property has an on-set trigger that ends up calling AlignControls for the parent form, which will move any controls with AutoSize=true.
By stepping through Vcl.Controls.pas, I see that my Label scales correctly at first , however when the next control (a radio group, it happens to be) is processed, the AlignControls is triggered, which changes my Label's Top.
The AlignControls function apparently can't handle the TLabel with the parameters I just described when called part-way through a rescaling operation.
I haven't firmly nailed down why, but I think it is because the parent Form or Frame has not yet been scaled (the ScaleControls function scales all the children before scaling the self), so it uses the form's old Height to calculate the actual Top that results from doing alignment to the bottom.
This effect is not triggered when loading the Form the first time, because the scaling code checks for csLoading component state and disables a whole lot of reactionary effects, including the call to AlignControls.
I haven't figured out why the bug is only triggered when ParentFont=false.
My current workaround is to include a line in the FormResize handler that manually realigns the Labels in question with another label that has ParentFont=true (and thus doesn't suffer from the bug).
I encountered something really really really odd with TStringGrid (Delphi XE). I have seen that sometimes when I click the first line in my grid, it turns black (or shows scrambled canvas 'stolen' from other controls on form).
It happens ONLY in certain configurations, when the grid receives focus. Once you click another area in the grid everything looks ok until the focus is moved to another TStringGrid.
How to reproduce:
put TWO string grids on a form
set them as shown below (Update: I realized that goRowSelect and goEditing must be 'true')
click the first cell in one grid -> nothing happens
click the first cell in the second grid -> the first cell gets black (see screenshot)
The problem appears also in other circumstances (not necessary to have 2 grids on a form), but I managed to reproduce it only when I have 2 grids.
object grid1: TStringGrid <------- same for Grid2
Left = 2
Top = 8
Width = 422
Height = 381
BevelEdges = [beLeft, beTop]
DefaultColWidth = 80
DefaultRowHeight = 15
DoubleBuffered = True
FixedCols = 0
Options = [goFixedVertLine, goFixedHorzLine, goVertLine, goHorzLine, goRangeSelect, goDrawFocusSelected, goColSizing, goEditing, goRowSelect, goFixedHotTrack]
ParentDoubleBuffered = False
TabOrder = 1
end
Any idea on how to fix this?
I can reproduce your problem with XE3 as well. After I have reset ParentDoubleBuffered to True, the problem is gone.
Generally speaking, when I see odd black rectangle in a control, I will first check the ParentDoubleBuffered settings. I saw you have enabled double buffering for the two grids. Do you have any special reason to do that? If you intend to avoid flickering during resizing or cell update, there are some techniques helpful.
I have done some FireMonkey stuff in XE2, in this case I'm having troubles with a customized TListBox.
In XE2 I built this customized TListBox by removing it's background and surrounding rectangle (basically I only need the 'grouping of child items' functionality provided by TListBox. This was simple, drop a TListBox, hit 'edit custom style', select the background rectangle, edit the fill and the stroke and you're golden.
Now we're moving to XE5 and I cannot reproduce the same behavior. Using the style book editor I can see the background (which is now TStyleObject and not TRectangle), but I cannot make the changes I could make before. I see tutorials on how to add stuff to a TListBox, but not on how to take default behavior away.
Can someone explain how to achieve this specific behavior, or point me towards a good tutorial?
Try changing the StyleLookup property of the list box to transparentlistboxstyle
My goal is to create a simple forms editor like the one that we find on Delphi IDE.
Right now the user can select and add the components making it parent of a TPanel that is the holder of the form. For simplicity, please consider also TPanel as the visual components added to the form.
I have 2 missing parts I want to find out ideas/code to help complete:
1 - how to move the created visual component? The same effect that in IDE for moving the visual component, for example Tpanel, around, chaning its top and left position
2 - how to draw that hooks for the component with focus on the form editor
3 - how to resize using the hooks
I only want the part related to handle the visual part. I am not generating DFM or anything like that.
Simply put your moving code needs to do this:
When the mouse goes down, check if the mouse position is over a control that can be dragged. If so, then set a variable named FDragControl to refer to that control. This code lives in an OnMouseDown event handler.
When the mouse moves, if FDragControl is not nil, move the control. This code lives in an OnMouseMove event handler.
When the mouse goes up, set FDragControl to nil.
That's pretty much all there is to it. The main nuance is that you must also remember the X, Y values of the mouse when the drag commenced. So in your OnMouseDown handler you write:
FStartMousePos := Point(X, Y);
FStartDragControlPos := Point(FDragControl.Left, FDragControl.Top);
And then in the OnMouseMove your position code reads:
FDragControl.Left := FStartDragControlPos.X + (X-FStartX);
FDragControl.Top := FStartDragControlPos.Y + (Y-FStartY);
You will also need to capture the mouse when you start dragging.
The resizing code is similar. Again, you need to decide in the OnMouseDown that you are resizing rather than dragging, but the code still involves handling mouse down, move and up events.
As for painting, you need to force a repaint whenever one of your event handlers changes a property that will influence the visual appearance of your form. You can use the value of FDragControl to decide whether or not to use special drawing of your control and indicate that it is being dragged. And likewise for resizing.
I've not coded up a full working implementation since your question is high level and conceptual. The implementation is down to you.
// I have made this an answer as I have just read your latest update which really should have been made as an edit to your original question but, anyway.
You can download the Cindy Components Pack and use the cyResizer Component which will do pretty much everything you need and is very customisable as well.
You can download it from here: http://sourceforge.net/projects/tcycomponents/
Searching more for an answer I could find these articles:
How to Move and Resize Controls at Run Time
http://delphi.about.com/library/weekly/aa102505a.htm
How to Add Size Handles to Controls being Resized at Run-Time
http://delphi.about.com/library/weekly/aa110105a.htm
Pretty much with all the information to complete this task with source code example.
These articles show how to implement and use a TMover class. I have done it and work correctly.
I have also downloaded the TcyComponents Pack and used the TcyResizer. It is a full featured form editor with pretty much everything that is required for a Delphi like forms editor. I recommend. It comes with source code and works fine with XE2 version.
My issue is with the thing Delphi progies scare to death - Rich Edit in Windows (XP and pre-XP versions).
Situation:
I have added EM_AUTOURLDETECTION in OnCreate of form. Target -> RichEdit1. Then, I have form, that is "collapsed" after showing form. RichEdit Control is sattic, visible and enabled, but it is "hidden" because form window is collapsed.
I can expand and collapse form, using Button1 and changing forms Constraints and Size properties.
After first time I expand form, the URL inside RichEdit1 control is highlighted. But, after second, third, fourth, etc... times I collapse and expand form, the RichEdit1 Control does not highlight URL anymore.
I have tried EM_SETTEXTMODE messages, also WM_UPDATEUISTATE, also basic WM_TEXT message -> no luck. It sems like this merssage really works ( enables detection ) while sending keyboard strokes ( virtual keycodes ), but not when text has been modified.
Also - I am thinking to rewrite code to make RichEdit Control dynamic. Would this fix the problem?
Maybe solution is to override OnPaint / OnDraw method to avoid highlight ( formatting ) losing when collapsing or expanding form?
Weird is that my Embarcadero Documentation says this function must work in any moment text has been modified. Why it does not work?
Any help appreciated. I am making this Community Wiki because this is common problem and togewther we cam find solution, right? :)
Also - follow-ups and related Question:
Override OnPaint
How to autodetect urls in RichEdit 2.0?
http://www.vbforums.com/archive/index.php/t-59959.html
I am not sure but is the window of the richedit recreated when geing from hide to show? If this is the case you might create your own derived TRichEdit class, override the function that creates the WIndows Handle (TWinControl.CreateHandle) and add EM_AUTOURLDETECTION there.