| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
The global F1 (application help) shortcut handling
never looked at the ShiftState value. So if we had
a popup menu with F1->help; Ctrl+F1->About, the
second item's shortcut with be interpreted as F1 only.
|
|
|
|
|
|
The global F1 (application help) shortcut handling
never looked at the ShiftState value. So if we had
a popup menu with F1->help; Ctrl+F1->About, the
second item's shortcut with be interpreted as F1 only.
|
|
No need for so much code duplication. This also means that widgets like TfpgStringGrid now
have keyMenu keypress behaviour. Basically any widget that supports a PopupMenu.
|
|
|
|
fpgApplication.HelpKey is now actually used in fpGUI, and it will invoke the help.
|
|
|
|
|
|
|
|
|
|
|
|
processing order is now as follows;
- widget that keypress occured it trys to handle the event.
- then to keyboard shortcut processing for the widget's children
- then work back towards the top-level form giving chance for
keyboard navigation (tabstop) processing. eg: pressing Tab key
- then let the top level form to keyboard shortcut processing
eg: allowing MainMenu to process the event.
- then allow the top level for to process OnKeyPress if such an
event handler is implemented.
- then if the top level form is not the MainForm, and the current
top level form is not shown model, allow the application.mainform
to process the keyshortcut in it's main menu.
|
|
This is similar to HandleKeyPress() but takes into account the original
widget that started the process, so it doesn't process that widget or its
children twice.
|
|
|
|
Code cleanup was done. After all, FPC 2.4.0 and 2.4.2 has been out for ages.
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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().
|
|
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.
|
|
|
|
It's disabled by default. Enabling can be done via project level
or inside each unit at the beginning of such units.
|
|
* TfpgButton now ignores double clicks by default
|
|
This is so they can be tested. Once DND stabilizes, I'll make the
properties available on the other components too.
|
|
* also introduced virtual DoDragStartDetected which executes
the OnDragStartDetected event
* We also added a override of DoDragStartDetected in GDI for
some extra tasks.
|
|
* This abstract method is called from TfpgWidget's AcceptDrops setter function
* Template implementation in X11
* Actual implementation in GDI
|
|
* Single click produces one OnClick event
* On a Double Click in produces a OnClick, then a OnDoubleClick
event. Old behaviour used to procuder yet another OnClick at
the end. This is not needed.
* OnMouseDown and OnMouseUp events behaviour has not changed.
The reason we introduce the FOnClickPending instead of fully
handling the events in TfpgWidget.MsgMouseUp is because a TfpgButton
has slightly different behavior (eg: When clicking on a button, keep
mouse down, and move mouse out of button rectangle, then an
OnClick must not fire.) The extra FOnClickPending allows us to
toggle this behaviour of HandleLButtonUp (which normally fires
the OnClick event)
|
|
This allows you to add/delete many lines and the memo only
repaints once.
|
|
|
|
* It used to have a hard-coded processing of alignment.
Top, Bottom, Left, Right and then Client.
* This meant extra "fake" panels was required to get a specific
design.
* Align property is now processed in the creation order of the
widgets.
|
|
If you only set a single anchor eg [anTop] and you resize the
width of the form, the component will stay relative to the
original position.
if you place a component in the center of a form, and set anchors
to [], and resize the form, the component will stay centered.
|
|
|
|
|
|
For now we hard-code the data type as TfpgString. Later this will change.
|
|
|
|
Under X11 the XDND OS messages on only go to the top-level window, so we
send the FPGM_ messages ourselves. Later each component will hook into this
to change it's appearance to show the end-user that a drop is allowed or not.
eg: Some components will get a dark/black border or something.
|
|
|
|
This will enable/disable drop support per widget.
|
|
* KeyPress is first offered to the focused widget
* If not consumed, then to parent, then parent.parent etc..
* if still not consumed, then to top level form
* if still not consumed, then to fpgApplication
If anywhere in the sequence Consumed = True, then distribution of
that event is stopped.
This is the basic foundation required for various keyboard shortcut
handling, actions shortcut handling, and especially in menus.
The latter still needs some work though.
|
|
Now these functions are accessible to platform specific code too.
|
|
If widgets are not visible, they are not added to list of widgets
that need to be re-aligned.
|
|
|
|
|
