On Tue, 03 Nov 2015 12:03:38 +0100, Michael Schnell
wrote:
>For the record:
>
>I verified that with the gtk2 (Linux) Widget type, "PostMessage()" uses
>a different Event Queue ("TGTKMessageQueue") than "TThread.Queue()" and
>TThread.Synchronize()".
Moved discussion to new thread named:
"Using
I answered in a new thread "Thread-to-Mainthread signalizing", as we are
getting too far off-topic.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Michael Schnell wrote:
For the record:
I verified that with the gtk2 (Linux) Widget type, "PostMessage()" uses
a different Event Queue ("TGTKMessageQueue") than "TThread.Queue()" and
TThread.Synchronize()".
So for this, calling "CheckSynchronize() will not help. You need to use
the appropri
For the record:
I verified that with the gtk2 (Linux) Widget type, "PostMessage()" uses
a different Event Queue ("TGTKMessageQueue") than "TThread.Queue()" and
TThread.Synchronize()".
So for this, calling "CheckSynchronize() will not help. You need to use
the appropriate GUI-based Widget typ
On 11/02/2015 08:32 PM, Bo Berglund wrote:
I had already looked at Synapse, but it is blocking.
I took a look at (an old version of the) Indy source code: it uses
"Synchronize" to simulate non-blocking behavior.
So if you use a thread to allow for non-blocking Indy functionality, you
need to
On 11/02/2015 08:32 PM, Bo Berglund wrote:
I had already looked at Synapse, but it is blocking.
IMHO this is exactly what makes it "clearer". You can run it in a thread
and do the communication with the main thread in any way you like.
A non-blocking thingy will either internally use multip
On Tue, 3 Nov 2015 02:40:11 +0100, José Mejuto
wrote:
>El 02/11/2015 a las 20:32, Bo Berglund escribió:
>
>>> IMHO using lnet or Synapse would be a lot "clearer" than using the
>>> overly complex Indy Library.
>> I had already looked at Synapse, but it is blocking.
>> I did not know about lnet (o
On Mon, 02 Nov 2015 20:32:40 +0100, Bo Berglund
wrote:
>On Mon, 02 Nov 2015 10:24:54 +0100, Michael Schnell
> wrote:
>
>>On 10/31/2015 07:28 PM, Mark Morgan Lloyd wrote:
>>> Alternatively look at the lnet code that comes with FPC, ...
>
>I did not know about lnet before but now I have had a look
El 02/11/2015 a las 20:32, Bo Berglund escribió:
IMHO using lnet or Synapse would be a lot "clearer" than using the
overly complex Indy Library.
I had already looked at Synapse, but it is blocking.
I did not know about lnet (or INet as it is shown when one searches)
before but now I have had a
On Mon, 02 Nov 2015 10:24:54 +0100, Michael Schnell
wrote:
>On 10/31/2015 07:28 PM, Mark Morgan Lloyd wrote:
>> Alternatively look at the lnet code that comes with FPC, ...
>
>IMHO using lnet or Synapse would be a lot "clearer" than using the
>overly complex Indy Library.
I had already looked
On 11/02/2015 10:21 AM, Michael Schnell wrote:
or PostMessage (with a Mainthread Object featuring "Procedure
message" )
Maybe I was wrong here this mechanism might use a different mechanism
(which supposedly will not work at all without a GUI).
-Michael
--
__
On 10/31/2015 07:28 PM, Mark Morgan Lloyd wrote:
Alternatively look at the lnet code that comes with FPC, ...
IMHO using lnet or Synapse would be a lot "clearer" than using the
overly complex Indy Library.
-Michael
--
___
Lazarus mailing list
La
On 10/31/2015 06:47 PM, Bo Berglund wrote:
Should I add this back now that CheckSynchronize seems to have cured a
few "shortcomings"?
Only with "CheckSynchronize" your thread can use TThread.Synchronize,
TThread.Queue or PostMessage (with a Mainthread Object featuring
"Procedure message"
On 10/31/2015 01:07 PM, Bo Berglund wrote:
I had hoped that while executing sleep() statements the main thread
would yield to the TCP thread but it seems like it does not...
Sleep() indeed puts the running (main) thread to sleep and allows for
other threads to run in the mean time.
The problem
On 10/31/2015 12:13 AM, Bo Berglund wrote:
Bo's precise problem is that he does not want to restructure his code.
. And I hesitate
to ask more questions here because I feel I am getting flamed for not
getting how it should be done. :(
I never intended to flame you. On the contrary I am fully
Bo Berglund wrote:
thank you very much for your excellent descriptions and tips!
I did not know of CheckSynchronize before but I immediately threw in a
number of such calls in the existing code that throws the SIGSEGV
exception and Lo-and-behold! I am now getting the event output I was
expectin
On Sat, 31 Oct 2015 13:28:40 +, Mark Morgan Lloyd
wrote:
>What I'd do is change the main code to be a loop to output
>your test messages without starting a background thread, and to loop for
>say a minute with Sleep() and CheckSynchronize(): if this crashes then
>you've got bigger problems
Bo Berglund wrote:
On Sat, 31 Oct 2015 10:22:08 +, Mark Morgan Lloyd
wrote:
Bo Berglund wrote:
What does the main thread do? If you can contrive to write that as a
loop, then as you've already been told you can call CheckSynchronize()
which hands control to whatever's been queued by th
On Sat, 31 Oct 2015 10:22:08 +, Mark Morgan Lloyd
wrote:
>Bo Berglund wrote:
>What does the main thread do? If you can contrive to write that as a
>loop, then as you've already been told you can call CheckSynchronize()
>which hands control to whatever's been queued by threads using
>Synch
Bo Berglund wrote:
My most recent investigation is about how to create a TCPIP socket
object that has event driven receive functions. I have no use for the
problem unit in that quest so this thread is not really valid for
those problems. Last I tested Indy10 with the help of Remy Lebeau but
in t
Am 31.10.2015 00:14 schrieb "Bo Berglund" :
> The biggest hurdle I have now is getting a TCP socket component
> working so I can plug it into the problem unit. I have tried several
> different approaches but am unfortunately not done yet. And I hesitate
> to ask more questions here because I feel I
On Fri, 23 Oct 2015 17:13:55 +0200, Sven Barth
wrote:
>Am 23.10.2015 14:29 schrieb "Bo Berglund" :
>> So I am a bit surprised that just using this unit would make the FPC
>> command program not work...
>
>It's not exactly FPC's fault, but more that one must not take one's
>environment for granted
On Fri, 23 Oct 2015 14:15:59 +0200, Michael Schnell
wrote:
>On 10/23/2015 02:12 PM, Sven Barth wrote:
>>
>> I somehow have the feeling that you and Graeme as well don't
>> understand what Bo's precise problem is. ...
>>
>> ... Yes, Bo should restructure his code, but he does not /need/ to do
>>
Am 23.10.2015 14:29 schrieb "Bo Berglund" :
> So I am a bit surprised that just using this unit would make the FPC
> command program not work...
It's not exactly FPC's fault, but more that one must not take one's
environment for granted. E.g. on Windows you basically always have a GUI
which is pro
On Friday 23 October 2015 15:49:25 Graeme Geldenhuys wrote:
> On 2015-10-23 13:07, Marcos Douglas wrote:
> > LOL!
> > One or two times on year I see this image do you talked hehehe
> >
> :-)
>
> Two additional points:
> - Martin's example is not nearly as big or complex as the example I
>showe
On Fri, Oct 23, 2015 at 11:49 AM, Graeme Geldenhuys
wrote:
> [...]
> - The project I worked on was started with Delphi 2 if I recall, and
>progressed though the various Delphi's as they got released. I also
>vaguely remember up until Delphi 6 or 7 you could only have one
>DataModule p
On 2015-10-23 13:12, Sven Barth wrote:
> I somehow have the feeling that you and Graeme as well don't understand
> what Bo's precise problem is.
Indeed - not at the start when Bo opened this thread. But as he
explained later what he wanted, I understood.
Regards,
- Graeme -
--
fpGUI Toolkit -
On 2015-10-23 13:07, Marcos Douglas wrote:
>
> LOL!
> One or two times on year I see this image do you talked hehehe
:-)
Two additional points:
- Martin's example is not nearly as big or complex as the example I
showed in the past.
- The project I worked on was started with Delphi 2 if I re
On Fri, 23 Oct 2015 08:01:20 +0200, Sven Barth
wrote:
>This is especially true if the code related to the GUI components isn't
>even used (yes, I knew such stuffed units as well -.- ).
I just looked in our CVS server for the history of the most
problematic unit. It was added to version control b
Am 23.10.2015 09:45 schrieb "Michael Schnell" :
>> In this case I do not want to re-invent all of the communications and
data parsing code...
>
> You obviously are out of luck (As already discussed, additionally to the
"visual-component" issues, the Event-queue issue will hit you as well. To
solve
On Fri, Oct 23, 2015 at 9:18 AM, Martin Schreiber wrote:
> Separating GUI and business logic is perfectly possible with RAD. Implement
> the business logic by components, properties and code in datamodules and
> additional units, for the GUI use forms witout or only GUI specific code.
Possible, y
On Fri, Oct 23, 2015 at 9:18 AM, Martin Schreiber wrote:
> [...]
> And before Graeme shows his image with the thousand components in a single
> datamodule here how it could look:
> http://mseide-msegui.sourceforge.net/pics/mseguirad.png
> ;-)
LOL!
One or two times on year I see this image do you
On 10/23/2015 01:18 PM, Martin Schreiber wrote:
In my understanding "RAD" is visually placing components in forms and
datamodules, ...
OK, "RAD" is just a name for whatever.
I don't disagree to calling "not using a separate set of units for
business logic and GUI stuff" with another name. But
On Friday 23 October 2015 09:44:58 Michael Schnell wrote:
> On 10/22/2015 11:13 PM, Bo Berglund wrote:
> > So it had helpers to show the recorded data in listviews and other
> > such GUI related stuff
>
> This is called "RAD" ("Rapid Application Development") and a big
> marketing argument of all
On 10/22/2015 11:13 PM, Bo Berglund wrote:
So it had helpers to show the recorded data in listviews and other
such GUI related stuff
This is called "RAD" ("Rapid Application Development") and a big
marketing argument of all companies who sold Delphi.
But it is very bad for portability. In
Am 23.10.2015 07:39 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
> Then refactor / clean-up the code to remove such "gui" dependencies if
> you want a true console application. Windows always has a GUI - so there
> you can get away with including GUI units, widgets or clipboard in
On Thu, 22 Oct 2015 17:32:30 +0100, Graeme Geldenhuys
wrote:
>That still doesn't explain why the original Delphi code required a
>TListView instance. TListView is purely a GUI component - so I'm very
>puzzled.
>
>If you needed a list of objects, and maybe an associated text string or
>something,
On 2015-10-22 15:33, Bo Berglund wrote:
> But when programming it I need to use existing classes from Delphi in
> which I will use a subset of the functionality only. No functions
> dealing with user interface will be used at all, but in the same class
> is embedded the bulk of the communications p
Bo Berglund wrote:
My development machine is now also the target, a Raspberry Pi2, with
FPC and Lazarus installed but it is headless. So my interface is PuTTY
for command line work in Raspbian Jessie and for GUI (= Lazarus) I use
tightvncserver on the Pi and TightVNCclient on Windows 7.
It work
On 10/22/2015 04:33 PM, Bo Berglund wrote:
Could be thought of as a service. But when programming it I need to
use existing classes from Delphi
Poor chap.
I have been investigating exactly this for years.
I posted the results in many answers to your forum messages.
-Michael
--
__
On Wed, 21 Oct 2015 14:38:54 +0200, Michael Schnell
wrote:
>On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
>> And even if you use the Win32 widgetset, you can still have a command
>> line program.
>Of course any executable can be started from the command line. But I
>don't suppose that this is
Am 21.10.2015 14:39 schrieb "Michael Schnell" :
>
> On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
>>
>> And even if you use the Win32 widgetset, you can still have a command
line program.
>
> Of course any executable can be started from the command line. But I
don't suppose that this is what Bo m
On 2015-10-21 12:42, Bo Berglund wrote:
> With LCL added it does work!
I'm with Michael Schnell on this one - that is a terrible idea. So too
is the LCL-NoGUI hack.
I would instead implement a Mock TListView class that implements the
most basic interface your unit requires, but doesn't really do
On 10/21/2015 02:37 PM, Mark Morgan Lloyd wrote:
Zeljko wrote:
On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
Under Linux/BSD every program is a command line program.
It is, but with exception that qtlcl and gtk2lcl cannot run on
headless linux machine. I'm giving this objection since one
On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
And even if you use the Win32 widgetset, you can still have a command
line program.
Of course any executable can be started from the command line. But I
don't suppose that this is what Bo meant when he said he wants do do a
"command line program".
Zeljko wrote:
On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
Under Linux/BSD every program is a command line program.
It is, but with exception that qtlcl and gtk2lcl cannot run on headless
linux machine. I'm giving this objection since one can create cmd line
program on windows and then e
On 10/21/2015 02:18 PM, Mattias Gaertner wrote:
Under Linux/BSD every program is a command line program.
It is, but with exception that qtlcl and gtk2lcl cannot run on headless
linux machine. I'm giving this objection since one can create cmd line
program on windows and then expect that it
On Wed, 21 Oct 2015 13:58:38 +0200
Michael Schnell wrote:
>[...].
> > With LCL added it does work!
> But now it is not a command line program any more.
That is wrong in so many ways.
As long as you don't add the "interfaces" unit, no external GUI lib is
used.
And even if you add the interfaces
On 10/21/2015 01:42 PM, Bo Berglund wrote:
I just want the unit to compile, but I will not use these methods in
the command line application...
A very bad idea, indeed. In many cases just using a unit will
automatically call procedures in certain (here: GUI) libraries.
Moreover using such a uni
On Wed, 21 Oct 2015 10:08:40 +0200, Michael Schnell
wrote:
>On 10/20/2015 07:06 PM, Bo Berglund wrote:
>> My program is a pretty simple command line program
>Description of TListview: " Use TListView to manage and display a list
>of items in a form"
>
>As a command line application does not have
On 10/20/2015 07:06 PM, Bo Berglund wrote:
My program is a pretty simple command line program
Description of TListview: " Use TListView to manage and display a list
of items in a form"
As a command line application does not have a form, this can't work.
-Michael
--
__
On Tue, 20 Oct 2015, Bo Berglund wrote:
On Tue, 20 Oct 2015 19:16:13 +0200, Mattias Gaertner
wrote:
comctrls is in package LCL.
Check "Project / Project Inspector / Required Packages" has package
"LCL".
Thanks! Worked OK.
Follow-up:
Is there a package with a TCP client socket as well?
I
On Tue, 20 Oct 2015 19:16:13 +0200, Mattias Gaertner
wrote:
>comctrls is in package LCL.
>Check "Project / Project Inspector / Required Packages" has package
>"LCL".
>
Thanks! Worked OK.
Follow-up:
Is there a package with a TCP client socket as well?
I need to replace a serial comm component wit
On Tue, 20 Oct 2015 19:06:44 +0200
Bo Berglund wrote:
> Note: Posted this by accident on the FPC list
> --
> I want to know why comctrls is not found by Lazarus and hence the
> definitions of a lot of objects in my Delphi code ported to FPC
> ge
Note: Posted this by accident on the FPC list
--
I want to know why comctrls is not found by Lazarus and hence the
definitions of a lot of objects in my Delphi code ported to FPC
generate errors?
I have googled extensively on "lazarus TListView" "
55 matches
Mail list logo
