I am moving a discussion that is being conducted in a thread named: "Lazarus implementation of TListview etc?" to this new thread since the topic has shifted away from the original....

This topic has to do with using communications components which fire off "OnReceive" events when data arrives (on a serial line or a TCP network connection) inside a console application.

I need to modify an existing Delphi class unit such that a serial port component is replaced with a TCP client component. And it must work in a console (non-GUI) application because it must run unattended via cron.
Since the original serial component used a receive event for incoming data the rather big class is geared towards handling incoming data this way. So I need to find a TCP component that is non-blocking and fires off OnReceive events when data arrives. Otherwise I will need to do major rework in the class.

Long story winding through Synapse, ssockets and Indy10 finally reached lNet today and initial tests make me think it is going to work.

However there has been a number of issues raised as to the suitability of threading in a console application in Lazarus/FPC so rather than having this discussed in a thread seemingly about TListView I now create this new thread.
In the old one I asked about creating my own events using a TThread object doing blocking reads on a TIdTCPClient object and making the connection between the two threads via CheckSynchronize() and Synchronize() calls respectively.

Others have pointed out that events will not work in a console application because there is no message loop built in.

But I have now tested the lNet TCP component created in code inside a console application and it seems to work, at least inside the Lazarus IDE under the debugger.
But this is of course in a test appliocation built as a descendant to TCustomApplication and not yet using the Delphi class I need to transform....

There are different kinds of message loops.
For multithreading Synchronize and Thread.Queue you just need a loop in the main thread that calls CheckSynchronize.

A LCL program calls Application.Run, which creates such a loop, processing AsyncCalls, Idle calls and CheckSynchronize. The NoGUI widgetset does that too.
The other widgetsets additionally support PostMessage and SendMessage, implementing a more complex message queue. Post/SendMessage require Handles, which the NoGUI widgetset does not have.

lnet does not use Post/SendMessage, so it works even with the NoGUI widgetset.

You can easily implement your own loop and simply call Application.ProcessMessages.

Mattias

Thanks,
you mean that Application.Processmessages is available in this console program? I did not know that. And it seems like TCustomApplication does not automatically include it either. I get a error "identifier not found: Application" when I try...

But now I have a basic Lazarus IDE usage question: When testing the lnet functions I copied the files from the lNet download (the complete lib directory) to my pi home directory into an lnet dir and set the project path to include this dir.

After successfully testing lnet I wanted to actually install it into Lazarus so I extracted the complete zipfile (according to install directions here:
http://wiki.lazarus.freepascal.org/lNet#Installation) into my lazarus install dir at /home/pi/development/lazarus/components. Then I went into Lazarus menu Package/Open Package file as instructed on the webpage above and installed the lnet package.

When it was all done and Lazarus restarted I removed the project path to the sources I used before and compiled my test project and it worked OK.
Then, just to make sure, I right-clicked on the TLTcp type name and selected "Find declaration" and unit lNet opened in the IDE.

But this unit is NOT where I expected it to be! Instead of in the Lazarus component directory it shows to be located in: /usr/local/fpc/source/utils/fppkg/lnet

How did this happen? Seems like there is a copy of lnet in this location so which is Lazarus using? And how did it get there in the first place?

I am running FPC 3.1.1 (svn trunk a couple of week back) and Lazarus 1.5 svn 50059M (don't know what M means)

It is available when you use the NoGUI widgetset.
If you don't use it, you have to call CheckSynchronize yourself.

AFAIK lnet has Lazarus packages. Use them instead of adding paths manually.

... and (hopefully) added the lnet lpk in the project inspector.

You have two lnet. One installed by fppkg and one manually. Open the right lnet .lpk once (Package / Open Package File).

How did this happen? Seems like there is a copy of lnet in this location so which is Lazarus using? And how did it get there in the first place?

You used fppkg.

I am running FPC 3.1.1 (svn trunk a couple of week back) and Lazarus 1.5 svn 50059M (don't know what M means)

The M means you have local modifications.

Mattias

Mattias Gaertner wrote

> you mean that Application.Processmessages is available in this console > program? It is available when you use the NoGUI widgetset.

How do you change which "widgetset" is used? (I really do not know what you mean by widgetset, but I assume it is some kind of application framework).

Did not know I had to do that, so no that was not done before compile...
Now done.

You have two lnet. One installed by fppkg and one manually. Open the right lnet .lpk once (Package / Open Package File).

So that means that lnet is actually part of fpc then? In that case I have been doing a superfluous thing when installing lnet in the first place. How can I get rid of the one in my local Lazarus copy?

You used fppkg.

What is fppkg? I do not know about it. Google says it is the FPC packet manager and thet one has to run it, which I don't think I have.

The M means you have local modifications.

I guess it's because I installed lnet and had to rebuild Lazarus??

Bo Berglund wrote

It is available when you use the NoGUI widgetset. How do you change which "widgetset" is used?

In the IDE the Macro to be set is called "LCLWidgetType" (not "widgetset").

-Michael

It's the layer of libraries in between the X11 server (or the Windows API etc.) and the LCL. The widget set implements the standard GUI elements (forms, buttons and so on) while the LCL takes these and provides a standardised set of properties and events that apps can use.

Since you're working on a console app this probably isn't something you need to bother about, but it's usually defined somewhere around Project -> Options -> Paths. However this has tended to vary a bit as the IDE has gained things like build modes.

When building the IDE you'd normally use make bigide or similar which would use the platform defaults, but depending on what libraries etc. were available you could also use e.g. make LCL_PLATFORM=qt bigide

Mark Morgan Lloyd wrote

Bo Berglund wrote: > How do you change which "widgetset" is used? When building the IDE ...

You don't need to rebuild the IDE to change the WidgetType (AKA "Interface") used in a project. It is a project option.

In older Lazarus IDE versions you could select the WidgetType to be used when compiling the project in the top level of the Project options.

In the newer versions of the IDE this selection is more hidden: "Project options" -> "Additions and Overrides" -> "Set LCLWidgetType".

-Michael

Michael Schnell wrote

"Project options" -> "Additions and Overrides" -> "Set LCLWidgetType".

Sorry:

"Project options" -> "Compiler Options" -> "Additions and Overrides" -> "Set LCLWidgetType".

I don't know what the two checkboxes mean that appear in front of

IDE-Macro: LCLWidgetType:=nogui

-Michael

Hi,

This question / discussion is also very interesting to me (warning possible dumb questions ahead).

I am still very vague on the widget type/set in my gnu/linux education. I'm kub14.04, the ide then uses gtk2, all automatic.

But my questions are:

Why would I want to use qt, gtk3, etc? Yes, of course for different platforms but which platforms (Fedora? Debian? ?? ).

Does this mean then that what I have developed in gtk2 will ==NOT== run properly in some gnu-L flavours? Which ones? How do I tell?

I guess setting up VMs for my targets is a good solution to find out if there is a problem but I can't always tell which widgetset is right for which flavour...?

I have googled this before but have found nothing that has enlightened me.

Thanks for any info.

Julius

JuuS wrote

Why would I want to use qt, gtk3, etc? Yes, of course for different platforms but which platforms (Fedora? Debian? ?? ).

Lazarus takes a lot of care on portability. So a "normal" user project should run on any supported platform/OS/CPU architecture.

Even such a windowish legacy methods as using PostMessage for Thread to Mainthread signaling are implemented platform independent.

-Michael

If that's Kububtu, I'd expect it to be using KDE which implies you've already got Qt. Assuming that you have- or can add- libqt4pas-dev then you can build the Lazarus IDE etc. for Qt.

But my questions are: Why would I want to use qt, gtk3, etc? Yes, of course for different platforms but which platforms (Fedora? Debian? ?? ).

Depends massively on the version of whichever distro you've selected, since these will typically bundle different versions of Gnome and it's this that drives GTK forwards. I'm sure you've seen Torvalds' rants on the issue.

It also depends on the version of Lazarus you're using since of necessity this tracks GTK and Qt, and to a much lesser extent on the version of FPC for the same reason.

In general, Debian "Lenny" is OK for GTK and GTK2. Debian "Squeeze" and "Wheezy" are OK for GTK2 and Qt. My experience with Lazarus "Jessie" is that Qt is somewhat more reliable than GTK, although I'm sure I'll take flak for saying so.

Can't remember where I've got to with "Stretch". Recent versions of Lazarus have started making demands of Qt that are no longer satisfied by the one with "Squeeze".

Does this mean then that what I have developed in gtk2 will ==NOT== run properly in some gnu-L flavours? Which ones? How do I tell?

Yes. Pass. Badly.

The first problem to solve is pairing up which version of FPC works best with a given version of Lazarus. After experimentation, I've got

/usr/local/bin/lazarus-0.9.24+2.2.4
/usr/local/bin/lazarus-0.9.26+2.2.4
/usr/local/bin/lazarus-0.9.28+2.4.0
/usr/local/bin/lazarus-0.9.30+2.4.4
/usr/local/bin/lazarus-1.0.0+2.4.4
/usr/local/bin/lazarus-1.0.0+2.6.0
/usr/local/bin/lazarus-1.0.8+2.6.2
/usr/local/bin/lazarus-1.0.14+2.6.4
/usr/local/bin/lazarus-1.2.6+2.6.4
/usr/local/bin/lazarus-1.4.2+3.0.0
/usr/local/bin/lazarus-gtk1-compatible

The last of those is actually 0.9.24.1 with FPC 2.2.4, which is about as old as is viable. I can't say without significant digging in my build scripts which of those are also good for Qt. I really can't say which are good for different versions of Windows (except that if you really do have to build for NT you'll need something like 0.9.26.2 + 2.2.4) or for OS X. Anybody into SPARC Solaris should find 1.4.2 + 3.0.0 OK.

The best thing to do, in my opinion, is to build as many variants of your binary as possible for a given platform, and then find out what doesn't work. To try to keep that doable I've got a script set up which points each of the combinations listed above at its own configuration file, so that I don't find myself chasing shadows because the underlying FPC version is suddenly wrong.

You can choose in which of your build modes the flag is enabled.

Mattias

Ah, now I see that a lot above there is a caption stating two build modes.

Great !

Thanks,
-Michael

Wow, thank you for the information! Exactly the type of explanation I needed to help clearup my confused mind re: widget sets.

Uhhh...no (but I immediately googled and read a bit...)

Ouch.

But this is what, ultimately, fpGUI will address I believe? Wiki page says it is still alpha but I anxiously await the opportunity to use it natively (I work in 1.4.4, I SVN only occasionally in special circumstances)

Excellent research, I see you've tracked this issue for a long time.

At this time it seems best for me to get the widest sample of VMs built for testing while I do not want to muddy my work machine with multiple builds and libraries and installs / upgrades gone wrong. I just don't need that.

Thanks Mark, your explanation has helped me toward devising a plan / system of my own regarding this.

Save us fpGUI...

JuuS wrote

Excellent research, I see you've tracked this issue for a long time.

Not so much that, but my colleagues and I have a fairly wide range of OS versions etc. and there are one or two programs that I really do want to run on just about anything (e.g. one that handles cut-and-paste over the LAN).

I've also written a very small amount of stuff that potentially I want to be able to send to anybody with confidence that any version of Lazarus will be able to read the forms and any version of FPC will be able to compile it. In most cases that's doable, provided that one's careful about exactly what gets put into svn.

In addition to form (.lfm etc.) compatibility, there's a couple of "gotchas" that's deserve comment. The first is that TNotebook (and related components) got a major workover somewhere around Lazarus 1.0, in general problems can be sorted by RTTI etc. It's worth noting as a related issue that the introduction of frames required a compiler facility that for a long time was only in a development version: if you put frames in a notebook, you'll have problems supporting really old versions.

The second is that SynEdit got some internal changes, and if you want to do anything that involves reaching below the surface I think you have to use compile-time conditionals rather than RTTI. That's one reason that I did the work to find out what compiler versions worked with which LCLs, expect problems around 0.9.28.

It is also possible to use fpGUI directly without LCL layer. Same applies to MSEgui if identical look and feel on all supported platforms is important.

Martin

Martin Schreiber wrote

On Wednesday 04 November 2015 14:31:34 JuuS wrote: > > > > But this is what, ultimately, fpGUI will address I believe? Wiki page

Interestingly it is now 16:52 local time, and I haven't seen that message from Juus in my Inbox. Umm...

Are there some hick-ups with the mailing list today where message are out of sync?

Regards,
- Graeme -

No, it's HMG filtering your email. Who've you upset?

Mark Morgan Lloyd wrote

No, it's HMG filtering your email. Who've you upset?

:-) Who knows.

Looking at the mailing list archive, I haven't received any of JuuS's messages on this thread. At least messages from others have come through.

And no, I don't have spam filtering enabled on my mail server or email client.

Regards,
- Graeme -

Ahhhh. Thank you for the insight! Yes, I can now compile qt as well as gtk2.

So simple!!...when you know what is needed...

Just FYI for others that may be in my position:

This insight (using a qt version) just solved the problem I was having with a later install version of kub 14.04 and kub 15.04 and 15.10 where a simple progress bar from the comp. palette showed fine in my development computer (earlier install v. of 14.04) but would NOT show in those other two versions. Ouch.

Thanks again, you just solved a headache for me (but one needs to install the libqt4pas5 library on the destination machines, even so problem solved).

Having to have that library is unfortunate, but is a fundamental requirement since Qt exposes a C++ API which is not directly usable by FPC. If you start looking too closely at that point, you have to question the wisdom of using non-mainstream tools... I really don't want to go there.

In practice, it's also worth installing database -dev packages e.g. libpq-dev on user-level machines, since it is these that typically set up a fixed-name symlink that avoids an app having to search for various possibilities. So on one of the older machines around here I've got

/usr/lib/libpq.a
/usr/lib/libpq.so -> libpq.so.5.1
/usr/lib/libpq.so.5 -> libpq.so.5.1
/usr/lib/libpq.so.5.1

while on a newer one:

/usr/lib/libpq.a
/usr/lib/libpq.so -> libpq.so.5.4
/usr/lib/libpq.so.5 -> libpq.so.5.4
/usr/lib/libpq.so.5.4

That's a distro problem, not an FPC or Lazarus one.

Let's make L mainstream then...it certainly deserves to be IMO.

I thought that any C++ API is not directly usable outside the compiler that build it. Even an older version of the same compiler might not be able to use it or a newer one for that matter. Am I wrong?