On Tue, 23 Apr 2013, silvioprog wrote:
Hi,
In FPC 2.7.1+ you've the Queue method, but it doesn't exists in FPC 2.6.2. So,
what you uses instead it? The Synchronize method does not works in this case.
To my knowledge, nothing is available.
Michael.
--
On Tue, Apr 23, 2013 at 08:34:53PM -0300, silvioprog wrote:
In FPC 2.7.1+ you've the Queue method, but it doesn't exists in FPC 2.6.2.
So, what you uses instead it? The Synchronize method does not works in this
case.
If Windows only, just use postmessage.
--
Seemingly no support for Linux, Android.
- http://www.embarcadero.com/products/rad-studio
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 04/24/2013 09:45 AM, Marco van de Voort wrote:
On Tue, Apr 23, 2013 at 08:34:53PM -0300, silvioprog wrote:
In FPC 2.7.1+ you've the Queue method, but it doesn't exists in FPC 2.6.2.
So, what you uses instead it? The Synchronize method does not works in this
case.
If Windows only, just use
On 04/24/2013 01:34 AM, silvioprog wrote:
In FPC 2.7.1+ you've the Queue method, but it doesn't exists in FPC
2.6.2. So, what you uses instead it? The Synchronize method does not
works in this case.
I'm implementing a small unit with some interfaces to use of sockets
with TCP/IP protocol
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 01:34 AM, silvioprog wrote:
In FPC 2.7.1+ you've the Queue method, but it doesn't exists in FPC 2.6.2.
So, what you uses instead it? The Synchronize method does not works in this
case.
I'm implementing a small unit with some
- different compilers for the supported targets - the new ARC is only
available for ARM iOS. How can they sell this ... as a cross-platform
solution ?
- do we have September again ? Now they are going to sell you beta
software in a half year cycle (instead of yearly as they used to do in
the
On 04/24/2013 10:41 AM, Michael Van Canneyt wrote:
By contrast it works only in lazarus GUI programs, and is useless e.g.
for daemons.
Of course I do know that (as I issued the request for a active non-GUI
Widget Type with support for a Pascal EventQueue for multiple
platforms - like mse
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 10:41 AM, Michael Van Canneyt wrote:
By contrast it works only in lazarus GUI programs, and is useless e.g. for
daemons.
Of course I do know that (as I issued the request for a active non-GUI
Widget Type with support for a Pascal
Am 24.04.2013 11:06, schrieb Michael Schnell:
On 04/24/2013 10:41 AM, Michael Van Canneyt wrote:
By contrast it works only in lazarus GUI programs, and is useless
e.g. for daemons.
Of course I do know that (as I issued the request for a active
non-GUI Widget Type with support for a Pascal
On 04/24/2013 11:21 AM, Michael Van Canneyt wrote:
Somewhere the main program loop must call checksynchronize, that is all.
If that (i.e. doing a pseudo-queue in the user-code) is true for all
platforms (which would mean that an EventQueue does exist and just is
not polled automatically),
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 11:21 AM, Michael Van Canneyt wrote:
Somewhere the main program loop must call checksynchronize, that is all.
If that (i.e. doing a pseudo-queue in the user-code) is true for all
platforms (which would mean that an EventQueue
Am 24.04.2013 11:25, schrieb Michael Schnell:
On 04/24/2013 11:21 AM, Michael Van Canneyt wrote:
Somewhere the main program loop must call checksynchronize, that is all.
If that (i.e. doing a pseudo-queue in the user-code) is true for all
platforms (which would mean that an EventQueue does
On 24 April 2013 09:52, Adrian Veith adr...@veith-system.de wrote:
- different compilers for the supported targets - the new ARC is only
available for ARM iOS. How can they sell this ... as a cross-platform
solution ?
- do we have September again ? Now they are going to sell you beta
On 04/24/2013 11:32 AM, Sven Barth wrote:
Please note that if you use TThread.Queue or TThread.Synchronize from
within the main thread then your code won't be queued, but executed
immediately. It is only designed for enqueing code execution for
threads that are not the main thread.
I see the
On 04/24/2013 11:34 AM, Sven Barth wrote:
QueueAsyncCall is implemented/provided by the LCL not the RTL.
OK. I understand. But this in fact is a very bad idea.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Am 24.04.2013 11:48, schrieb Michael Schnell:
On 04/24/2013 11:34 AM, Sven Barth wrote:
QueueAsyncCall is implemented/provided by the LCL not the RTL.
OK. I understand. But this in fact is a very bad idea.
QueueAsyncCall was implemented before TThread.Queue, because the Lazarus
developers
Am 24.04.2013 11:44, schrieb Michael Schnell:
On 04/24/2013 11:32 AM, Sven Barth wrote:
Please note that if you use TThread.Queue or TThread.Synchronize from
within the main thread then your code won't be queued, but executed
immediately. It is only designed for enqueing code execution for
On 04/24/2013 11:48 AM, Sven Barth wrote:
QueueAsyncCall was implemented before TThread.Queue, because the
Lazarus developers thought it is a good idea (which I basically agree
to)...
Yep.
But now it would be a good idea to overcome this situation - that
obviously is introduced by two
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 11:48 AM, Sven Barth wrote:
QueueAsyncCall was implemented before TThread.Queue, because the Lazarus
developers thought it is a good idea (which I basically agree to)...
Yep.
But now it would be a good idea to overcome this
On 04/24/2013 12:34 PM, Michael Van Canneyt wrote:
´
What are you waiting for ?
All you need to do is implement an event loop. All the rest is there.
As I said, I already did try this some years ago Trying both to
implement a new event queue mechanism (stolen from mse), and - better
idea -
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 12:34 PM, Michael Van Canneyt wrote:
´
What are you waiting for ?
All you need to do is implement an event loop. All the rest is there.
As I said, I already did try this some years ago Trying both to implement a
new event queue
On Wed, Apr 24, 2013 at 01:03:38PM +0200, Michael Van Canneyt wrote:
Of course it can.
You make the task far too complex. Start by NOT looking at the LCL code.
You need simply to start with
TCustomEventLoopApplication = Class(TCustomApplication)
// Whatever
end;
Which abstracts
On 04/24/2013 11:52 AM, Sven Barth wrote:
QueueAsyncCall can't do anything different, because it needs to go
through either TThread.Queue or TThread.Synchronize as the queue's
implementation is not directly accessible from the outside and I don't
intend to change this.
It can't be true
Jürgen Hestermann schrieb:
Am 2013-04-23 19:11, schrieb Howard Page-Clark:
On 23/04/13 5:20, Jürgen Hestermann wrote:
I am stuck again. How can I make long (wide) text visible in a
restricted window?
In a proper design it should be a matter of enabling the scrollbars of
the component, and
Michael Van Canneyt schrieb:
On Wed, 24 Apr 2013, Michael Schnell wrote:
On 04/24/2013 11:21 AM, Michael Van Canneyt wrote:
Somewhere the main program loop must call checksynchronize, that is all.
If that (i.e. doing a pseudo-queue in the user-code) is true for all
platforms (which
vfclists . schrieb:
Why don't they give make it a 120 or 180 day evaluation with bug fixes
included? It takes time to evaluate a product as well as develop a good
product in it, something you may be doing in your spare time. If after
using that long it turns out to be good enough the
How can they sell this ... as a cross-platform solution ?
For most people, having at least two different targets already counts
cross-platform, even if the host is only one (yaoming). The prerequisites
suck, REALLY REALLY SUCK (why do the hell they need .NET framework there?)
Reference:
--- El mié 24-abr-13, Jürgen Hestermann juergen.hesterm...@gmx.de escribió:
Still I am wondering why nobody seems to miss a horizontal
shift for TListBox and TStringGrid (especially because a
slider is shown for TStringGrid but does not work). Are
these bugs which nobody discovered since
On 24.04.2013 17:54, leledumbo wrote:
How can they sell this ... as a cross-platform solution ?
For most people, having at least two different targets already counts
cross-platform, even if the host is only one (yaoming). The prerequisites
suck, REALLY REALLY SUCK (why do the hell they need
Hello
I did everything i found in the wicki, still the app
does not let me insert breakpoints (the lines show a ?).
It builds fine but when I run it, it says it cannot find the file
with the break point.
I have shown the options in my previous posts.
I do not know what to do anymore.
Should I
On 2013-04-24 16:54, leledumbo wrote:
The prerequisites
suck, REALLY REALLY SUCK (why do the hell they need .NET framework there?)
Because they had the brain fart to write the Delphi IDE in .NET, thus
giving it the special features of being super slow, incredibly memory
hungry and not portable
On 2013-04-24 16:54, leledumbo wrote:
The prerequisites
suck, REALLY REALLY SUCK (why do the hell they need .NET framework there?)
I also forgot to mention the biggest laughing stock of them all... A
full install with help just takes 45-60 minutes. WTF! Yeah, I heard them
say that on todays
Hello guys,
The classes of SSockets allow to use write and read simultaneously? (eg.
Gtalk/Skype send messages even receiving a attached file)
Please excuse if the question is silly, I even got to do a test, but I
wanted to know because I need to implement a multi-platform code, using
write/read
Am 2013-04-24 20:25, schrieb Jesus Reyes:
Still I am wondering why nobody seems to miss a horizontal
shift for TListBox and TStringGrid (especially because a
slider is shown for TStringGrid but does not work). Are
these bugs which nobody discovered since years? I can't
believe it.
Do you
35 matches
Mail list logo
