Age | Commit message (Collapse) | Author |
|
|
|
This is done because DoKeyShortcut() clearly says what it does. It only
processes keyboard shortcut events.
|
|
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.
|
|
|
|
It's disabled by default. Enabling can be done via project level
or inside each unit at the beginning of such units.
|
|
This will hopefully reduce the confusion between the other
TfpgWidget.AcceptDrops property - they had too similar names.
* Applied rename changes to all other descendants too
* Updated DND demo project
|
|
If set to False (the default), no DND can occur in that window. No OS
messages for DND are processed or received.
|
|
* 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.
|
|
|
|
This facilitates in the loading of external form files at runtime.
|
|
They were available in TfpgWidget, so why not make them available in
TfpgForm as well.
|
|
|
|
|
|
* Replaced all magic number modal results with actual enum values
* UI Designer now uses enum combolist for ModalResult type in
Object Inspector.
* UI Designer now handles default values of ModalResult property correctly.
|
|
|
|
properties are populated.
|
|
The TfpgBaseForm needs to ask fpgApplication to free it, so we now use
a new, and more appropriately named, message constant.
|
|
|
|
|
|
|
|
|
|
* Implemented InvokeHelp in TfpgWidget
* implemented InvokeHelp and OnHelp event in TfpgForm
* Implemented HelpConext, HelpKeyword and HelpType in TfpgComponent
|
|
Part of the "golden ratio" goodies. It seems to me more pleasing
to the eye if a dialog is not 100% centered in the window, but
rather 1/3 down of available vertical space. I think Mac OS X
also does this.
|
|
|
|
stach make sure to remove themselves when destroyed
* Added 2 new attributes to TWindowAttributes waUnblockableMessages, waX11SkipWMHints
* waUnblockableMessages is useful for allowing certain windows to still respond when other windows are modal
|
|
user input could be blocked.
|
|
* UI Designer has been updated to reflect the new gui unit names.
|