| Age | Commit message (Collapse) | Author |
|---|
|
|
|
No more manual handling of LineEnding characters etc, because StringList
does that already, and our custom handling causes blank lines to
disappear in the memo. Not what we want.
|
|
|
|
|
|
|
|
|
|
Old behaviour was that the OnClick will trigger even if the left
mouse button was released outside the bounds. This is not standard
behaviour compared to other gui toolkits.
|
|
Clicking on the first column of the left ListView will sort
the listview by that column. Both listviews will get updated.
|
|
|
|
Sender: the widget the mouse was over when drop occurs.
Source: If whole DND is inside the same app, then Source is the
original Widget the DND started from.
|
|
Sender: the widget the mouse was over when drop occurs.
Source: If whole DND is inside the same app, then Source is the
original Widget the DND started from.
|
|
Sender: = the widget the mouse entered and that triggered the event
Source: = if whole DND occurs in same app, then Source is the
Widget the DND action started from.
|
|
Sender = widget the mouse entered and triggered the event
Source = if the whole DND is inside the same app, then Source
is the original Widget drag started from.
|
|
* A new constructor was also added where you can pass the tabsheet
title, so tabsheet size can be better calculated if tabs are
set to Left or Right.
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
It's not something that should be managed by the ui designer.
|
|
We must not use field variables for Width, Heigh, Top and Left any more.
|
|
|
|
|
|
This changes is to keep the UI Designer on par with what has changed
in the core framework regarding widget positioning. We now need to
call UpdateWindowPosition to correct the internal state of widgets,
as they are loaded.
Also removed unused/commented code.
|
|
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!
|
|
* PageControl now has a MinWidth set, so that making it ridiculously
small doesn't scew with the widget anchors.
* Due to above change the default splitter snapping doesn't occur.
So now we worked around that using a new OnDoubleClick event handler,
by simply making the pagecontrol visible or not.
|
|
|
|
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.
|
|
|
|
Also set min width/height constraints for the dialog.
|
|
|
|
for groups, and text wrapping on PDF.
|
