Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
On 10/23/2015 04:15 PM, Martin Frb wrote: On 23/10/2015 19:34, Dmitry Boyarintsev wrote: That's why I'm asking the participant to adjust his email client, rather than doing anything on my end. Well my email client does sort them correct. +1 Yet I find it (personal opinion) annoying to have a SPAM keyword in those mails. +1 -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
On 23/10/2015 19:34, Dmitry Boyarintsev wrote: That's why I'm asking the participant to adjust his email client, rather than doing anything on my end. Well my email client does sort them correct. Yet I find it (personal opinion) annoying to have a SPAM keyword in those mails. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
On Fri, Oct 23, 2015 at 9:38 AM, Henry Vermaak wrote: > > If your mail client is threading based on the subject, it's broken or > misconfigured. My client has no issues with the subject changing. > I totally agree that gmail.com is totally broken and misconfigured. (no irony, but sorrow) That's why I'm asking the participant to adjust his email client, rather than doing anything on my end. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
On Fri, 23 Oct 2015 17:01:32 +0200 Sven Barth wrote: >[...] > Those and the code they link to would remain. It will depend on the > specific initialization whether it can do any harm (especially with the > widgetset not initialized) if left in... The most harmful are probably: - forms.pp installs an exception handler - lazutf8 under Windows tweaks some WideString manager functions optimized for UTF8 and sets DefaultSystemCodePage to CP_UTF8. The other sections create objects and register classes, which don't do anything on their own. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 provided by the core OS (yes, there are things like headless servers or the new Windows 10 for IoT). On Linux systems on the other hand the GUI is entirely optional and provided by the distribution (I simplified here). In addition there can be multiple GUI toolkits (GTK and Qt to name two). If you now have for some reason a dependency on a Qt library but try to run it on a system without Qt your applications won't work. This part is solved by not using the Interfaces unit which is required for LCL GUI applications and which pulls in the widgetset (WinAPI, GTK, Qt, etc.) dependency (you are already doing this). However there /might/ be unit initialization sections in the LCL units that rely on the fact that the widgetset had been initialized (because the Interfaces unit is usually one of the first used in the program file) and thus will result in a crash during the initialization of the unit. Again this does not happen with Delphi's VCL as there is no such widgetset abstraction like the LCL has, because it directly accesses the WinAPI (which is always there). So I at least suggest you to split the GUI and non-GUI parts of the unit to be on the really safe side. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
Am 23.10.2015 14:20 schrieb "Michael Schnell" : > > On 10/23/2015 02:12 PM, Sven Barth wrote: >> >> He simple needs to get the unit to compile (which he did by adding the LCL dependency) and stay clear from using any of the code that might use GUI. In that case there will be no dependency on a specific GUI, because the Interfaces unit is missing and the compiler might even smartlink away the GUI-related code that isn't used anyway. > > What about code in the "initialization" section of the multiple units that will get pulled even if using a single GUI related unit from the LCL ? > Those and the code they link to would remain. It will depend on the specific initialization whether it can do any harm (especially with the widgetset not initialized) if left in... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 >showed in the past. You don't know what is in the other datamodules. ;-) Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
Henry Vermaak wrote: On Fri, Oct 23, 2015 at 08:19:53AM -0400, Dmitry Boyarintsev wrote: Hello Michael It seems like your email client is adding "*SPAM*" to the subject of emails coming from lazarus mailing list. Could you please add Lazarus@lists.lazarus.freepascal.org to the white list? Otherwise getting an email with *SPAM* prefix in the subject ruins the whole thread. If your mail client is threading based on the subject, it's broken or misconfigured. My client has no issues with the subject changing. Some clients take the subject into account, because in the mists of time messages which originated at or passed through certain (MS?) systems had their headers mangled. I agree that it would have been appropriate for people to have deleted the SPAM annotation. But far better would have been avoiding the exhortation "Win 10 IOT Core (no purchase required)" in the first place, which was guaranteed to trip spam filters :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 per project. With later Delphi versions, Lazarus and >MSEide that is not an issue any more. Maybe Delphi 4 because in version 5 you could have more than one DataModule per project. > The bottom line is, Delphi-style RAD promotes bad habits (this is fact > with the Delphi projects I've seen over the last 20+ years), and we all > know bad habits die hard. I agree. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 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 per project. With later Delphi versions, Lazarus and MSEide that is not an issue any more. The bottom line is, Delphi-style RAD promotes bad habits (this is fact with the Delphi projects I've seen over the last 20+ years), and we all know bad habits die hard. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
On Fri, Oct 23, 2015 at 08:19:53AM -0400, Dmitry Boyarintsev wrote: > Hello Michael > > It seems like your email client is adding "*SPAM*" to the subject of emails > coming from lazarus mailing list. > Could you please add Lazarus@lists.lazarus.freepascal.org to the white list? > > Otherwise getting an email with *SPAM* prefix in the subject ruins the > whole thread. If your mail client is threading based on the subject, it's broken or misconfigured. My client has no issues with the subject changing. Henry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 back in February 2001 and to date there are 99 revisions checked in. It does not show the best OO design one has seen... Another pice of info: About 2-3 years ago I had to make available a Windows DLL to support a university which needed to create its own software for research and it was rellay not possible for them to handle the communications side of it. So I made (in Delphi) a Windows DLL which used this unit and basically also the other units I am now porting to Lazarus/FPC. Inside that DLL are between 22 functions related to the instrumentation handling, but none that refers to the GUI components. But the problem unit is used in any case. This DLL works just fine to control the instrumentation in Windows used in a Windows console program written in Delphi. It could also be used from Visual Basic 6 without any issues (I tested both). So I am a bit surprised that just using this unit would make the FPC command program not work... -- Bo Berglund Developer in Sweden -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] annoying *SPAM* (attn: Michael Schnell)
Hello Michael It seems like your email client is adding "*SPAM*" to the subject of emails coming from lazarus mailing list. Could you please add Lazarus@lists.lazarus.freepascal.org to the white list? Otherwise getting an email with *SPAM* prefix in the subject ruins the whole thread. I apologize if it's not your email client, but someone else's. But whoever's email client does that, please fix it. Changing thread subject ruins the whole idea of mailing lists. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
On 10/23/2015 02:12 PM, Sven Barth wrote: He simple needs to get the unit to compile (which he did by adding the LCL dependency) and stay clear from using any of the code that might use GUI. In that case there will be no dependency on a specific GUI, because the Interfaces unit is missing and the compiler might even smartlink away the GUI-related code that isn't used anyway. What about code in the "initialization" section of the multiple units that will get pulled even if using a single GUI related unit from the LCL ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
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 so right now. Bo's precise problem is that he does not want to restructure his code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 this, non-RAD will not be enough.). > > There is no shortcut on this way. That is why I recommended to do a standard GUI application with Lazarus. I somehow have the feeling that you and Graeme as well don't understand what Bo's precise problem is. He has a unit which is a collection of various different methods, classes, whatever. Some of these are related to GUI components (e.g. TTreeView) while others are not. He wants to use the non-GUI related code in his project without restructering the unit (for now). So this has /nothing/ to do with RAD or hom writing a console application or whatever. He simple needs to get the unit to compile (which he did by adding the LCL dependency) and stay clear from using any of the code that might use GUI. In that case there will be no dependency on a specific GUI, because the Interfaces unit is missing and the compiler might even smartlink away the GUI-related code that isn't used anyway. TL;DR: Yes, Bo should restructure his code, but he does not /need/ to do so right now. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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, yes, but is more difficult to understand, maintenance is compromised and hard to make tests. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 talked hehehe PS: Graeme, I agree with you but is funny. :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 I don't know such. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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 companies who sold Delphi.
>
> But it is very bad for portability. Investing some effort, it can be
> overcome, though (see my message to Graeme.)
>
In my understanding "RAD" is visually placing components in forms and
datamodules, to set component properties in objectinspector and to use event
properties in order to react on events.
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.
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
;-)
In order to connect the GUI with the business model use TDatasource and
TAction for example or use glue code. MSEgui additionally has the MSEifi
components from component palette tab "ifi".
Applications without GUI use tnoguiapplication instead of tguiapplication as
application instance for the main-eventqueue. tnoguiapplication has no
dependency on GUI-libraries and GUI-services and provides a platform
independent API. I assume Lazarus has a similar approach.
Martin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus implementation of TListView etc?
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. Investing some effort, it can be
overcome, though (see my message to Graeme.)
Lazarus does a great job regarding portability of RAD projects, but it
mainly has desktop usage in mind and not embedded gadgets.
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 this, non-RAD will not be enough.).
There is no shortcut on this way. That is why I recommended to do a
standard GUI application with Lazarus.
- Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] *SPAM* Re: Lazarus implementation of TListView etc?
On 10/22/2015 06:32 PM, 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. I had been at this point already years ago. As you might know, I myself do not have any Pascal "user" project to do, but what I wanted was to provide a "toolbox" for my colleagues, who manage a huge "embedded" Delphi project and would like to run it on Linux. As the project in fact is a Windows Service, the Linux machine is supposed to run "headless". This is exactly the same task as Bo has in mind. Now my colleagues (like Bo) decline to modify the Delphi code greatly, as the project still needs to be able to compile and run in Delphi for a long time in the future. (A friend of mine, as he faced the same issue, in fact rewrote his complete former Delphi project in Python and finally was very happy with this.) So what they want is workalikes for the visual Delphi components (as they are provided by the LCL) but in a variant (i.e. "Widget type") that does not need a GUI binding. That is why I hat been working on an "ActiveNoGUI" Widget type (a better name might be "General Service Application", as its supposed to be independent of the OS and the ARCH). In a first step it just should provide handling the fpc-RTL's TThread queue events, Application.ProcessMessages(), Application.QueuAsyncCall(), and TTimer. In a second step as many dummies for visual components as possible (or necessary) should be provided, maybe with some basic display/keyboard functions via pipe/telnet In a third step "ifi" functionality should be added for providing an as complete as possible (or necessary) remote GUI. But right now, these plans are of less interest in the company, as WIN 10 IOT provides running Delphi Service applications on a not bloated cost-free OS and cheap hardware such as the MinnowBoard MAX.. (Maybe not a bad idea for Bo, as well.) As with any newer version of Windows, a Service is not allowed any more to (optionally) show a GUI, we (company) are pursuing the "un-RAD"ing of the software (separating the business-logic and the GUI in distinct units) anyway. So the result will be a compiled Delphi project and run on Win IOT. A remote user interface can be done by TCP/IP - streaming the completely propriety interface between these two brands of units. Regarding Bo's project: This "un-RAD"ing would eliminate TListView and friend and allow for making it a reals Service (even still in Delphi) and then port it to headless Linux using Lazarus. (As I don't think he wold be inclined to follow me on the long (endless ?) path: General Service Application" Widget Type -> enhancing same to the visual components he uses -> "ifi"). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
