On Tue, 04 Feb 2014 14:19:07 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
and in my experience the thing that's most likely to work is DVD
playback because the data stream is (as I understand it) sent via a
backdoor to the graphics chips bypassing most of the kernel and X.
My last message was just a failure in using my mail client.
Sorry for the noise.
R:
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 11/14/2014 01:16 PM, Reimar Grabowski wrote:
but you actually gain nothing, because of how the drivers work.
Are we (still) talking multi-core systems gaining performance by really
parallel work ?
You will gain nothing in the work of the GUI framework called by the
Lazarus program *if*
On Fri, 14 Nov 2014 15:55:07 +0100
Michael Schnell mschn...@lumino.de wrote:
Are we (still) talking multi-core systems gaining performance by really
parallel work ?
No, we aren't talking anything (see second mail).
If you did not get it there may be a problem with your mail client(1), if you
On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote:
Window managers do not care about widgets,,,
So maybe I am confused about the term Window Manager (I think I did
not introduce it here)
-Michael
--
___
Lazarus mailing list
Michael Schnell schrieb:
On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote:
Window managers do not care about widgets,,,
So maybe I am confused about the term Window Manager (I think I did
not introduce it here)
MS Windows does not distinguish between the window manager and
widgetset,
On 07/02/14 02:57, Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
I think that the only thing remotely worth pursuing, bearing in
mind the current state of widget sets etc., would be whether an LCL
in a dll/so animated by its own thread (which MichaelS has already
said was doable)
Mark Morgan Lloyd schrieb:
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
OK, so assuming an OS similar to X, can a single app support two
forms on different displays, and/or move forms between displays?
That's the job of the desktop/window manager, on every OS. When a form
shall
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
OK, so assuming an OS similar to X, can a single app support two
forms on different displays, and/or move forms between displays?
That's the job of the desktop/window manager, on
On 02/06/2014 05:39 PM, Mark Morgan Lloyd wrote:
OK, so assuming an OS similar to X, can a single app support two forms
on different displays, and/or move forms between displays? Because if
it could, one of those displays could be a local X session and the
other could be something like a VNC
On 02/07/2014 03:57 AM, Hans-Peter Diettrich wrote:
fill their video buffer,
This only sounds appropriate for pixel graphics, not for the complex
stuff widgets create and that result in object descriptions that are
rendered by the processor in the video adapter.
-Michael
--
Mark Morgan Lloyd schrieb:
Try to move a form with the mouse to an different monitor. This works
on Linux without additional libraries. Linux also can show the same
form on all desktops, without additional code or libraries.
Oh no it doesn't. You need something like Xinerama (RandR, Xdmx)
Michael Schnell schrieb:
On 02/07/2014 03:57 AM, Hans-Peter Diettrich wrote:
fill their video buffer,
This only sounds appropriate for pixel graphics, not for the complex
stuff widgets create and that result in object descriptions that are
rendered by the processor in the video adapter.
On 02/05/2014 07:37 PM, Reimar Grabowski wrote:
OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus
and fpc and do everything in ASM.
And loose your job for missing deadline after deadline. ;)
...
What I meant by the sarcasm is: Even if there are other ways to reach a
On Wed, Feb 05, 2014 at 01:44:59PM +, Mark Morgan Lloyd wrote:
Particularly on systems with some sort of interconnect between
processor units, it's entirely possible to find the threads associated
with a single program spread over a comparatively large physical volume,
with each
Marco van de Voort wrote:
The question is more how you are going to display that stuff swiftly. GDI?
Forget it. OpenGL gives up at about 40-60 MByte/s on a discrete model, and
half on integrated video. (HD4000)
One can try to create a GUI for this already remote scenario (independent
On Thu, 06 Feb 2014 10:31:15 +0100
Michael Schnell mschn...@lumino.de wrote:
What I meant by the sarcasm is: Even if there are other ways to reach a
goal, it does make sense to work with the powers to help improving a
tool that shows shortcomings in certain aspects, while being perfectly
On 02/06/2014 11:54 AM, Reimar Grabowski wrote:
You see that as shortcomings. Most others (even widgetset developers) see
thread-safe GUIs as nonsense without real benefit, else they would be available.
I think we can agreee to disagree.
This is a funny opinion indeed.
- we did a project in
On Thu, 06 Feb 2014 12:19:22 +0100
Michael Schnell mschn...@lumino.de wrote:
On 02/06/2014 11:54 AM, Reimar Grabowski wrote:
You see that as shortcomings. Most others (even widgetset developers) see
thread-safe GUIs as nonsense without real benefit, else they would be
available.
I
On 02/06/2014 01:21 PM, Reimar Grabowski wrote:
So a gain for a small amount of apps but a lot of work to support the solution.
Correct, but this is not the definition of not being a shortcoming.
Currently there are other options but you do not want to use them. Your choice.
Can't you read ?
Michael Schnell schrieb:
On 02/06/2014 11:54 AM, Reimar Grabowski wrote:
You see that as shortcomings. Most others (even widgetset developers)
see thread-safe GUIs as nonsense without real benefit, else they would
be available.
I think we can agreee to disagree.
This is a funny opinion
On 02/06/2014 02:13 PM, Hans-Peter Diettrich wrote:
When an application relies on high speed updates, it should serialize
these requests itself, as required, instead of leaving this to the
desktop manager and its arbitrary request scheduling.
Once again, this is not about serializing requests
On Thu, 06 Feb 2014 13:38:47 +0100
Michael Schnell mschn...@lumino.de wrote:
Can't you read ?
Nope. The batteries of my cyberpig which does the reading for me are running
low.
Can you send a voice recording of your last mail?
Or a video of you dancing it (perhaps multi-threaded)?
Have a nice
On Thu, Feb 06, 2014 at 10:21:12AM +, Mark Morgan Lloyd wrote:
One can try to create a GUI for this already remote scenario (independent
processes display to independent sections of the screen), but if the
systems below can't handle it, what's the point?
I agree, with the caveat that
Marco van de Voort wrote:
On Thu, Feb 06, 2014 at 10:21:12AM +, Mark Morgan Lloyd wrote:
One can try to create a GUI for this already remote scenario (independent
processes display to independent sections of the screen), but if the
systems below can't handle it, what's the point?
I agree,
On 02/06/2014 04:17 PM, Mark Morgan Lloyd wrote:
I think that the only thing remotely worth pursuing, bearing in mind
the current state of widget sets etc
I don't suppose this makes much sense unless the infrastructure called
by the LCL supports it in a proven way.
OTOH:
In the other
Michael Schnell wrote:
On 02/06/2014 04:17 PM, Mark Morgan Lloyd wrote:
I think that the only thing remotely worth pursuing, bearing in mind
the current state of widget sets etc
I don't suppose this makes much sense unless the infrastructure called
by the LCL supports it in a proven
Mark Morgan Lloyd schrieb:
I think that the only thing remotely worth pursuing, bearing in mind the
current state of widget sets etc., would be whether an LCL in a dll/so
animated by its own thread (which MichaelS has already said was doable)
could output to a buffer, which could then be
Michael Schnell schrieb:
On 02/06/2014 02:13 PM, Hans-Peter Diettrich wrote:
When an application relies on high speed updates, it should serialize
these requests itself, as required, instead of leaving this to the
desktop manager and its arbitrary request scheduling.
Once again, this is not
Mark Morgan Lloyd schrieb:
OK, so assuming an OS similar to X, can a single app support two forms
on different displays, and/or move forms between displays?
That's the job of the desktop/window manager, on every OS. When a form
shall be updated on screen, the manager determines the monitor
Hans-Peter Diettrich wrote:
Mark Morgan Lloyd schrieb:
OK, so assuming an OS similar to X, can a single app support two forms
on different displays, and/or move forms between displays?
That's the job of the desktop/window manager, on every OS. When a form
shall be updated on screen, the
On 02/04/2014 07:10 PM, Hans-Peter Diettrich wrote:
Right, nobody tries to support threads in GUI related libraries,
because this doesn't make sense.
IMHO it does make sense in certain applications.
The one my colleagues did is a user interfaces application for a huge
(including many PCs
On 02/04/2014 03:19 PM, Mark Morgan Lloyd wrote:
I'm not unreservedly siding with MichaelS's position, since unless it
completely bypassed any existing widget set (and preferably drew
directly to the framebuffer) it could be screwed at any time by
off-project developers (i.e. the Gnome, Qt or
On 02/04/2014 03:42 PM, Michael Van Canneyt wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There
is therefor no need to have it refreshed in intervals that the brain
cannot discern anyway. What
On 02/04/2014 04:02 PM, Mark Morgan Lloyd wrote:
I'm afraid that's... highly questionable. The more video streams
(etc.) that are visible the smoother you want the overall presentation
to be: the human brain is /very/ sensitive to small timing differences.
Yep.
We don't do such systems, but
On 02/04/2014 04:02 PM, Reimar Grabowski wrote:
You can talk to the GPU from different threads (with a little
overhead) but you actually gain nothing, because of how the drivers work.
Very wrong, IMHO.
There is a lot to do for the CPU between the user programmer's code
calls an Language RTL-
On 02/04/2014 04:20 PM, Reimar Grabowski wrote:
It is not unusual to show the same frame three times to bring the
framerate up to 72fps to reduce the black screen time which will be
percieved as flickering. Motion blur helps a lot to make the
experience 'smooth'. Why do you think it is
On 02/04/2014 03:48 PM, Sven Barth wrote:
When you call a method of a widget that results in some GUI related
stuff Qt checks the current thread ID against the thread ID the
QApplication was created in (or more precisely: the thread ID the
event loop is running in) using an Assert. While there
On 02/04/2014 03:11 PM, Michael Van Canneyt wrote:
Exactly:
you can perfectly collect 20 stills and display a composed view of all
20 stills,
10 times a second. Should be perfectly in reach of a single thread.
Sounds correct on the first sight, but my colleagues found that this was
not good
Michael Schnell wrote:
On 02/04/2014 04:02 PM, Reimar Grabowski wrote:
You can talk to the GPU from different threads (with a little
overhead) but you actually gain nothing, because of how the drivers work.
Very wrong, IMHO.
There is a lot to do for the CPU between the user programmer's code
On Tue, 04 Feb 2014 21:17:47 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
IMHO being implemented in the same driver is a hint that they use
similar mechanics.
But they aren't implemented in the same driver: video (i.e. mpeg
playback etc.) uses the standard X drivers
On 02/05/2014 10:51 AM, Michael Van Canneyt wrote:
Judging by your explanation to Dido, it seems you must explain your
users the limits of their own brains. Adding monitors and indicators
does not
guarantee that they will process more info :)
Please see the discussion on surveillance camera
On Wed, 05 Feb 2014 11:18:28 +0100
Michael Schnell mschn...@lumino.de wrote:
On 02/04/2014 04:02 PM, Reimar Grabowski wrote:
You can talk to the GPU from different threads (with a little
overhead) but you actually gain nothing, because of how the drivers work.
Very wrong, IMHO.
This is not
On 02/05/2014 11:40 AM, Mark Morgan Lloyd wrote:
I think a realistic question is how close can multiple threads get to
a form without fouling up the LCL or widget set.
Yep !
Seemingly not doable at the moment. The LCL _could_ be updated to be
reentrant, but if the Widget Set it binds to does
On 02/05/2014 12:15 PM, Reimar Grabowski wrote:
Talk to the driver directly ...
OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus
and fpc and do everything in ASM.
But in fact Lazarus is more fun :-) .
-Michael
--
___
Michael Schnell schrieb:
On 02/05/2014 10:51 AM, Michael Van Canneyt wrote:
Judging by your explanation to Dido, it seems you must explain your
users the limits of their own brains. Adding monitors and indicators
does not
guarantee that they will process more info :)
Please see the
Hans-Peter Diettrich wrote:
Please note that even a CPU with multiple cores doesn't have multiple
data busses for the cores. That's the narrowest bottleneck, which limits
That's a good point, but strictly it's an implementation detail which
could be very different on even different chips of
On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote:
Then you have to include appropriate hardware, where multiple GPUs are
preferable to multiple CPUs when it comes to processing multiple video
streams concurrently.
In fact the system runs just fine for multiple customers right now with
many
On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote:
Please note that even a CPU with multiple cores doesn't have multiple
data busses for the cores. That's the narrowest bottleneck, which
limits the throughput on every standard machine.
Right, But this is why 1st Level cache has been invented
On Wed, 05 Feb 2014 12:31:42 +0100
Michael Schnell mschn...@lumino.de wrote:
On 02/05/2014 12:15 PM, Reimar Grabowski wrote:
Talk to the driver directly ...
OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus
and fpc and do everything in ASM.
And loose your job for
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
(And I learned that in fact XInitThreads() can be called in
On Tue, 4 Feb 2014, Michael Schnell wrote:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make sense to
create multiple X sessions (i.e. one per thread) in a single program.
Thread aware does
On 02/04/2014 11:12 AM, Michael Van Canneyt wrote:
It kind of defeats the purpose, as it suggests that only 1 thread at a
time can access the display.
Of course concentrating the GUI stuff to a single thread makes things a
lot easier to handle.
But I already did explain the purpose I (once)
BTW.:
What we did to take advantage of the multicore architecture in fact was
creating multiple applications, each of which handles such a GUI element
in a dedicated Window that is automatically placed at the appropriate
location above the main window. But of course the overhead for
managing
Michael Schnell wrote:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
At that point why not bite the bullet and
Michael Schnell schrieb:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
This may make sense with remote
On 02/04/2014 11:36 AM, Mark Morgan Lloyd wrote:
At that point why not bite the bullet and exploit GPU parallelism?
Yep ! :-)
(And this hint is going out to whom ? ;-) )
KDE and Qt are minor issues, far more significant is arbitrary
restrictions that GTK imposes because they envisage some
On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote:
Right, and the restriction to one widgetset resides in the Lazarus
widgetset handling.
I do know. But it does not make much sense to be nagging towards the
powers here about LCL not being reentrant, if the library (Widget Set,
...) it
Am 04.02.2014 11:04, schrieb Michael Schnell:
Of course it might be that QT (or KDE) impose additional restrictions
(though I still suppose that this can be handles somehow).
No, this can not be handled somehow (and it's not KDE, but Qt itself):
Upon creation of the QApplication class it
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as
well. Certain events like rendering are also checked for the thread ID.
While I don't exactly see the point (as
On Tue, 4 Feb 2014, Michael Schnell wrote:
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as well.
Certain events like rendering are also checked for the thread
On 02/04/2014 02:40 PM, Michael Van Canneyt wrote:
I play a video at full HD, 1 thread handles the screen display. It
works just fine,
Playing two videos at the same time does make sense in some applications
(we create 20 small videos in our application to have the user see
what the system
On Tue, 4 Feb 2014, Michael Schnell wrote:
On 02/04/2014 02:40 PM, Michael Van Canneyt wrote:
I play a video at full HD, 1 thread handles the screen display. It works
just fine,
Playing two videos at the same time does make sense in some applications (we
create 20 small videos in our
Michael Van Canneyt wrote:
The GUI is for use by humans. That means that there is no point
whatsoever in updating the GUI more than 10 times per second: the human
eye cannot process information faster than that, let alone that the
brain can grasp the *meaning* of what the eye has seen in such
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process information faster than that, let alone that the brain can
On Tue, 4 Feb 2014 14:40:21 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process information faster than that, let alone that
Am 04.02.2014 14:04, schrieb Michael Schnell:
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID
and every GUI widget is checked that it is owned by this thread ID as
well. Certain events like rendering are also checked for the thread
On Tue, 04 Feb 2014 14:19:07 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
and in my experience the thing that's most likely to work is DVD
playback because the data stream is (as I understand it) sent via a
backdoor to the graphics chips bypassing most of the kernel and X.
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There
is therefor no need to have it refreshed in intervals that the brain
On Tue, 4 Feb 2014, Reimar Grabowski wrote:
On Tue, 4 Feb 2014 14:40:21 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There is
therefor no need to
On Tue, 4 Feb 2014 15:59:07 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
Traditional Film uses 24 FPS, this was considered twice the speed of what
was/is
needed to experience motion 'fluently'.
It is not unusual to show the same frame three times to bring the framerate up
On 04/02/14 15:15, Michael Van Canneyt wrote:
[...]
I would be very interested to see experiments proving that this will
make an actual difference in human operator efficiency.
I know this is completely different ballpark, but, why do you think,
3d games are all in pursuit of FPS ? And
On Tue, 4 Feb 2014, Reimar Grabowski wrote:
On Tue, 4 Feb 2014 15:59:07 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
Traditional Film uses 24 FPS, this was considered twice the speed of what was/is
needed to experience motion 'fluently'.
It is not unusual to show the same
On Tue, 4 Feb 2014 17:07:23 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
But this does not enable you to process the *information* displayed at
such a speed.
As stated in my last mail the USAF and their pilots do not share your
opinion.
Please... These people are
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
In addition, there are standards for e.g. flashing indicators in
safety-critical applications which are specified with much finer
resolution than 100 mSec.
So a 10Hz update is totally out of the question these days:
Reimar Grabowski wrote:
On Tue, 04 Feb 2014 14:19:07 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
and in my experience the thing that's most likely to work is DVD
playback because the data stream is (as I understand it) sent via a
backdoor to the graphics chips bypassing
Michael Van Canneyt wrote:
But this does not enable you to process the *information* displayed
at such a speed.
As stated in my last mail the USAF and their pilots do not share your
opinion.
Please... These people are primed for this kind of thing.
But the general discussion didn't say
Michael Schnell schrieb:
On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote:
Right, and the restriction to one widgetset resides in the Lazarus
widgetset handling.
I do know. But it does not make much sense to be nagging towards the
powers here about LCL not being reentrant, if the library
On Tue, 04 Feb 2014 18:21:14 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
With the major caveat that the interfaces used for playing video and for
program-generated graphics are distinct (hardware MPEG decompression in
one case, OpenGL in the other) and having one work
Reimar Grabowski wrote:
On Tue, 04 Feb 2014 18:21:14 +
Mark Morgan Lloyd markmll.laza...@telemetry.co.uk wrote:
With the major caveat that the interfaces used for playing video and for
program-generated graphics are distinct (hardware MPEG decompression in
one case, OpenGL in the other)
On 01/17/2014 06:25 PM, Sven Barth wrote:
Wouldn't help much, because e.g. Qt does not allow usage of GUI
widgets in multiple threads.
http://qt-project.org/doc/qt-4.8/threads.html
I did not thoroughly read this but it seems that QT is thread-aware
-Michael
--
On Mon, 20 Jan 2014, Michael Schnell wrote:
On 01/17/2014 06:25 PM, Sven Barth wrote:
Wouldn't help much, because e.g. Qt does not allow usage of GUI widgets in
multiple threads.
http://qt-project.org/doc/qt-4.8/threads.html
I did not thoroughly read this but it seems that QT is
Am 20.01.2014 10:51 schrieb Michael Schnell mschn...@lumino.de:
On 01/17/2014 06:25 PM, Sven Barth wrote:
Wouldn't help much, because e.g. Qt does not allow usage of GUI widgets
in multiple threads.
http://qt-project.org/doc/qt-4.8/threads.html
I did not thoroughly read this but it seems
On 01/20/2014 11:10 AM, Sven Barth wrote:
Trust me, I'm currently working with Qt's internals as I've just
finished the port of Qt to my company's OS, so I know what I'm talking
about... (and I've already hit an assertion regarding this)
I see.
In fact I already came across applications
On 01/20/2014 11:01 AM, Michael Van Canneyt wrote:
http://qt-project.org/doc/qt-4.8/threads-starting.html
Note that QCoreApplication::exec() must always be called from the
main thread
(the thread that executes main()), not from a QThread. In GUI
applications,
the main thread is also
Am 20.01.2014 14:47 schrieb Michael Schnell mschn...@lumino.de:
On 01/20/2014 11:01 AM, Michael Van Canneyt wrote:
http://qt-project.org/doc/qt-4.8/threads-starting.html
Note that QCoreApplication::exec() must always be called from the main
thread
(the thread that executes main()), not
On Fri, 17 Jan 2014, Antonio Fortuny wrote:
Hi All.
Maybe not a Lazarus/FPC specific question but development whill be done using
Lazarus/FPC.
I wonder if I can build an application (service) having multiple threads
running (Indy TCP/IP server, multiple connections) and every thread calls
Le 17/01/2014 12:53, Michael Van Canneyt a écrit :
On Fri, 17 Jan 2014, Antonio Fortuny wrote:
Hi All.
Maybe not a Lazarus/FPC specific question but development whill be
done using Lazarus/FPC.
I wonder if I can build an application (service) having multiple
threads running (Indy TCP/IP
On Fri, Jan 17, 2014 at 8:34 AM, Antonio Fortuny
a.fort...@sitasoftware.lu wrote:
Hi All.
Maybe not a Lazarus/FPC specific question but development whill be done
using Lazarus/FPC.
I wonder if I can build an application (service) having multiple threads
running (Indy TCP/IP server, multiple
On 01/17/2014 01:25 PM, Marcos Douglas wrote:
is better not use global variables in the DLL.
Of course I agree.
A reason for using global variables in a DLL might be to access that
value as well in the DLL as in the main program.
Is this even possible ?
(To allow for this loading the DLL
Am 17.01.2014 14:23, schrieb Michael Schnell:
On 01/17/2014 01:25 PM, Marcos Douglas wrote:
is better not use global variables in the DLL.
Of course I agree.
A reason for using global variables in a DLL might be to access that
value as well in the DLL as in the main program.
Is this even
On Fri, Jan 17, 2014 at 10:23 AM, Michael Schnell mschn...@lumino.de wrote:
On 01/17/2014 01:25 PM, Marcos Douglas wrote:
is better not use global variables in the DLL.
Of course I agree.
A reason for using global variables in a DLL might be to access that value
as well in the DLL as in
Vrey interesting indeed.
I agree with Marcos on his last remark. I'm concerned with
multi-threading from a long time now and I'm used to avoid global vars
in any case.
Reading your answers I'm more strongly convinced that this position
should be the master rule when dealing with threads. But
On 01/17/2014 03:06 PM, Marcos Douglas wrote:
But why do you need a global var in the DLL? IMHO (and for many
programmers around the world), global var is not good, even in the
application code.
I don't suppose I'll ever want to do this. :-) - I just was being nosy.
-Michael
--
Marcos Douglas wrote:
But why do you need a global var in the DLL? IMHO (and for many
programmers around the world), global var is not good, even in the
application code.
Although I think that this is in part received wisdom, dating back to
some of the earliest ALGOL computers where globals
On Fri, Jan 17, 2014 at 12:38 PM, Mark Morgan Lloyd
markmll.laza...@telemetry.co.uk wrote:
Marcos Douglas wrote:
But why do you need a global var in the DLL? IMHO (and for many
programmers around the world), global var is not good, even in the
application code.
Although I think that this
On 01/17/2014 05:47 PM, Marcos Douglas wrote:
I said: IMHO, not only programmers around the world... so, for me is
not a received wisdom, but a lesson learned. ;-)
Unfortunately Lazarus uses global variables in the LCL. Otherwise it
would be possible to create a project with a TApplication
Am 17.01.2014 17:58 schrieb Michael Schnell mschn...@lumino.de:
On 01/17/2014 05:47 PM, Marcos Douglas wrote:
I said: IMHO, not only programmers around the world... so, for me is
not a received wisdom, but a lesson learned. ;-)
Unfortunately Lazarus uses global variables in the LCL.
Marcos Douglas wrote:
So going back to the specific question, as I understand it you get a global
in a DLL if you define a form in it. In practical terms it might not be
immediately usable, but as an example I've used a form in a DLL as a
template and copied menu entries from it to an
1 - 100 of 214 matches
Mail list logo
