On 06/30/2014 07:53 PM, Graeme Geldenhuys wrote:
In hobby projects that might be fine, but in commercial multi-platform
apps that is unacceptable.
I see.
Regarding myself, I in fact don't like taking the enhanced effort of
beatifying the GUI (and Delphi-introduced Windows Widget Set
On Tue, 1 Jul 2014, Michael Schnell wrote:
On 06/30/2014 07:53 PM, Graeme Geldenhuys wrote:
In hobby projects that might be fine, but in commercial multi-platform apps
that is unacceptable.
I see.
Regarding myself, I in fact don't like taking the enhanced effort of
beatifying the GUI (and
On 07/01/2014 09:36 AM, Michael Van Canneyt wrote:
You obviously don't often get in contact with clients and marketeers.
I Do. But we do embedded stuff and not (very often) Software that runs
visibly on PC screens.
So this obviously is a different market ;-) .
-Michael
--
On 06/28/2014 12:51 AM, Giuliano Colla wrote:
...
Seems like you describe shortcomings in the LCL that are doubtlessly
worse than it could be.
Hence the decent way of handling things would be to improve the LCL,
rather than to try to do normal-purpose FPC based GUI enabled projects
that
On 06/30/2014 11:36 AM, Michael Schnell wrote:
than avoid using the LCL.
OK using another _existing_ GUI framework (like mseGUI) might make
sense, as well.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/27/2014 12:24 PM, Michael Schnell wrote:
Unfortunately this is even true if you do TThread.Queue with a fake
thread pointer, as it internally checks using GetCurrentThread.
In fact the first parameter (Thread) in the class procedure
TThread.Queue is just use to mark the event, so that
On 2014-06-30 10:36, Michael Schnell wrote:
Hence the decent way of handling things would be to improve the LCL,
In the past I have done just that. But due to the design goals of LCL
(being as native as possible), some changes simply ain't possible, or
only possible in some backend toolkits (eg:
Am 29.06.2014 01:43 schrieb Giuliano Colla giuliano.co...@fastwebnet.it:
Il 28/06/2014 20:30, Marco van de Voort ha scritto:
On Fri, Jun 27, 2014 at 05:40:35PM +0200, Giuliano Colla wrote:
Sorry for the misunderstanding. I did consider this possibility because
we have hundreds of Kylix
Il 29/06/2014 09:40, Sven Barth ha scritto:
[...]
Am 29.06.2014 01:43 schrieb Giuliano Colla
giuliano.co...@fastwebnet.it mailto:giuliano.co...@fastwebnet.it:
However the sources are left untouched. I believe this be a sign of
good design, from the Borland's good old times...
As I said I
On Friday 27 June 2014 21:04:13 Giuliano Colla wrote:
I don't care too much about being modern. I claim that the best
solution is always the most appropriate, not the newest.
Tombstones are still made of stone. It's stone age technology, but it's
the most appropriate up to now. Only if
Giuliano Colla schrieb:
Whenever you need a form to stay on top you never know if it'll
work or not. For Gtk2, it did work on Lazarus 1.0.8, but it
stopped working since Lazarus 1.1. This means that a user may lose
an alarm which pops up, because he inadvertently touched
Il 28/06/2014 09:16, Hans-Peter Diettrich ha scritto:
Giuliano Colla schrieb:
Whenever you need a form to stay on top you never know if it'll
work or not. For Gtk2, it did work on Lazarus 1.0.8, but it
stopped working since Lazarus 1.1. This means that a user may lose
Am 28.06.2014 12:19 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Giuliano Colla schrieb:
Whenever you need a form to stay on top you never know if it'll
work or not. For Gtk2, it did work on Lazarus 1.0.8, but it
stopped working since Lazarus 1.1. This means that a
Am 28.06.2014 12:27 schrieb Giuliano Colla giuliano.co...@fastwebnet.it:
Il 28/06/2014 09:16, Hans-Peter Diettrich ha scritto:
Giuliano Colla schrieb:
Whenever you need a form to stay on top you never know if it'll
work or not. For Gtk2, it did work on Lazarus 1.0.8, but it
On 2014-06-27 19:53, Giuliano Colla wrote:
You need tons of workarounds to make them work under Lazarus, and to
comply with native widgesets features and bugs. Just to mention a few:
That is a very similar experience I had with LCL. My applications
required a lot of visual customisation, and
On 2014-06-27 18:16, Juha Manninen wrote:
Can they also bind to recent QT versions? I doubt.
No need, because Kylix comes with its own Qt library - hence the
applications still run perfectly on today's systems.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free
Il 28/06/2014 01:18, Juha Manninen ha scritto:
On Sat, Jun 28, 2014 at 1:51 AM, Giuliano Colla
giuliano.co...@fastwebnet.it wrote:
(I can't anchor the second Button to the first, because if the first becomes
invisible, the second is moved from his position, which is not acceptable).
True,
On 2014-06-27 23:51, Giuliano Colla wrote:
Graeme Geldenhuys who had problems of the same sort ended up designing
his own widgetset. I'm more modest, and I look to a design mediator.
If there is something missing from fpGUI to help you migrate your
projects off Kylix, we can discuss this in
Il 28/06/2014 14:47, Graeme Geldenhuys ha scritto:
On 2014-06-27 23:51, Giuliano Colla wrote:
Graeme Geldenhuys who had problems of the same sort ended up designing
his own widgetset. I'm more modest, and I look to a design mediator.
If there is something missing from fpGUI to help you
On 2014-06-28 14:41, Giuliano Colla wrote:
My current main problem is to provide support to hundreds of installed
applications, providing updates, enhancements etc. Therefore migrating
to a different project frame is a possible option, but not the first one.
I fully understand that.
Il 28/06/2014 20:30, Marco van de Voort ha scritto:
On Fri, Jun 27, 2014 at 05:40:35PM +0200, Giuliano Colla wrote:
Sorry for the misunderstanding. I did consider this possibility because
we have hundreds of Kylix projects which are still alive, and need
maintenance. Kylix IDE can only be used
On 06/26/2014 07:38 PM, Mattias Gaertner wrote:
If you mean for TTimer: Yes, I'm waiting for your patch.
Meaning what ?
I can send you a testing application (that does nit use the LCL but just
fpc) if you just want to see it working.
For doing a Patch to the LCL, some more prerequisites
On 06/27/2014 03:19 AM, Hans-Peter Diettrich wrote:
Every clock tick increments the internal clock, and triggers all
events...
This is exactly what I want to avoid.
Each active clock tick needs a system-mode / user-mode and back
transition. But the NoGUI Widget Type is done for small
On 06/26/2014 05:16 PM, Sven Barth wrote:
At the beginning Michael sounded more like he wants to implement a new
widgetset that's only relying on TThread functionality and thus would
require 2.7.1. For the case of extending NoGui you are of course right.
Yep.
As discussed in fpc-devel, I
On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:
implementation part is demanded to some third party Widgetset (such as
gtk, qt, Windows, etc.), via an Interfaces unit.
This is not compatible with other implementations, such as Kylix and
fgGui, just to mention two.
It is
On Fri, 27 Jun 2014 10:35:28 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/26/2014 07:38 PM, Mattias Gaertner wrote:
If you mean for TTimer: Yes, I'm waiting for your patch.
Meaning what ?
I can send you a testing application (that does nit use the LCL but just
fpc) if you just
On Wed, Jun 25, 2014 at 04:46:08PM +0200, Mattias Gaertner wrote:
Thanks for the Clarification.
I seem to remember that with Delphi the Term RuntimPackage had been used
the way I did and was not aware that with Lazarus this is different.
Both Delphi designtime and runtime packages are
On 06/27/2014 11:08 AM, Mattias Gaertner wrote:
Yes, please.
I'll do some cleaning up and send you the source code.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Fri, 27 Jun 2014 10:35:28 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
So? Program a queue.
IMHO this is not appropriate.
There already is a queue in the RTL that needs to be handled, as same is
fed by TThread.Synchonize (and TThread.Queue) user accessible functions.
Hence
On Fri, 27 Jun 2014 11:09:41 +0200
Marco van de Voort mar...@stack.nl wrote:
On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:
implementation part is demanded to some third party Widgetset (such as
gtk, qt, Windows, etc.), via an Interfaces unit.
This is not compatible with
Il 27/06/2014 11:09, Marco van de Voort ha scritto:
On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:
implementation part is demanded to some third party Widgetset (such as
gtk, qt, Windows, etc.), via an Interfaces unit.
This is not compatible with other implementations, such as
On 06/27/2014 11:35 AM, Mattias Gaertner wrote:
In case of nogui there is no library, so you have the full control.
I need to do a system call to have the program wait and do another
system call to wake it. I understand that this is library dependent.
Not quiet.
OK. Not _necessarily_. But
Michael Schnell schrieb:
On 06/27/2014 03:19 AM, Hans-Peter Diettrich wrote:
Every clock tick increments the internal clock, and triggers all
events...
This is exactly what I want to avoid.
Any time source is applicable with this model. The ticks (or even longer
intervals) can be deliverd
On 06/26/2014 02:54 PM, Michael Schnell wrote:
Maybe this is not fully compatible with Application.QueueAsyncCall (if
same is called in the main thread), which I did implement using
TThread.Queue.
I checked the code of TThread.Queue and in fact it does not queue the
call if TThread.Queue is
On 06/27/2014 10:35 AM, Michael Schnell wrote:
For doing a Patch to the LCL, some more prerequisites are needed:
- do we want something at all if it is not usable with the released
version of fpc (see discussion in fpc-devel)
...
Addition:
- we can't create full compatibility to how
On 06/27/2014 11:56 AM, Hans-Peter Diettrich wrote:
Any time source is applicable with this model. The ticks (or even
longer intervals) can be deliverd by callbacks, messages...
We have multiple TTimers that need to be driven by a singe Time source.
Hence the necessary userspace /
On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:
This is not compatible with other implementations, such as Kylix and
fgGui, just to mention two.
It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?
You're right, in Kylix CLX Qt is hardcoded. Therefore
On Fri, 27 Jun 2014 12:24:02 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
- we can't create full compatibility to how Application.QueuAsnyCall
works with other Widget Types, as TThread.Queue, when called from the
main Thread, does not queue the call but preforms the call right
On 06/27/2014 03:07 PM, Mattias Gaertner wrote:
... or simply do it without TThread.Queue, which is not complicated,
is LCL compatible and works with fpc 2.6.2+.
Only argument: You fear it is more overhead. The only overhead I see is
an extra critical section, which is negligible when your
Il 27/06/2014 14:44, Marco van de Voort ha scritto:
On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:
[...]
This makes it impossible to use the features of IDE Designer as it is
for a Kylix project.
True, but the incompatible threw me off, and the perspective on what
On Friday, June 27, 2014, Giuliano Colla giuliano.co...@fastwebnet.it
wrote:
But given this possibility, I find much more interesting and stimulating
the attempt to take advantage of this feature, than the boring task of
converting hundreds of Kylix applications to LCL!
Is it a boring task?
On Friday, June 27, 2014, Giuliano Colla giuliano.co...@fastwebnet.it
wrote:
I did consider this possibility because we have hundreds of Kylix projects
which are still alive, and need maintenance. Kylix IDE can only be used on
old platforms/virtual machines but the compiler and the
Il 27/06/2014 19:08, Juha Manninen ha scritto:
On Friday, June 27, 2014, Giuliano Colla giuliano.co...@fastwebnet.it
mailto:giuliano.co...@fastwebnet.it wrote:
But given this possibility, I find much more interesting and
stimulating the attempt to take advantage of this feature, than
Il 27/06/2014 19:16, Juha Manninen ha scritto:
On Friday, June 27, 2014, Giuliano Colla giuliano.co...@fastwebnet.it
mailto:giuliano.co...@fastwebnet.it wrote:
I did consider this possibility because we have hundreds of Kylix
projects which are still alive, and need maintenance. Kylix
You seem to have unusual GUIs. Still, I have a feeling you do something
wrong when creating controls in code.
Setting the position, size or anchors at runtime work well.
Gtk2 may have some Z-order issues, QT is better.
I did not use a background bitmap but it should be doable, too.
If you ask
Il 27/06/2014 23:34, Juha Manninen ha scritto:
You seem to have unusual GUIs. Still, I have a feeling you do
something wrong when creating controls in code.
Setting the position, size or anchors at runtime work well.
Gtk2 may have some Z-order issues, QT is better.
Well, I may give you a small
On Sat, Jun 28, 2014 at 1:51 AM, Giuliano Colla
giuliano.co...@fastwebnet.it wrote:
(I can't anchor the second Button to the first, because if the first becomes
invisible, the second is moved from his position, which is not acceptable).
True, hiding the control ruins the plan of using anchors
On 06/25/2014 09:57 PM, Sven Barth wrote:
If you rely on the new TThread functionality you'd need to at least
put in guards against compiling with a pre-2.7.1 compiler.
Can I do this by a {$ifdef ... } ?
Better would be to write the code in a way that it works with 2.6.x as
well.
I can
On Thu, 26 Jun 2014 09:30:58 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/25/2014 05:22 PM, Mattias Gaertner wrote:
ok, then it needs ifdefs in nogui.
Yep.
How does such an ifdef exactly look like ?
{$IF FPC_FULLVERSION = 20701}
Mattias
--
On 06/25/2014 05:22 PM, Mattias Gaertner wrote:
ok, then it needs ifdefs in nogui.
Yep.
How does such an ifdef exactly look like ?
(see my answer to Sven..)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Thu, 26 Jun 2014 09:28:28 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
- TThread.Queue,:
I use this to implement Application.QueuAsyncCall.
I can try to do the (supposedly minimal) code that in TThread.Queue
forwards the procedure of object to the Event queue, native in the
On 06/26/2014 10:52 AM, Mattias Gaertner wrote:
Application.QueueAsyncCall works in nogui if you call
Application.ProcessMessages.
I am just doing the implementation of TApplication. And the point with
_active_ Applications is that the events are called without the user
needing to do a main
On 06/26/2014 09:28 AM, Michael Schnell wrote:
- TThread.GetTickCount64:
I can try to do the (supposedly minimal) code that in
TThread.GetTickCount64 does a system call and some calculations,
native in the implementation of my TApplication class.
This version of the compiler even does
On Thu, 26 Jun 2014 12:13:39 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/26/2014 10:52 AM, Mattias Gaertner wrote:
Application.QueueAsyncCall works in nogui if you call
Application.ProcessMessages.
I am just doing the implementation of TApplication. And the point with
_active_
On Thu, 26 Jun 2014 13:12:14 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/26/2014 12:25 PM, Mattias Gaertner wrote:
Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the
calls in the main thread.
Not true at all.
Huh?
I can rephrase it:
The LCL
Am 26.06.2014 12:36 schrieb Michael Schnell mschn...@lumino.de:
On 06/25/2014 09:57 PM, Sven Barth wrote:
If you rely on the new TThread functionality you'd need to at least put
in guards against compiling with a pre-2.7.1 compiler.
Can I do this by a {$ifdef ... } ?
{$IF FPC_FULLVERSION
On 06/26/2014 01:47 PM, Mattias Gaertner wrote:
I can rephrase it:
The LCL Application.QueueAsyncCalls can be called by any thread, and
executes the calls, when the main thread calls
Application.ProcessMessages. Therefore the calls are executed by the
main thread.
Of course I do know this. But
On Thu, 26 Jun 2014 14:06:15 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Of course I do know this.
Make up your mind. Either I'm Not true at all or I wrote something
right.
But my goal is that these Events are executed
without the user needing to call
On 06/26/2014 02:41 PM, Sven Barth wrote:
Did you even look at the interface of TThread? There's a protected
instance function that calls a public class function with Self as
first parameter. If you use the second one and pass Nil as first
parameter it automatically uses the current thread.
On Thu, 26 Jun 2014 14:41:21 +0200
Sven Barth pascaldra...@googlemail.com wrote:
[...]
{$IF FPC_FULLVERSION 20701}
{$MESSAGE fatal 'You need at least FPC 2.7.1'}
{$ERROR 'You need at least FPC 2.7.1'}
But the Lazarus code must work with 2.6.4, so there must not be an
error.
{$ENDIF}
[...]
On 06/26/2014 02:52 PM, Mattias Gaertner wrote:
On Thu, 26 Jun 2014 14:06:15 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Of course I do know this.
Make up your mind. Either I'm Not true at all or I wrote something
right.
Not true was, that my implementation of
On Thu, 26 Jun 2014 15:07:22 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
But maybe it really is not perfectly compatible, as,
_when_called_in_the_main_thread_, TThread.Queue perhaps does a direct
call instead of a queued schedule, which might not be true with
Il 25/06/2014 15:16, Michael Schnell ha scritto:
On 06/24/2014 09:30 AM, Giuliano Colla wrote:
Widget Types are LCL related. It's the part which actually implements
virtual abstract methods in the Interfaces unit.
Yep.
So it seems perfectly suitable to individually define the
functionality
On 06/26/2014 03:54 PM, Mattias Gaertner wrote:
Application.ProcessMessages calls CheckSynchronize and calls the
queued async calls. Under nogui that's all.
Here the waiting and sleeping mechanism is lacking.
Application.ProcessMessages supposedly calls CheckSynchronize with the
Timeout set
Am 26.06.2014 15:02 schrieb Mattias Gaertner nc-gaert...@netcologne.de:
On Thu, 26 Jun 2014 14:41:21 +0200
Sven Barth pascaldra...@googlemail.com wrote:
[...]
{$IF FPC_FULLVERSION 20701}
{$MESSAGE fatal 'You need at least FPC 2.7.1'}
{$ERROR 'You need at least FPC 2.7.1'}
But the
On Thu, 26 Jun 2014 16:52:59 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/26/2014 03:54 PM, Mattias Gaertner wrote:
Application.ProcessMessages calls CheckSynchronize and calls the
queued async calls. Under nogui that's all.
Here the waiting and sleeping mechanism is lacking.
If
Michael Schnell schrieb:
TThread.Queue in the end calls WakeMainThread() to wake the main thread
(i.e. terminate the CheckSynchronize call waiting for a timeout).
In Simula a single time base is used to trigger events at a known time.
Each event, to occur after a given delay, is enterd into
On 06/24/2014 09:30 AM, Giuliano Colla wrote:
Widget Types are LCL related. It's the part which actually implements
virtual abstract methods in the Interfaces unit.
Yep.
So it seems perfectly suitable to individually define the functionality
of classes that share a common name.
I'm
On 06/23/2014 02:47 PM, Mattias Gaertner wrote:
. Therefore the nogui widget only needs a decent TTimer, preferably
with no extra dependencies like EpikTimer and no calibration.
I added some {$ifdefs} so that my code does not depend on any EpikTimer
related stuff.
Instead it then uses
On Wed, 25 Jun 2014 15:16:38 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
I'm already using packages, but they're run time only packages.
Lazarus does not (yet) support runtime-packages (that with Delphi are a
special kind of dlls).
You mean packages as dynamic libraries
On Wed, 25 Jun 2014 15:21:22 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/23/2014 02:47 PM, Mattias Gaertner wrote:
. Therefore the nogui widget only needs a decent TTimer, preferably
with no extra dependencies like EpikTimer and no calibration.
I added some {$ifdefs} so that my
On 06/25/2014 04:00 PM, Mattias Gaertner wrote:
'Runtime-packages' means something different:
http://wiki.freepascal.org/Lazarus_Packages#Design_Time_vs_Run_Time_package
I see.
Thanks for the Clarification.
I seem to remember that with Delphi the Term RuntimPackage had been used
the way I
On Wed, 25 Jun 2014 16:28:03 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/25/2014 04:00 PM, Mattias Gaertner wrote:
'Runtime-packages' means something different:
http://wiki.freepascal.org/Lazarus_Packages#Design_Time_vs_Run_Time_package
I see.
Thanks for the Clarification.
On 06/25/2014 04:04 PM, Mattias Gaertner wrote:
Instead it then uses TThread.GetTickCount64. Do you think that is
appropriate at this point in time ?
Yes.
I just checked and found that with fpc vertsion 2.6.0-9, which is the
version I installed as a Debian Package for X86-64) TThread does
Am 25.06.2014 16:54 schrieb Michael Schnell mschn...@lumino.de:
On 06/25/2014 04:04 PM, Mattias Gaertner wrote:
Instead it then uses TThread.GetTickCount64. Do you think that is
appropriate at this point in time ?
Yes.
I just checked and found that with fpc vertsion 2.6.0-9, which is the
On 06/25/2014 05:14 PM, Sven Barth wrote:
The TThread extensions are only part of FPC 2.7.1.
Is it decent do base a Lazarus extension on same ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Wed, 25 Jun 2014 16:53:36 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/25/2014 04:04 PM, Mattias Gaertner wrote:
Instead it then uses TThread.GetTickCount64. Do you think that is
appropriate at this point in time ?
Yes.
I just checked and found that with fpc vertsion
On Wed, 25 Jun 2014 17:14:52 +0200
Sven Barth pascaldra...@googlemail.com wrote:
[...]
I just checked and found that with fpc vertsion 2.6.0-9, which is the
version I installed as a Debian Package for X86-64) TThread does not have
CurrentThread,
Queue, and
GetTickCount64
I do
On 25.06.2014 17:18, Michael Schnell wrote:
On 06/25/2014 05:14 PM, Sven Barth wrote:
The TThread extensions are only part of FPC 2.7.1.
Is it decent do base a Lazarus extension on same ?
If you rely on the new TThread functionality you'd need to at least put
in guards against compiling
Il 24/06/2014 09:14, Michael Schnell ha scritto:
On 06/23/2014 06:48 PM, Giuliano Colla wrote:
one must add a Mediator, aware of the new widgetset units, etc. But
currently duplicates aren't allowed. Meaning that a different
widgetset cannot contain units or classes with the same name of an
On 06/23/2014 06:48 PM, Giuliano Colla wrote:
one must add a Mediator, aware of the new widgetset units, etc. But
currently duplicates aren't allowed. Meaning that a different
widgetset cannot contain units or classes with the same name of an LCL
counterpart.
As you never mention this term I
On 06/21/2014 12:43 PM, Giuliano Colla wrote:
I'm trying to figure how to face my nonlcl widgetset project.
I don't understand what you mean by nonlcl widgetset project.
In fact I already do have a working draft of my ActiveNoGUI Widget
Type Project.
Here the goal is to provide another
On 06/22/2014 05:29 PM, Mattias Gaertner wrote:
On Sun, 22 Jun 2014 17:24:46 +0200
Giuliano Colla giuliano.co...@fastwebnet.it wrote:
Meaning that an appropriate IDE extension, and a TReader/TWwriter
extension, would one day permit to stream FpGui components which are
found not in a separate
On Mon, 23 Jun 2014 10:32:50 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/21/2014 12:43 PM, Giuliano Colla wrote:
I'm trying to figure how to face my nonlcl widgetset project.
I don't understand what you mean by nonlcl widgetset project.
This is definitely one of your worst
On 23/06/2014 10:41, Michael Schnell wrote:
On 06/22/2014 05:29 PM, Mattias Gaertner wrote:
On Sun, 22 Jun 2014 17:24:46 +0200
Giuliano Colla giuliano.co...@fastwebnet.it wrote:
For an upcoming ActiveNoGUI Widget Type would it be appropriate (and
easy to do) to use such mechanism to allow a
On Mon, 23 Jun 2014 10:41:22 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
For an upcoming ActiveNoGUI Widget Type would it be appropriate (and
easy to do) to use such mechanism to allow a user to use the Lazarus GUI
designer to place pseudo-visual Objects such as TTimers on a
On 06/23/2014 10:48 AM, Mattias Gaertner wrote:
This is definitely one of your worst hijacking.
Sorry this was not my intention (but just trying to be helpful). :-(
Am I wrong understanding that this thread is about creating a new Widget
Type (or something with a similar target) for Lazarus
On 06/23/2014 10:48 AM, Reinier Olislagers wrote:
You mean on a DataModule? I don't really understand the question...
(@Mattias: sorry if this is off-topic here.)
Imagine a new Widget Type (and Application) that does not provide any
GUI but (other than the current not GUI based Lazarus
On 23/06/2014 11:14, Michael Schnell wrote:
On 06/23/2014 10:48 AM, Reinier Olislagers wrote:
You mean on a DataModule? I don't really understand the question...
When the user wants to use a TTimer, he usually simply drops one on
this Form.
Of course a running Active NoGui application does
On Mon, 23 Jun 2014 11:14:40 +0200
Michael Schnell mschn...@lumino.de wrote:
[...]
Imagine a new Widget Type (and Application) that does not provide any
GUI but (other than the current not GUI based Lazarus Application types)
allows for TTimer (and other Event Queue based stuff).
Why not
On Mon, 23 Jun 2014 11:28:39 +0200
Reinier Olislagers reinierolislag...@gmail.com wrote:
On 23/06/2014 11:14, Michael Schnell wrote:
[...]
Yes, what about a DataModule? Or, for that matter, a regular form. Just
make sure your widgetset does not try to create a graphical form on the
screen. I
Il 23/06/2014 10:56, Michael Schnell ha scritto:
On 06/23/2014 10:48 AM, Mattias Gaertner wrote:
This is definitely one of your worst hijacking.
Sorry this was not my intention (but just trying to be helpful). :-(
Am I wrong understanding that this thread is about creating a new
Widget Type
On 06/23/2014 11:28 AM, Reinier Olislagers wrote:
Yes, what about a DataModule?
Of course a DataModule would do. But here I would need to make the IDE
automatically create a DataMoule as a would-be MainForm. No Idea if
this is possible/sensible/appropriate.
I suppose that is how the
On 06/23/2014 11:43 AM, Mattias Gaertner wrote:
If you implement the TTimer backend, then it will work.
I suppose additionally to the run-time code for TTimer I would need some
design-time code (or at lease parameters) and appropriate streaming
code for my new TTimer class.
-Michael
--
On Mon, 23 Jun 2014 11:52:10 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/23/2014 11:28 AM, Reinier Olislagers wrote:
Yes, what about a DataModule?
Of course a DataModule would do. But here I would need to make the IDE
automatically create a DataMoule as a would-be MainForm. No
On Mon, 23 Jun 2014 11:54:52 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/23/2014 11:43 AM, Mattias Gaertner wrote:
If you implement the TTimer backend, then it will work.
I suppose additionally to the run-time code for TTimer I would need some
design-time code (or at lease
On 06/23/2014 11:41 AM, Mattias Gaertner wrote:
Why not put this in the existing nogui widgetset?
Maybe his in fact is a good idea.
I did not dare to suggest this, because I always in great fear to break
something, as I am not at all an expert with the Lazarus / LCL internals.
What is the
On 06/23/2014 10:54 AM, Mattias Gaertner wrote:
What do you mean with pseudo form?
A thingy supposedly working like TDataModule, that the IDE is able to
use as MainForm.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 06/23/2014 12:01 PM, Mattias Gaertner wrote:
So your nogui widgetset has that already.
I'll take a look...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 06/23/2014 11:58 AM, Mattias Gaertner wrote:
You can register a new project type that does that.
I'll try to fond out how to do that.
(That means that the Widget Type (i.e. the code that is $ifdef'ed by
the appropriate setting of the WidgetType variable) and the IDE code
itself does not
1 - 100 of 122 matches
Mail list logo
