| Age | Commit message (Collapse) | Author |
|---|
|
This is a placeholder for future use.
|
|
|
|
See the comments in the code. This fixes lots of code that checks for
the ShiftState values in key press events.
|
|
Now we can retrieve the WindowState of TfpgForm under both Linux and
Windows.
|
|
|
|
This is an initial implementation for Linux only. Currently this property
is read-only, but that alone is already very useful. Next I'll implement
the Windows support, and later the read-write support.
|
|
This component allows you to set all components on a form or embedded containers
as ReadOnly = True/False by just toggling one property on TfpgReadOnly.
|
|
|
|
Code cleanup was done. After all, FPC 2.4.0 and 2.4.2 has been out for ages.
|
|
|
|
|
|
|
|
Somehow I forgot to rename this type when we introduced the 'fpg' prefix years ago.
|
|
Somehow I forgot to rename that type name when we moved over to the 'fpg' prefix.
|
|
The fpgStyle global variable is now simply a reference to the current style
in the fpgStyleManager. The Style Manager does the free'ing of the style
too, so we simply need to tell the style manager when we want that done.
|
|
This is a bit of a cross-linking case, jumping from corelib code to gui code,
but I can't see how this can be done any other way. After all, fpGUI is a
GUI toolkit - not a non-gui utility library.
For some strange reason the 'Win2000' and 'auto' did not register automatically,
even though they are in the *.lpk package and in the initialization section.
So I had to add that style unit to the uses clause. I need to investigate
why this had to be done.
|
|
This is basically just some code formatting changes, making it easier for
a developer to see what style methods related to what widgets - that's if
the method names was not obvious enough. ;-)
|
|
This is a common style implementation - basically just paints the background
a specific color. Nothing fancy.
|
|
These will later contain the various style implementations.
|
|
|
|
This allows a style to define by how much the button image and text must
shift (if at all) when the button is pressed. Possitive numbers moves right
and down. Negative numbers move up and left. Zero values means the icon and
text doesn't move [like under Mac OS X].
|
|
I know in FPC mode objfpc it is not strictly needed, but lets keep to the
Object Pascal language standards for now.
|
|
|
|
If the ActiveWidget was freed, the parent never got notified. If focus was
then changed, the parent tried to call ActiveWidget.HandleFocusKill, causing
an access violation.
The toolkit now correctly sets ActiveWidget to nil if it was freed, and as
a extra failsafe, wraps the HandleFocusKill call in a try..except block.
|
|
|
|
The code change in the original commit worked fine for Windows, but caused
other problems under Linux. So I have commented the original code change
for Linux until I can find a more suitable solution.
|
|
|
|
|
|
|
|
a project uses clause.
|
|
* Linux now defaults to 'Liberation Sans' which comes standard
with most Linux distros, and is metric compatible with Arial.
The latter is freely available, but doesn't come standard
with any Linux disto.
* Windows default font size is now 8 (down from previous 10),
which is now the same as the remainder of Windows apps.
Strange that the same font as size (eg: Arial-10) is different
sizes in pixels under Linux and Windows. Weird! :-/
|
|
|
|
|
|
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.
|
|
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.
|
|
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().
|
