| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* Also fixed the issue where the treeview did not always display
in the UI Designer.
* When the treeview is in the UI Designer, then only limited
painting occurs.
|
|
|
|
|
|
This means that the internal state of the result component instances
are set correctly - without extra developer intervention.
|
|
We must not use field variables for Width, Heigh, Top and Left any more.
|
|
|
|
This is sow that the internal FPrevXXX and other state information
is setup correctly.
The Edit Button controls also needed some extra code to work correctly
in the UI Designer.
|
|
|
|
Because widget positioning is new possible before it is show, we
need to call UpdateWindowPosition any time we set Width, Height,
Top or Left so that it can update the internal state of the
widget correctly.
|
|
We used FHeight instead of FLeft!! Dope!
|
|
Updated the following methods by rather checking the ComponentState,
than the HasHandle result. Why? Because we want alignment and anchor
calculations to work, even before we have a window handle. Something
that happens often when using a Frame-type design for the UI.
* HandleMove()
* HandleResize()
* UpdateWindowPosition()
Due to removing the HasHandle check in UpdateWindowPosition, we had
to do the HasHandle check in each backend code instead. We don't want
to trigger API calls when we don't have a window handle yet.
|
|
* All fpGUI backends must override it as supply an implementation.
* Moved DowaitWindowMessage() implementations to the protected
section in the GDI and X11 backends.
|
|
Also made MessagesPending() a virtual abstract method in fpg_base.pas
which every fpGUI backend must supply an implementation.
|
|
A boolean return value of True means that there are active timers.
|
|
This function blocks the calling method, but allows for framework
messages still to be processed. Could be useful for some developers.
|
|
Windows uses OS messages for the timer, and Linux not. So the
DoMessagePending code had to be tweaked to work for both.
I made a note of this, to see if there is a better way of doing this.
|
|
|
|
|
|
|
|
Old behaviour calculated the size deltas, then applied the new sizes from
the received message. The new sizes were not guaranteed due to widget size
constraints that could be applied, which means the deltas could be wrong, which
in turn meant child components could be positioned incorrectly.
We now store the original size values in temp variables, apply the new sizes
which handles possible constraints, then only do we calculate the deltas, and
then pass those on to HandleAlignments().
|
|
eg: When you resize continuously for a few seconds to test widget anchor
processing, it was possible to reach the message queue limit. After this change,
that is not so likely any more.
|
|
|
|
|
|
|
|
instance.
|
|
|
|
|
|
|
|
* Painting is now near identical to Checkbox painting.
* Focus rectangle is now only around text.
Same reason as before. The left margin was 4px's which meant radiobuttons
never aligned nicely with other widgets. Now the margin is only 2px
so alignment is much better using the same left co-ordinate.
|
|
Because new now only paint inside the HandlePaint() method, we need
some optimization while setting properties. BeginUpdate
now blocks painting until EndUpdate it called.
|
|
Painting outside the HandlePaint is possible but very unpredictable,
so it is best we do not do it.
|
|
Now that the Align issues have been resolved, this work-around
is not needed any more. Commented, it now produces the exact same
events as under Windows too. This is good, obviously. :)
|
|
Not calling Parent.Realign ment we (self widget) is not being
resized (excluded from the re-align calculation), and thus the
self widget status at its current location and dimentions - until
the end-user actually resizes the top-level form.
This has now been fixed.
NOTE:
If you create extra widgets (eg: frames) outside the control of
the UI Designer, but still created before resource handles are
created, and you use Align property in those widgets, you need to
rather create those in Form.OnShow().
Align changes are not always acted apon before they have a window
handle, so it's best to do it in Form.OnShow for example. I'm still
figuring out how best to handle this.
|
|
of columns.
|
|
This is handy if you apply version version information to your
ini files, and on a new version the program must ignore the
old size values (because that sepecific form might have changed
dimensions at design time).
|
|
|
|
|
|
* Before, the image was 4 pixels away from the left, in default layout
So when you align many components with there left edges, it
looked as if the checkbox widget wasn't aligned correctly.
* Now the image is only 2 pixels from the edge, so aligning with
other widgets looks much better.
* Focus rectangle is now only drawn around the text portion of the
widget too. This is now similar to most OSes.
|
|
* ComboBox was always auto sized which is not always desired.
We now have a property to control that behaviour.
* Default is False, in preperation for layout managers which
control the size.
* Widget frame borders are now retrieved from the current Style
instance.
* default Height is set to 24px. The same default used for TfpgEdit
widget. Default sizes have been moved up into TfpgBaseComboBox,
out of TfpgBaseStaticCombo.
|
|
* This was done in preperation for layout managers which will
control widget sizes, and AutoSize will just interfere.
* Default Height is now set at 24px (same as what it was before
with default Arial font)
* Also implementeted setter for AutoSize property. This now
correctly adjusts the widget set when the property is changed
to True.
|
|
|
|
|
|
|
|
It's disabled by default. Enabling can be done via project level
or inside each unit at the beginning of such units.
|
|
Used internally, but could be used in developers own software
too.
|
|
Apparently it is good to allocate a instance, without
calling the constructor. I'm not exactly sure why, but it also
makes supporting FPC 2.5.1 a lot less messy (no casting required).
|
|
Old behaviour was that the beginning of long text was scrolled
off the left of the edit, so you saw the end of the text.
Now we should see the beginning of the text and the end of the
Text is out of view on the right.
|
|
|
|
|
