Hallo IvankoB,
Du schriebst am Fri, 02 Nov 2012 14:03:52 +0500:
Have You tried the Synapse network library ? (pure Pascal) It's
No. AS for one I don't know it, and for another I wanted to use only FPC
and MSEGUI internals, no external components. Well, and my own code, after
all...
But I might have a look at the library anyway, thank you for mentioning it.
===
An excellent network library :) Me use it for all my network
utilities, WWW-robots,software updaters.. [min console app size in
LINUX : FPC+Synapse = 320K, FPC+Synapse+MSEgui=650K]
as there is just one
Hallo Ivanko,
Du schriebst am Sun, 4 Nov 2012 00:55:00 +0500:
[Synapse network library]
An excellent network library :) Me use it for all my network
utilities, WWW-robots,software updaters.. [min console app size in
LINUX : FPC+Synapse = 320K, FPC+Synapse+MSEgui=650K]
Fine - but I need
Have You tried the Synapse network library ? (pure Pascal) It's
multithreading-aware.
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one
Hallo Martin,
once more a report on the lock-up problem.
Today I tried another approach, just using a flag mechanism to signal data
transfer between the network and GUI threads of the program, having a timer
function doing the GUI updating.
This seemed to work quite well now, even for those
Hallo Martin,
concerning the lock-ups, I'm sorry having to report that the modifications
mentioned recently didn't have a very positive effect.
There might be a slight enhancement as to the network connection, but now
there are nearly reproducible lock-ups on tab-page-changes, which I use to
show
Hallo Martin,
Du schriebst am Tue, 30 Oct 2012 04:39:04 +0100:
Calling X11 or gdi32 functions by tcanvas is thread-safe. So it is
...
gdi32 means windows.
Oh - yes, sure. I overlooked that completely, sorry.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht
Hallo Martin,
Du schriebst am Sun, 28 Oct 2012 18:54:52 +0100:
a - albeit short - detour: You consistently wrote quite for a
parameter originally named quiet.
Where? I'd like to fix it.
kernel/mseapplication.pas l.324-330, l. 1226, l. 1239, l. 1252 dependends.
You might just search for
Hallo Martin,
Du schriebst am Fri, 26 Oct 2012 06:47:14 +0200:
I think we should concentrate on fixing the deadlock.
Another response - on preparing for a work around I did find that the
program code already uses a thread for the network communication which I
hadn't remembered any more. As the
Hallo Martin,
Du schriebst am Fri, 26 Oct 2012 06:47:14 +0200:
synchronize call comparable to Delphi's in your msegui?)
Yes.
Ok, that would make the intended approach feasible.
if left undisturbed long enough)? Could a thread be sufficiently
uncoupled from the main process to be
Hallo Ivanko,
Du schriebst am Fri, 26 Oct 2012 03:29:48 +0500:
holds for _non_-interactive
programs
=
Win-32 serveices _can_ be interactive - the service manager even
provides an option allow to interact with desktop for each of its
services :)
Well, yes, to some extend. I.e. at
Hallo Martin,
Du schriebst am Thu, 25 Oct 2012 07:56:52 +0200:
Possibly Sieghard wants to have its client-side app of service
...
Simply write msenogui instead of msegui in uses of the main program
in oder to instantiate a event driven tnoguiapplication without GUI
elements. Examples are
holds for _non_-interactive
programs
=
Win-32 serveices _can_ be interactive - the service manager even
provides an option allow to interact with desktop for each of its
services :)
--
Everyone hates slow
On Thursday 25 October 2012 20:48:29 Sieghard wrote:
[...]
What do you think of a setup using a secondary thread only running a
periodical timer that every so often synchronizes (is there a synchronize
call comparable to Delphi's in your msegui?)
Yes.
with the main thread in an
attempt
On Tuesday 23 October 2012 17:57:45 Sieghard wrote:
Hello Martin,
I would like (or rather, am obliged) to create an application that can
run for a long time without getting any user input, just displaying some
data received by some hardware interface (serial ports, network or such).
It's got
On Tuesday 23 October 2012 20:59:27 Sieghard wrote:
Hallo Patrick,
Du schriebst am Tue, 23 Oct 2012 13:45:33 -0400:
where this might come from and how to get rid of those lock-ups?
What if you set up a timer process to wake up every n minutes?
The on event can do nothing or something
Hallo Patrick,
Du schriebst am Tue, 23 Oct 2012 16:43:32 -0400:
the Linux case. Do timers run in a separate thread under Windows?
I don't know if they run in a separate thread or not. Martin may know
the answer to that.
The question was rather meant as rhetorical, anyway - but as far
Why not to use a IFI client/server pair where client writting to a
server's dataset can be handled by DB events etc ? It also provides
secure communicartion channels, link persisnce (due to SSL) ...
--
Everyone hates slow
Hallo Martin,
Du schriebst am Wed, 24 Oct 2012 09:57:09 +0200:
the Linux case. Do timers run in a separate thread under Windows?
No.
As I expected. Thank you for the information.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von
Possibly Sieghard wants to have its client-side app of service
(daemon) type. It's a special type of win-32 apps - with attention to
error handling, auto restarting if killed/died/zombied etc. Correct ?
If yes then MSEgui should provide a such type of project :)
If yes then MSEgui should provide a such type of project :)
More correct - a project template with an interface class declaring
methods which should be implemented to have the daemon behavior.
--
Everyone hates
Smth like LazDaemon: http://wiki.freepascal.org/Daemons_and_Services
or Lazarus's TDaemon+TDaemonMaper :
Hallo Martin,
Du schriebst am Wed, 24 Oct 2012 09:55:17 +0200:
sending alarm signals (which did away with a similar issue under Linux
some time ago, and still does).
IIRC there was a problem on Linux because of lost timer events. If the
problem still exists it is time now to fix it right
Hallo Ivanko,
Du schriebst am Thu, 25 Oct 2012 01:57:45 +0500:
Possibly Sieghard wants to have its client-side app of service
(daemon) type. It's a special type of win-32 apps - with attention to
Yes, that might be a possible solution - although I'm still quite reluctant
to delve into these
Hallo Ivanko,
Du schriebst am Thu, 25 Oct 2012 00:27:46 +0500:
Why not to use a IFI client/server pair where client writting to a
Interesting idea. There's just the tiny problem that one of the
participants cannot speak Pascal - it only speaks IEC(6)1131, the
programming language for PLCs.
--
On Thursday 25 October 2012 01:10:41 Sieghard wrote:
Hallo Ivanko,
Du schriebst am Thu, 25 Oct 2012 01:57:45 +0500:
Possibly Sieghard wants to have its client-side app of service
(daemon) type. It's a special type of win-32 apps - with attention to
Yes, that might be a possible solution
Hello Martin,
I would like (or rather, am obliged) to create an application that can
run for a long time without getting any user input, just displaying some
data received by some hardware interface (serial ports, network or such).
It's got to be running on Windows, meaning I cannot use my Linux
On 10/23/2012 11:57 AM, Sieghard wrote:
Hello Martin,
I would like (or rather, am obliged) to create an application that can
run for a long time without getting any user input, just displaying some
data received by some hardware interface (serial ports, network or such).
It's got to be
Hallo Ivanko,
Du schriebst am Tue, 23 Oct 2012 22:35:37 +0500:
On-demand IPC ? Options:
IPC is _not_ the problem, that works. The problem are the lock-ups, which
seem to stem from the interactive nature of the program. Didn't Windows
(beginning with XP) use to swap out programs it regards as
Yes, I was thinking of something like that also. I just didn't implement it
yet because, in a similar case with a Linux program, this approach didn't
work at all. It's to be expected that a simple timer might not be
sufficient here, because this runs in the same context as all the rest of
30 matches
Mail list logo
