On 22.03.2017 14:50, Marc Weustink via Lazarus wrote:
From what I've read, I fear not.
Supposedly true. AFAIK there is no support for Win IoT on ARM by fpc. I
understand that IoT on ARM is very different form Win CE - but rather
similar to Win on X86, so fpc supposedly would need a completely
I'd like to check out working with Zeos and SQLite.
I have an "SVN" installation of Lazarus on Linux. So i used same for
testing.
I found a demo program and when trying this I found it includes the line
sLibraryLocation := sAppPath + 'sqlite3_library.dll';
So it obviously is doe for Windows (O
On 19.04.2017 16:31, Graeme Geldenhuys via Lazarus wrote:
That's very impressive. I'm still amazed at what is actually possible
via a web browser - other than just viewing web pages. Thanks for sharing.
In fact my little QNAP NAS (an ARM Linux Box) features a GUI vi Browser
that is very similar
On 19.04.2017 17:21, Graeme Geldenhuys via Lazarus wrote:
I believe that is what Michael van Canneyt is working on.
It seems like, which to me is great news !
Of course we would need first a Pascal->WebAssembly compiler and then a
new WidgetType in Lazarus. Same maybe could be derived from
"
On 20.04.2017 09:54, Santiago A. via Lazarus wrote:
That is what RAD and GUI designers were created for ;-)
Obviously it's not easy to do a (compatible) GUI designer for a
Browser-(remote)-GUI. Otherwise I suppose Lazarus would have it.
With WebAssembly, maybe there is a new chance...
-Micha
On 20.04.2017 11:11, Graeme Geldenhuys via Lazarus wrote:
Yes, many times.
There obviously are lots of alternate GUI design tools (e.g. mse,
FireMonkey, WXPython (Poenix), ...) . But for Lazarus users, it of
course would be beneficial to be able to use the GUI designer already
perfectly wor
+1 !!!
The dream:
Write and test a program using in a (partly) RAD way, of course in an
Event-programming way, using the Lazarus IDE - say - in Windows.
Now just by changing some settings, compile it for
- Win32
- Win42
- Win 32 or 64 as a service (hence also running on WIN IOT Core)
- MA
On 04.05.2017 16:56, Juha Manninen via Lazarus wrote:
I believe everybody is happy to get rid of the horrendous Windows
If if this is true, there is a decent need for backwards compatibility.
That is why, theoretically, code aware strings is a good idea.
Unfortunately the implementation of thos
On 05.05.2017 12:16, Graeme Geldenhuys via Lazarus wrote:
In the end it’s about supporting Unicode. Does it really matter
what internal encoding it is to achieve the “Unicode support”
goal?
Yep it does.
There are ways around that issue (i.e. code aware strings) but in fact
these trigger a new
Vielen Dank für den Hinweis !
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
On 09.06.2017 09:38, Steve Gatenby via Lazarus wrote:
I create a thread every second to run a process (TAsyncprocess), then
FreeAndNil the process once done.
Would it not be more appropriate to use a thread pool and keep the
threads up, waiting for a TEvent telling them what to do ?
-Mic
On 17.06.2017 22:25, el es via Lazarus wrote:
Where does the call queued from a thread, return to ?
From the POV of the application programmer: "nowhere". it's just
another (main-Thread-) "Event" that (like "OnClick") gets "fired" by the
Lazarus/fpc infrastructure and is done.
The object's lif
On 04.07.2017 08:04, Michael Van Canneyt via Lazarus wrote:
So at the moment the developer experience would not be very good, I
think you're better off using a HTML5 based Ionic app.
This of course is bad news, but we do hope for improvement when time
comes
See -> http://www.remobjects.c
They claim Delphi VCL compatibility and hence it should be compatible to
LCL, as well.
-> http://www.elementscompiler.com/elements/whatsnew.aspx
(I did not test any of their products.)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.or
On 13.08.2017 22:41, Juha Manninen via Lazarus wrote:
You have misused "String" or "AnsiString" from the beginning for binary data.
There have always been warnings against it.
While this might be true, it's decently silly, IMHO.
The name "String" can easily be interpreted as "String of things"
On 14.08.2017 14:50, Marcos Douglas B. Santos via Lazarus wrote:
"The right solution is to use Unicode everywhere."
Embarcadero though that this would not b the "right" solution. Otherwise
they would not have invented the encoding aware strings.
IMHO that was a good idea. They only completely
On 14.08.2017 18:49, Sven Barth via Lazarus wrote:
Because the crowd demanding Delphi compatibility is larger than the
crowd demanding exact terminology.
... or even a revised concept avoiding the junk presented by Embarcadero :(
But obviously the fpc team has no choice.
-Michael
--
__
On 14.08.2017 18:47, Sven Barth via Lazarus wrote:
The main problem of such a dynamic type would be the inability to do
fast indexing as the compiler would need to insert runtime checks for
the size of a character.
What "indexing" do you think of ?
Could you give an example where such a dif
On 15.08.2017 11:25, Michael Van Canneyt via Lazarus wrote:
WideString/UnicodeString for those that want 2-byte characters.
A codepage-aware single-byte string for those that want 1-byte
characters.
The shortstring is even still available.
IM (often stated) O, this does not help as long as TS
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote:
In this case, I would argue that both are true.
And the culprit obviously is Embarcadeo and not the fpc or the Lazarus
team, who did their best to try to do a compatible and implementation
that is really workable on the multiple supported pla
On 15.08.2017 11:52, Michael Van Canneyt via Lazarus wrote:
This cannot be solved properly except by duplicating the classes unit.
Sorry to disagree, but IMHO this can only be solved properly by defining
an additional fully dynamically encoded string type and use same for
TStrings (see ->
ht
On 15.08.2017 12:11, Mattias Gaertner via Lazarus wrote:
It does not explain what the characters of DynamicString are, does it?
I don't understand what you are asking.
The element size and encoding of a Dynamic String ("CP_ANY" in the
document) are not predefined, but depend on the content:
On 15.08.2017 12:15, Michael Van Canneyt via Lazarus wrote:
What does S[2] mean in your proposal ? Is it 1, 2, 4 or even 8 bytes ?
Regarding the users' appreciation, the S[x] notation is decently
incompatible between the different string types and compiler versions.
There were hundreds of comp
On 15.08.2017 13:19, Graeme Geldenhuys via Lazarus wrote:
Just wanted to show you guys something.
Great.
CrossVCL seems to allow to easily port Delphi VCL applications to Mac
and Linux.
How to compare it against Lazarus ?
-Michael
--
___
Lazarus
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote:
Why shouldn't there be a single char type that intuitively represents
a single character regardless of how many bytes are used to represent it.
I suppose by "char" you mean "single printable thingy" with Unicode it's
rather debatable what suc
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote:
3. The problem with string handling today is that it is not based on a
consistent approach to the character type.
If you clean up character handling then the model for string
handling should become obvious. A string is after all no m
On 15.08.2017 14:53, Mattias Gaertner via Lazarus wrote:
Do you mean a 'char' is a string in your proposal?
Nope. In my proposal there would be Chars for any statically encoded
String Type, hence 1, 2, 4, and 8 byte wide. (As regarding statically
encoded string (and char) brands, it's just an e
On 15.08.2017 21:40, Ondrej Pokorny via Lazarus wrote:
Too bad that Eugene didn't decide to improve Lazarus Cocoa bindings :)
Does he use fpc as a compiler ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.
On 15.08.2017 19:18, Graeme Geldenhuys via Lazarus wrote:
Why can't that be changed to a UnicodeString or UTF8String
IMHO, any implementation of TStrings that forces a conversion (just
because the class uses TStrings and not due to a logical demand), is a
contradiction to providing code awar
On 15.08.2017 19:29, Luca Olivetti via Lazarus wrote:
I has worked extremely well and reliably until fpc 2.6.4 (i.e. with
string=ansistring).
Does it not work in 3.x?
I understand that storing uncoded Bytes in UTF8-Strings (hence in fpc)
works as good as it always had, as long as all strings ar
On 15.08.2017 21:38, Ondrej Pokorny via Lazarus wrote:
Furthermore, if you use(d) strings for binary data, just replace old
string for AnsiString/RawByteString (and Char for AnsiChar, PChar for
PAnsiChar) and you are good to go. Annoying but no big deal.
This only works if all tools that you u
On 15.08.2017 22:45, Graeme Geldenhuys via Lazarus wrote:
How is that not "abuse"???
IMHO it's a major shortcoming to define "string" as "printable text". In
fact the name "String" does not suggest this at all. A "string" in my
understanding just is a sequence of similar "things".
A string
On 16.08.2017 10:58, Mattias Gaertner via Lazarus wrote:
This thread is going out of topic.
Please start a new thread if you want to discuss Delphi strings.
You can't discuss fpc's string problems without mentioning Delphi, as
they are a direct consequence as well of Delphi-compatibility as of
On 15.08.2017 19:53, wkitty42--- via Lazarus wrote:
what if 3 and 4 byte characters are required? will they also work in
UnicodeStrings?
UTF-8 and UTF-16 are just encoding variants for 32 bit Unicode
"characters", storing them in n (or 2*n) Bytes according to a simple
scheme.
-Michael
--
___
On 15.08.2017 18:33, Mattias Gaertner via Lazarus wrote:
Do you propose a string without the array operator [] ?
I don't understand what you mean by this.
Of course an appropriate "char" type for each string encoding brand
could to be provided, hence a "CP_QWord Char" as an alias or a QWord.
On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote:
So it makes sense that TStrings should use UnicodeString internally to
store its data. The Unicode standard is also the only standard that
can support any language.
But in fact "Unicode" is just a universal standard defining 64 bit
enti
On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote:
Are you suggesting that internally TStrings should have different
storage for all possible languages,
Not at all. In the said paper I point out that a new fully dynamical
string encoding brand would be introduced and same is used for TStr
On 16.08.2017 11:32, Mattias Gaertner via Lazarus wrote:
Anyone who wants to discuss the grand picture of strings in FPC for the
millionth time should start a new topic.
Right you are. And it will be by far too late and futile, anyway,
because of the reasons discussed a million times.
-Michae
On 16.08.2017 11:55, Mattias Gaertner via Lazarus wrote:
1,114,112 possible code points need at most 21 bits. Due to encoding
at most 32bit.
Sorry. Typo.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/
On 16.08.2017 11:51, Mattias Gaertner via Lazarus wrote:
Every Delphi/FPC type has a bunch of operators. Strings support :=, =,
<>, >=, <= and [] for read and write.
When you propose a new string type "dynamicstring" you have to define these
operators.
That is easily doable.
The definition of
On 16.08.2017 12:22, Juha Manninen via Lazarus wrote:
You should stop writing in this thread now. I agree with Mattias.
I perfectly agree with you. But you can't blame me for answering when
asked.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.l
BTW.:
This is off topic in the Lazarus list and would be an fpc issue.
Moving it in one of the fpc lists would have the additional advantage
that I am banned there, anyway, for having answered to similar questions.
-Michael
--
___
Lazarus mailing lis
On 16.08.2017 13:17, Mattias Gaertner via Lazarus wrote:
You are confusing people if you name your encodings like this.
There also is no "official" Code pages named "Default" or "None", the
naming "CP_DEFAULT" and "CP_NONE" has just been invented by Emparcadero.
So I did the same and just brai
On 16.08.2017 14:30, Martin Frb via Lazarus wrote:
And that would still not be "char", but "codepoint"
A char can be composed of several combining code points (each of them
afaik, in the 32 bit range).
So a char can have 96 or more bits. (And not all of them have a
combined form).
Unfortunate
On 16.08.2017 14:22, Alexey via Lazarus wrote:
BTW, it will be good to have "Cstring" (or another name, not
"dynamicstring") : ...
You are missing the point the paper is supposed to be about: enhancing
the versatility of the library functions such as those using TStrings.
Not just creating an
On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote:
Not if complicated things get more complicated.
Please leave out the additional encoding brands suggested just as an
afterthought in the paper. These are not the purpose at all but ()if the
other stuff would be in place) just com as a nat
On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote:
For some unknown
reason you want to store different encodings in a TStrings and fear
the "time-consuming" and loss-prone auto conversions.
It's obvious that a user using a different encoding brand in a string
var than that suggested by TSt
On 16.08.2017 15:33, Juha Manninen via Lazarus wrote:
Why don't you implement such a system. This is all FOSS, free and open
source.
I would never dare to try to edit the compiler :-[
You are writing about encodings etc. which are part of codepoints, but
you call them "characters". Why?
Becaus
On 16.08.2017 17:20, Juha Manninen via Lazarus wrote:
Unicode is the standard now. We cannot ignore it, and we don't want to
ignore it because it solves so many problems of the earlier solutions.
If you create a new string type, you certainly must take Unicode into account.
It is not "ignored",
On 16.08.2017 17:55, Juha Manninen via Lazarus wrote:
although Pos(), Copy() and Length() deal with CodeUnit resolution.
I wonder how the new fancy string types would handle it without a
performance penalty.
This again is not in the scope of the paper, and supposed to stay as it
is. S[x], Pos(),
On 16.08.2017 18:24, Mattias Gaertner via Lazarus wrote:
This "dynamicstring" sounds like Rawbytestring times two.
In fact I do suppose that the initial intention the Developers had with
Rawbytestring, was something like this, but it never was implemented or
documented appropriately. In fact I
Maybe, Sven could answer to this mail in the other thread...
On 14.08.2017 18:47, Sven Barth via Lazarus wrote:
The main problem of such a dynamic type would be the inability to do
fast indexing as the compiler would need to insert runtime checks for
the size of a character.
What "indexing
On 16.08.2017 20:26, Luca Olivetti via Lazarus wrote:
Call me lazy but I don't want to reinvent the wheel and re-implement
from scratch the functionality that a plain ansistring provides and
TBytes to this day doesn't.
So please continue in the thread "dynamic string proposal".
Exactly this
On 16.08.2017 22:40, Sven Barth via Lazarus wrote:
Trunk supports Insert() and Delete() on dynamic arrays, Concat() and +
are on the near term ToDo list.
Supposedly "pos", as well. But that does not really help if we don't
have a TStringList workalike, and supposedly several more library
func
On 17.08.2017 11:29, Sven Barth via Lazarus wrote:
Am 17.08.2017 11:11 schrieb "Michael Schnell via Lazarus"
mailto:lazarus@lists.lazarus-ide.org>>:
>
> Maybe, Sven could answer to this mail in the other thread...
>
I provided an example in my answer to Tony Whyman
On 17.08.2017 12:09, Bart via Lazarus wrote:
Variables of the ordinal type Char are used to store ASCII characters."
According to this wording, using Windows with ANSI character set would
be a no-go.
-Michael
--
___
Lazarus mailing list
Lazarus@l
On 17.08.2017 12:41, Tony Whyman via Lazarus wrote:
UCS-2 differs from UTF-16 by being a constant length encoding and only
capable of encoding characters of BMP, it is supported by many programs."
Rather obviously Embarcadero primarily had UCS-2 in mind as they created
the "Unicode aware" De
On 17.08.2017 12:41, Tony Whyman via Lazarus wrote:
Finally: "In UTF-16, code points greater or equal to 2^16 are encoded
using /two/ 16-bit code units.
2¹⁵ ???
-Michael--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-i
On 17.08.2017 14:43, Sven Barth via Lazarus wrote:
Yes it does, because without optimizations implemented and enabled the
compiler would need to do this for each element access.
But it does not need to do a function call. If getting the element size
of a string is a pascal function it would
On 17.08.2017 11:27, Sven Barth via Lazarus wrote:
Why do you want to stuff everything and the kitchen sink into TStrings?
To make use of the benefits the string type offers such as reference
counting and lazy copy.
-Michael
--
___
Lazarus mailing
On 18.08.2017 11:01, Graeme Geldenhuys via Lazarus wrote:
On 2017-08-18 09:16, Tony Whyman via Lazarus wrote:
Damn, should remember never to copy and paste from Wikipedia!
Or simply use "plain text" emails
To explain my mail above in plain Text:
A 32 bit Unicode needs two UTC-16 codes when
On 18.08.2017 14:26, Sven Barth via Lazarus wrote:
Delete(), Insert() and Pos()
I understand those, and "+", etc, are in the pipe for Array of Byte, as
well.
I suppose workalikes for the most important TStrings siblings, such as
TStringlist (including sort and LoadFromFile) be doable on to
On 20.09.2017 22:09, Marcos Douglas B. Santos via Lazarus wrote:
In a perfect design, we may only connect all objects to work in a
"task", call "run", and "they" will know what to do. They (Objects)
will decide how to do. Not the programmer (the "controller"). Just
objects sending messages for
On 28.09.2017 15:35, Marcos Douglas B. Santos via Lazarus wrote:
https://github.com/EtheaDev/kitto2
Seems like an interesting project.
I once did some rather successful tests with ExtPascal but gave up as
ExtPascal seemed to be dead.
Now at -> http://www.ethea.it/eng_news.htm we read: "Septe
I rather unsuccessfully tried to use the pdf decoder example provided
here -> http://wiki.lazarus.freepascal.org/fpvectorial .
I needed to add the package fpvectorial to my project. Now I can do "use
fpvectorial".
The project needs "use pdfvectorialreader". To allow for this I needed
to add
On 24.10.2017 10:48, el es via Lazarus wrote:
[...]
begin
repeat
until not ThreadNowInUse; //
try
ThreadNowInUse :=true;
Busy wait actions are usually a very bad idea
Better use a TTimer for such.
-Michael
--
___
Lazarus maili
On 24.10.2017 11:29, Mattias Gaertner via Lazarus wrote:
Are you kidding?
If this is not appropriate, I suppose the general design of that
functionality should be reconsidered, doing anything that needs a fast
reaction in the worker thread.
-Michael
--
___
On 07.11.2017 10:55, Alexey via Lazarus wrote:
https://bugs.freepascal.org/view.php?id=32653
wp wrote: >>Sorry I will not fix this one because it opens another
Pandora to add features well-established in TAChart.
Pls apply the patch. it makes several plots on one panel. What
Pandora?? I don'
On 08.11.2017 08:57, Michael Van Canneyt via Lazarus wrote:
Normally, early december a RC version of pas2js will be released.
I understand that the issue of this thread is using Lazarus to do a
server based "Rich Internet" application that shows it's GUI in the browser.
So pas2js is only part
On 08.11.2017 11:14, Mattias Gaertner via Lazarus wrote:
A server is not needed. You can write standalone browser applications that work
offline too.
OK. Great ! Stand alone browser based applications might be one
desirable type of application, but AFAIK, the more commonly required
type of ap
On 08.11.2017 12:28, Michael Van Canneyt via Lazarus wrote:
It is the basic building block.
I do agree that it is a very viable building block, but theoretically
for "Rich internet Applications" there are alternatives:
- WebAssembly (which as far as I understand is considered for fpc, and
I su
On 08.11.2017 08:47, Marcello via Lazarus wrote:
Are there any information about it?
I just found and watched -> https://prezi.com/upueosj4ep0q/pj-suite/?webgl=0
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus
On 08.11.2017 13:12, Michael Van Canneyt via Lazarus wrote:
ExtPascal way (or UniGUI for that matter) is the wrong way to do
things. Interesting as a toy, but not suitable for
a) Large, scalable websites
b) serveless applications.
Agreed ! But if doing a server based application (ore one that i
On 08.11.2017 14:15, Sven Barth via Lazarus wrote:
Nope, WebAssembly and what pas2js does are two different things even
if in the end both run in the browser's JavaScript engine.
Of course I do know this.
But AFAIK WebAssembly has been invented with JS in mind, so it might
follow some paradi
On 08.11.2017 16:39, Michael Van Canneyt wrote:
.. I believe that you should embrace the platforms you're using. That
means: browser as client, webserver as server, and HTTP or websocket
as the transport layer.
This depends on who is "you" :) .
I've already been doing some " Lazarus Community
On 09.11.2017 11:12, Michael Van Canneyt via Lazarus wrote:
We are busy creating this framework.
Great. From the previous messages I got the impression it would be
depreciated.
But Rome wasn't built in a day.
Obviously. I am not trying to hurry anybody. I am very happy with what
Lazarus and
On 26.11.2017 17:13, Sven Barth via Lazarus wrote:
Lazarus already contains a custom drawn widgetset that supports X11. I
don't know its current state, but maybe it would be best to bring that
up to speed and form instead of starting a new one.
Some time ago I did play with the custom drawn Wi
On 26.11.2017 18:32, Kostas Michalopoulos via Lazarus wrote:
i am already working on a widget toolkit for a few years now which is
written in C ... Most of my code is LCL specific
This seems like a very peculiar combination to me.
-Michael
--
___
La
On 27.11.2017 20:07, Graeme Geldenhuys via Lazarus wrote:
Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI
widgetsets get some more attention.
Is there any chance to unify them to a single Widget Type implementation
that uses a low level graphics API (without an external Widg
On 27.11.2017 19:59, Graeme Geldenhuys via Lazarus wrote:
(except for TLabel)
To me TLable seems like very important to allow easy "porting" of
applications from an other widget Type to fpGUI/LCL.
Is implementing TLabel really that hard ?
-Michael
--
___
On 28.11.2017 11:28, Sven Barth via Lazarus wrote:
Why should they? They are two completely different projects. From the
LCL's point of view fpGui is a black box like GTK, Qt or the Windows API.
OK, so in the end fpGUI *is* an external Widget set, only that it comes
more independent of the OS di
On 30.11.2017 00:02, Graeme Geldenhuys via Lazarus wrote:
RAD style development is highly overrated...
I do know that very exactly, been there often enough.
RAD is great to create "small" applications, but with huge projects, you
will very likely hit a limit where you wish you would not have
On 30.11.2017 10:04, Michael Schnell via Lazarus wrote:
e.g. a small embedded device or to allow running them as a service..
Of course another important "headless environment" is server
applications with built-in Web server or sitting behind a standard
WebServer.
On 30.11.2017 12:09, el es via Lazarus wrote:
It is not easy to break free from old, ... programming practices
Nonetheless, IMHO RAD is a great way to start programming, as you
immediately and painlessly can see (visualize) what your "business
logic" software does and easily set parameters an
On 01.12.2017 07:42, Martin Schreiber via Lazarus wrote:
separating of GUI and business logic is perfectly possible with RAD.
Yep. But you need to apply this discipline to yourself right from start
of the project, as doing this afterwards is tedious.
Unfortunately many projects arise from slop
On 01.12.2017 08:22, Martin Schreiber via Lazarus wrote:
For me Delphi is not the best RAD environment and therefore
developments made with Delphi should not be used to disqualify RAD as
a whole.
Which are there other than Delphi and its siblings ?
-Michael
--
__
On 01.12.2017 20:43, Graeme Geldenhuys via Lazarus wrote:
On 2017-12-01 13:33, Marcos Douglas B. Santos via Lazarus wrote:
I believe RAD is the best way to code a GUI
I'll even disagree with that - somewhat. :)
http://geldenhuys.co.uk/articles/model-gui-mediator.pdf
The article start
On 05.12.2017 00:50, Graeme Geldenhuys via Lazarus wrote:
DBGrid behaves slightly different to TStringGrid, and is slow.
While for perfect performance / clearness / portability / ... , DBGrid
supposedly should not be used in a production release, it might be very
helpful when designing an appl
On 05.12.2017 12:16, Martin Schreiber via Lazarus wrote:
What is wrong with TDBGrid???
As I quoted, Graeme claims it's slow.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Featuring "parallel loops", "future variables", etc, implemented via a
thread pool that is transparent for the application programmer.
-> http://docwiki.embarcadero.com/Libraries/Tokyo/de/System.Threading
-Michael
--
___
Lazarus mailing list
Lazarus
sorry
-> http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Threading
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
On 15.02.2018 22:22, Michael Van Canneyt via Lazarus wrote:
Yesterday, TMS Software has released a tech preview of their "TMS Web
core" product for Delphi.
Great stuff indeed !
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https:
On 08.06.2018 19:05, Bo Berglund via Lazarus wrote:
This Delphi package is a collection of some 20 components and all of
them have Register procedures inside of each source file.
Are those really IDE-relevant packages (showing up in the visual
component selection ) ?
If not, they might be ju
On 10.06.2018 15:11, Bo Berglund via Lazarus wrote:
... Build IDE: Exit code 2, Errors: 23 ...
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.or
On 11.06.2018 21:03, Bo Berglund via Lazarus wrote:
On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus
wrote:
You want to compile some 3rd party Dongle code in the IDE ?
That is more than weired !
Sorry, I don't really know what you mean here...
What is the reason for
On 12.06.2018 11:30, Sven Barth via Lazarus wrote:
Only because the code is part of a package that's loaded by the
Delphi IDE does not mean that it also is one in the final Delphi
program. Delphi package distributions more often than not also contain
the DCU for static linking.
Of course you
On 12.06.2018 14:06, Sven Barth via Lazarus wrote:
The dongle code would also be linked if it would be in a dynamic
package and Lazarus would support them.
Sorry, I seem not to be have been clear.
The (potential) problem I want to provide a solution for is: not to link
the Dongle code in the L
On 12.06.2018 17:08, Sven Barth via Lazarus wrote:
No. Delphi does *not* solve this by using dynamic linking.
OK. I see. Thanks for pointing this out.
Hence in such a (potentially problematic) case the suggested solution
might be helpful even with Delphi.
But as Bo's code seemingly works fin
There are application that require a „stylish“ GUI for optimum user
satisfaction, …. And there are applications that do their thing more or less on
their own, requiring human attention only for configuration and service.
-Michael
--
___
lazarus maili
Wonderful !!!
-Michael
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
1 - 100 of 173 matches
Mail list logo
