The fpc documentation of classes is very interesting with regards to
messages and properties and handlers. As I recall from tcl/tk, similar
messaging is available using the "send" command. But I believe tcl/tk
uses (used) the X11 messaging system for this capability. Does fpc use
the same mechanism ??

The reason I'm asking is, a generic IPC message queue handling
mechanism for fpc classes would be extremely powerful. Basically,
process control could be implemented using fpc classes.

On 2005-12-08, RickE <eng@pinenet.com> wrote:
> The fpc documentation of classes is very interesting with regards to
> messages and properties and handlers. As I recall from tcl/tk, similar
> messaging is available using the "send" command. But I believe tcl/tk
> uses (used) the X11 messaging system for this capability. Does fpc use
> the same mechanism ??

No. There is no messaging system involved. It is all method variable IOW
indirect calls. There is some support a messaging system (that evolved from
Delphi, thus windwos), but it is currently hardly used (only on Windows for
certain lowest level windows interfacing, not on FPC library level)

All this is also not threadsafe. Additional locking needs to be provided.
Spartan, but fast.

> The reason I'm asking is, a generic IPC message queue handling
> mechanism for fpc classes would be extremely powerful. Basically,
> process control could be implemented using fpc classes.

I don't understand really what you want here.

Again, I am not an expert. So if my questions are unclear it is because
I am reaching.

I have been reading a lot, including Delphi and a surprisingly good
book; "Kylix Power Solutions." My interest is instrumentation controls
and automation. Event driven GUI programming might be generalized to
event driven device programming.

On 2005-12-08, RickE <eng@pinenet.com> wrote:
> Again, I am not an expert. So if my questions are unclear it is because
> I am reaching.
>
> I have been reading a lot, including Delphi and a surprisingly good
> book; "Kylix Power Solutions." My interest is instrumentation controls
> and automation. Event driven GUI programming might be generalized to
> event driven device programming.

True, but event driven doesn't require a messaging subsystem.

I don't wish to bite the hand that feeds me ( I really like fpc ). But
please refer to "Special Edition: Using Delphi2," by Que pub. page 403.

"Windows is a message-driven system. Each application has a message
queue."

I am trying to exploit such a capability for other than GUI events.
Sincere thanks for fpc.

On 2005-12-08, RickE <eng@pinenet.com> wrote:
> I don't wish to bite the hand that feeds me ( I really like fpc ).

Don't worry, I just didn't understand.

> But
> please refer to "Special Edition: Using Delphi2," by Que pub. page 403.

Don't have every Delphi book in existance.

> "Windows is a message-driven system. Each application has a message
> queue."

True, BUT:
- FPC is more than Windows. Using windows messaging will make it windows
	only.
- using it heavily will kill performance.

> I am trying to exploit such a capability for other than GUI events.

This is possible. Just define events above WM_USER, and send messages from
parts of the program to the other. The base principle is that to receive a
message you have to have a form handle. This form handle does not have to be
visual.  Good examples to learn this kind of stuff is reviewing the console
examples of the socket suites (ICS, Indy). I recommend ICS for this purpose,
it is a bit more transparant.

You have the enthusiasm and ambition of a young man. That is wonderful.
I have a different perspective.

I think I'll proceed in my deprecated ways. I'll stick with fpc
Objects, not Classes. I'll try put together a combined IPC test.
Messages will be used to notify of an event. Shared Memory might be
used to pass pointers. And perhaps Semaphores can manage activity.

Perhaps the framebuffer graphics routines can be cleaned up so that
separate processes (not threads) can be plotted.

This link might lead somewhere;

http://groups.google.com/group/comp.unix.programmer/browse_thread/thread/3dcf1534562c9392/dc9fb8b945a57f1e#dc9fb8b945a57f1e

I'm very slow. But I know where I'm going.

On 2005-12-11, RickE <eng@pinenet.com> wrote:
> This link might lead somewhere;
>
> http://groups.google.com/group/comp.unix.programmer/browse_thread/
thread/3dcf1534562c9392/dc9fb8b945a57f1e#dc9fb8b945a57f1e
>
> I'm very slow. But I know where I'm going.

Those functions (getpid/pgrp etc) are available in units baseunix/unix.
See the example in demo/freebsd/sysmousetest as an example how to catch a signal. (in this case SIGUSR2,
a user programmable signal that under FreeBSD is used for the textmode mouse driver)

Note that signals are a bit slow, and overuse will cause horrible performance. 

Yes, I know. Can you imagine trying to reach such an overall
organization in C ??

Most programming today is what used to be called "Data Processing."

BTW, I got some good books on Xlib. The X server does indeed use
Message Queues, though probably not kernel IPC queues. The "send"
command tcl/tk uses is the cut and paste procedure, not a message. Lots
of tricks to borrow.

The TCollection object is very appealing. But, again, I'm very slow. My
goal is to help make tomorrow better than yesterday. I'm looking
forward to trying the new release. Thanks.

Putting together a little code here.

In FreePascal, it seems quite easy to build qualified address names for
processes. Very similar to a numeric internet address and its string
counterpart, we can use both a numeric and string process address. ie;

<tSessionName.tProcessGroupName.tProcessName>  and  <sid.pgid.pid> are
the same.

Or, perhaps the address could be formed as

<tProcessName.tProcessGroupName.tSessionName>  ??