Age | Commit message (Collapse) | Author |
|
|
|
This now makes it easier to reuse this border style declaration in other
widgets. We need to refactor some other widgets too, that have there own
border styles as well.
|
|
|
|
|
|
It wasn't always desireable for DumpStack to output to the console, because
it doesn't always exist, and the user will normally not see it if app is
launched from a icon.
We can now output that info to a stringlist, and display it to the end-user
in whatever way we want.
|
|
|
|
value.
|
|
|
|
|
|
|
|
This doesn't have any affect under Linux, but it might under Windows.
|
|
|
|
|
|
- also updated the translation include files. ready for translation.
|
|
|
|
|
|
|
|
|
|
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.
|
|
In KeycodeToText(), 'Shift+' came before Ctrl or Alt. This is not normal
practice, so I moved it.
|
|
Now the internal blink timer only gets activating when a Canvas is assigned.
|
|
|
|
I was clearly smoking something that day! Anyway, the GDI timer is now
correctly implemented, and doesn't push up the CPU load any more. No matter
how long the timer runs for. The timer is much more accurate/consistent in
firing as well. :-)
|
|
Refactored the TfpgTimer by introducing a TfpgBaseTimer and X11 & GDI Timer
descendants. This now allows use to add platform specific extensions to
the timer implementation.
|
|
|
|
This is consistent with other components in the RTL, FCL and even fpGUI
itself.
|
|
It seems FPC only supports users.pp unit in Linux. Making this changes
allows use to compile fpGUI under OpenSolaris too!
|
|
Old behaviour was that we simply assumed the first parameter will be
the X11 -display parameter. This is just WRONG!
We now query the parameter list for the value of -display, that's if it
exists in the first place.
|
|
|
|
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.
|
|
|