On 10/27/2011 05:02 PM, Felipe Monteiro de Carvalho wrote:
http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls
http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Package
In fact I understand that fpGUI already is a custom drawn Widget set and
it does work (to some extend) with
On 10/28/2011 02:25 PM, Graeme Geldenhuys wrote:
Wouldn't it
simply be easier to work on LCL-fpGUI widgetset interface instead?
LCL-fpGUI looks very promising, indeed !
I would appreciate improvements on LCL-fpGUI a lot. If anybody starts
working on same, I might be able to supply some suggest
On 10/24/2011 01:53 PM, Hans-Peter Diettrich wrote:
What else is the convention, whether e.g. "oe" should be combined into
"œ"?
oe = œ = eo = ö = o + (some character that just consits of two
dots) = ?
-Michael
--
___
Lazarus mailing
On 10/24/2011 01:34 PM, Hans-Peter Diettrich wrote:
Please note that the RawByteString type is not an intended type for
variables, only for subroutine arguments.
I'm not speaking about wow anything is intended, but asking about a
definition what the compiler is to do when these cases are detecte
On 10/24/2011 01:34 PM, Hans-Peter Diettrich wrote:
I'm not sure what you mean. Whenever a UnicodeString is passed as an
argument, the UnicodeString version is called, not the RawByteString
version.
I'm not speaking about any existing procedures, but those somebody can
do and thus do not ha
On 10/21/2011 11:48 PM, Hans-Peter Diettrich wrote:
What if a file on the user computer has 4byte [visible] character as
8th character and you, for example want to get 8 character file name?
In this case you split that 4 byte character and have garbage.
For me (and for Linux) a file name d
On 10/21/2011 01:26 PM, Michael Lutz wrote:
Ever heard of decomposed characters?
Handling those in a computer program seems similar to having the
computer understand a philosophical text.
Allowing decomposed characters in a string and trying to match them
against identically _looking_ single
+1 to all points.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 10/21/2011 10:24 PM, Hans-Peter Diettrich wrote:
The bad news about new Delphi strings is the addition (overload) of
functions with RawByteString arguments, which *take* strings of any
encoding, but then *ignore* that encoding. These versions certainly
must fail for all MBCS encodings :-(
On 10/21/2011 04:13 PM, Michael Lutz wrote:
If you write a file with a file name in unicode NFC in OS X
and read the file name back from the OS, you'll get a NFD string returned,
which means a normalization-unaware compare function will not do what
you'd expect.
...as already mentioned in anothe
On 10/21/2011 02:18 PM, Žilvinas Ledas wrote:
What if a file on the user computer has...
If you deal with the content of files you did not write yourself, you of
course need to deal with whatever encoding same has been done in (maybe
its EBCDIC :) ). This is unavoidable and if you are so unhap
On 10/21/2011 10:09 AM, Graeme Geldenhuys wrote:
We use the Science and Maths symbols define outside the BMP all the time
in our products.
So with these projects you obviously are a "Unicode aware" programmer
and don't qualify for the group of "office" programmers that (IMHO)
should be enabled
On 10/20/2011 10:26 PM, Felipe Monteiro de Carvalho wrote:
Mac OS X uses the decomposed form in UTF-8 to store filenames, which
is rather unpleasant.
Why are they so silly ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
h
On 10/20/2011 05:49 PM, Mattias Gaertner wrote:
Often they say: Linux has problems with unicode. Reason: teachers
think that unicode is so simple under java, so they don't explain it.
I see. Obviously a similar problem as with Delphi. (If E. in fact (like
promised some time ago) creates a Delp
On 10/21/2011 08:56 AM, Graeme Geldenhuys wrote:
That is such a rubbish statement! More and more information is being
added outside the Unicode's BMP. Emoticons, Science and Maths symbols,
Map Symbols (often seen in GPS applications), Music notes etc etc.
Those who deal with this of course need
On 10/21/2011 09:03 AM, Graeme Geldenhuys wrote:
You forgot surrogate pairs in UTF-16. Think outside
the Unicode BMP where a "visible" character will be 4-bytes, thus two
UTF-16 Char values.
Regarding this, there seemingly is no help at all :( (I understand that
even in full 32 Unicode there are
On 10/20/2011 09:42 PM, Felipe Monteiro de Carvalho wrote:
Changing the size of Char is not just small detail, this breaks *a
lot* of code. Any kind of memory operations such as Move will fail
because the char size changed.
Of course you are right, but "move" and friends is "hardware-near
progr
On 10/20/2011 04:34 PM, Felipe Monteiro de Carvalho wrote:
Length does not give the number of chars? No problem:
As said: Of course this is no problem for those who do are aware that
they are dealing with Unicode and not with displayed characters. This of
course includes myself when doing new
On 10/20/2011 03:45 PM, Felipe Monteiro de Carvalho wrote:
Do you have any big applications
written in Lazarus? If you had, how happy would you be having to
convert them from utf-8 to utf-16?
I never voted for a UTF-16 - Lazarus.
In fact I have lots of applications done in Delphi < 2009 and th
On 10/20/2011 02:55 PM, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 20, 2011 at 2:54 PM, Michael Schnell wrote:
All others are fooled.
This is not true. My students from the 2nd year of engineering learned
alone how to use UTF-8 properly.
That is exactly what I meant to say. Those who do
On 10/20/2011 01:55 PM, Hans-Peter Diettrich wrote:
It's sufficient to agree that all (displayed) strings in the LCL
contain UTF-8 text, regardless of their type name (string types
currently are alias).
Plus: a "char" is not a displayable character but only can hold an UTF-8
code byte.
-Mic
On 10/20/2011 01:55 PM, Hans-Peter Diettrich wrote:
Functions with more than one (Ansi)String argument deserve special
care, the *user* is responsible to only supply strings of the same
encoding,
Very funny ! They invent a dynamically encoded string type that has the
power to trigger convers
On 10/20/2011 01:55 PM, Hans-Peter Diettrich wrote:
It's sufficient to agree that all (displayed) strings in the LCL
contain UTF-8 text, regardless of their type name (string types
currently are alias).
And thus functions like pos(), length() and myString[i] work on UTF-8
code bytes rather th
On 10/20/2011 09:43 AM, Martin Schreiber wrote:
I don't refer to Lazarus but to Free pascal compiler, RTL and FCL.
I suppose that there will be some kind of compiler switch allowing for
selecting whether or not to use the "new string" feature.
-Michael
--
___
On 10/20/2011 09:18 AM, Martin Schreiber wrote:
Now the FPC team destroyed a stable product in favor of
Delphi string compatibility.
I don't consider the current state of Lazarus "stable", as IMHO the
"UTF8 in type ANSIString" paradigm (seemingly forced by the underlying
FPC version) is too "sp
On 10/15/2011 04:42 PM, Hans-Peter Diettrich wrote:
Bernd schrieb:
Maybe this option should be inverted and renamed to: "program needs
console window". This will also affect whether on windows an attempt
to writeln() will crash your application due to missing stdout.
+1
The current wording i
On 10/13/2011 09:10 AM, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 8:48 AM, fred f wrote:
I have forgotten to mention, that this started to happen with latest
Lazarus/FPC svn versions.
Are you aware of the huge changes in FPC svn?
For now, I would not use it with Lazarus. Use
On 10/10/2011 11:36 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
In fact the help for any LCL and RTL function should say how it can
be used regarding threads.
Currently it's sufficient to know that the LCL is not threadsafe.
So you claim that nobody shoul
On 10/10/2011 10:34 AM, michael.vancann...@wisa.be wrote:
I don't think that the LCL should support this.
I did not want to suggest that it should (IMHO it would be "nice" to
have this as a special Application type, but it's (a) not easy to do and
(b) quite low priority. I in fact do have a (D
Type: LCL
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 10/10/2011 10:23 AM, Michael Schnell wrote:
type:
There are functions in the LCL especially done be called by worker
Threads,...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org
On 10/09/2011 03:14 PM, Michael Van Canneyt wrote:
It's not so on Unix. X-Windows is definitely not thread-safe.
Of course "in general" this is correct.
But I understand that it should be possible that an application (using
additional threads) creates more than one "Main Frame" by attaching to
On 10/09/2011 02:37 PM, Hans-Peter Diettrich wrote:
Mattias Gaertner schrieb:
Most LCL code is reentrant.
Only within the context of an single thread.
In a single threadded application only recursive functions can have
reentrancy problems.
As nearly all user code is done as an event (call
On 10/09/2011 10:49 AM, Hans-Peter Diettrich wrote:
The LCL is not reentrant. All code accessing the LCL should run in the
main thread (see Synchronize...), not in other threads.
Not true in this intensity.
There are functions in the LCL especially doe not be called by worker
Threads, and th
On 10/09/2011 09:55 AM, Mattias Gaertner wrote:
On Sun, 9 Oct 2011 08:14:41 +0100
Frank Church wrote:
How is it determined whether a piece of code runs within the LCL or not?
if GetCurrentThreadID=MainThreadID then
I understand his question as "How to find out whether a function in the
RTL
On 10/09/2011 09:55 AM, Mattias Gaertner wrote:
All LCL code that deals with Application, ... is
not thread safe and should only be accessed by the main thread.
Hmmm.
Application.QueuAsyncCall() is obviously created to be called by a thread.
So it's necessary to read the documentation to be s
On 10/09/2011 09:14 AM, Frank Church wrote:
Do you mean that TCriticalSection is part of the LCL and shouldn't be
run from within a thread, or that code within the thread or the
critical section must not run code accessing the LCL?
TCriticalSection is obviously done to be used in Thread.
On 10/09/2011 01:22 AM, Frank Church wrote:
Are multiple critical sections allowed in form or data module?
I don't understand your concern.
A DataModule is a way to organize the makeup and dependance of objects
(so strictly a question of data in memory).
A CriticalSection is a way to organiz
On 10/08/2011 06:17 PM, Bernd wrote:
There must be a thread about it here (but I can't remember its title)
and also I believe there was a demo program somewhere that
demonstrated this problem.
I did a demo program that tests several thread to mainthread signaling
functions. It can be found in
On 10/04/2011 01:54 PM, Mark Morgan Lloyd wrote:
Can a thread safely suspend itself, subject to an external resume? If
not, what is the "official" alternative?
A semaphore.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 10/04/2011 12:53 PM, Frank Church wrote:
I am looking at Application.QueueAsyncCall and the only parameter it
takes in addition to the method pointer is a PrtInt. That seems to
limit the options passed compared with TThread.Synchronize. Can the
PtrInt be cast to a pointer to a richer data
On 10/04/2011 12:26 PM, Frank Church wrote:
Isn't it possible to have add new fields to your thread that can be
interrogated?
Of course you can add any variables and properties to your TMyThread
Object. (This is just data-handling and completely independent of the
Thread "context" the code is r
On 10/04/2011 11:37 AM, Frank Church wrote:
What is the purpose of the while not Terminated in a threads execute loop?
If a thread is doing its own thing and knows when or not it has
finished what is the purpose of the while not Terminated
In Lazarus (and Delphi), "Worker Threads" can't have an
On 09/26/2011 04:34 PM, Marco van de Voort wrote:
That depends on what you want to do with it. I personally wouldn't bother.
Either do it right, or forget about it.
Yep. I am quite sure that _if_ I am going to need it I'll try to get the
current compiler version going.
Thanks,
-Michael
--
_
On 09/26/2011 11:06 AM, Marco van de Voort wrote:
Nearly everything. Afaik there are some 2.0 reg definitions for 68k, and
that is about it. And probably outdated by several years.
The 1.0.x codegenerator is totally different. It can be used in some cases
to see what it did in some cases, but f
On 09/24/2011 12:10 AM, silvioprog wrote:
"... The getTime() method returns the number of milliseconds since
midnight of January 1, 1970 and the specified date."
As the TDateTime type is a real incrementing in +1 for a day, it's easy:
var
BaseDate: TDateTime, MyDate;
MyMsecs: Int64
BaseDate
On 09/15/2011 10:37 AM, Felipe Monteiro de Carvalho wrote:
On Thu, Sep 15, 2011 at 10:01 AM, Michael Schnell wrote:
What is the reason why 68K is not supported in the newer versions ?
zero contributors and zero maintainers for such a port. Just the same
reason for every other missing feature
On 09/22/2011 05:28 PM, Krzysztof wrote:
Main problem is: I don't know how to tell thread (which is locked in
QueueAsyncCall critical section), that method pointer which he trying
to post, doesn't exists anymore.
Seemingly you want to create a queue of objects and/or strings that are
sent f
On 09/22/2011 02:56 PM, Michael Schnell wrote:
IMHO the better way is to check if the object exists in the main
thread when called.
Obviously you need to use a procedure of some other object (e.g. the
thread itself) and (if necessary) provide the object i9n question (that
might be destroyed
Why clear the queue ?
IMHO the better way is to check if the object exists in the main thread
when called.
-.Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 09/22/2011 12:17 PM, Kjow wrote:
I'll try to investigate :)
If you really desperately need "something more powerful" I suppose the
only way is to introduce a second GUI Window. This will might if you are
using a multi-Core System.
Obviously it is possible to create a second GUI Windows by
On 09/22/2011 11:40 AM, Kjow wrote:
2011/9/22 Michael Schnell:
QueuAsyncCall() does not considerably impact the Worker-Thread, so obviously
you mean that the main (GU-)I thread gets slow.
Here of course the correct way is to do the QueuAsyncCall() not too often.
(e.g. only when e.g. 5 % in
On 09/22/2011 10:52 AM, Kjow wrote:
Thank you for hint, but trying it the Form is too slow and
semi-freezed.
QueuAsyncCall() does not considerably impact the Worker-Thread, so
obviously you mean that the main (GU-)I thread gets slow.
Here of course the correct way is to do the QueuAsyncCall()
The best (portable and avoiding "Windowish" stuff) way to notify the
main thread about the state of a thread (so that the main thread can
e.g. advance a progress bar without temporarily stall the worker thread
is "Application. QueuAsyncCall()".
Same fires a procedure in the main thread and pr
Sorry, I suppose I misunderstood one of your previous messages.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 09/20/2011 02:41 PM, Sven Barth wrote:
Huh? What do you mean here? If String is declared as a
AnsiString(CP_UTF8) then the a variable declared as String does
contain UTF8 data... and any code can detect that by using GetCodePage
which will return CP_UTF8.
Ah, I see. He was meaning a New S
On 09/20/2011 01:09 PM, cobines wrote:
String=AnsiString(CP_UTF8),
Meaning that a library function (or an FPC syntax candy feature) can't
detect the code that is used for the string.
If you mean UTF-16 UnicodeString then I don't think there will be a
problem.
AFAIK, Lazarus does not use UTF-16
On 09/20/2011 11:09 AM, Luiz Americo Pereira Camara wrote:
Nope. AFAIK String type will automatically map to UTF8 or UTF16 string
depending of a compiler switch or directive and the RTL used (UTF8,
UTF16).
What do you mean by "map to UTF8" ? AFAIK, there is no string type in
FPC that decently d
On 09/20/2011 07:39 AM, Hans-Peter Diettrich wrote:
In the past days I've updated the LCL docs,
Some weeks ago I hard but unsuccessful tried to compile the DocView
files for the lcl documentation. Is this possible now ?
Thanks,
-Michael
--
___
Lazar
On 09/19/2011 06:35 PM, Luiz Americo Pereira Camara wrote:
On 19/9/2011 09:47, Michael Schnell wrote:
I don't suppose Lazarus can work with a cpstrnew version of FPC at all.
Supposedly moving Lazarus to cpstrnew will be a lot of work.
Not at all. Since fpc will provide two rtl (UTF
On 09/18/2011 04:22 PM, cobines wrote:
Hello.
Yesterday there was a commit:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=32374
"don't use UTF8String type in the code. It will cause problems when
cpstrenew branch is merged"
What problems could it cause, is it be
On 09/18/2011 02:28 PM, Frank Church wrote:
I switched a program which I knew worked perfectly in Win32 to GTK2
and the Synchronize(@DispatchOutput) stopped working.
I recently verified that TThread.Synchronize does work (in my testing
program) in the current svn version of Lazarus. It did not w
On 09/15/2011 09:59 PM, Sven Barth wrote:
Some TVs are running on MIPS with Linux now... just as a sidenote (I
personally own a TV with an ARM and a Linux :P )
I was very disappointed to find that the settop box from Deutsche
Telekom I have uses WinCE :(.
-Michael
--
_
On 09/15/2011 10:28 AM, Mark Morgan Lloyd wrote:
Michael Schnell wrote:
On 09/14/2011 04:37 PM, Sven Barth wrote:
You need to use a pre 2.0 version of FPC for this. The 68k code
isn't enabled and/or maintained in current versions.
Of course you can try to revive it again :D
Seems v
On 09/15/2011 11:25 AM, Mark Morgan Lloyd wrote:
...
Thanks for the pointers
In any event please write up what you do for the wiki to get it "into
the record".
Of course I'll be posting here when starting this :-) .
-Michael
--
___
Lazarus mail
On 09/14/2011 06:32 PM, Mark Morgan Lloyd wrote:
Does that also apply to cross builds? Could Lazarus built with a
current FPC drive a 1.x compiler, or is it too different?
I don't think I would need to do that. I suppose I just need to point
Lazarus to the compiler to be used for ARCH 68K.
A
On 09/14/2011 04:37 PM, Sven Barth wrote:
You need to use a pre 2.0 version of FPC for this. The 68k code isn't
enabled and/or maintained in current versions.
Of course you can try to revive it again :D
Seems viable-
What is the reason why 68K is not supported in the newer versions ?
-Mic
On 09/14/2011 03:50 PM, Martin Schreiber wrote:
Is it possible/viable to use the Lazarus IDE for writing and compiling
the code ?
Is it possible to configure the Lazarus IDE to use gdb in cross-mode ?
Maybe you should have a look to MSEide too. MSEide has been designed
not only for MSEgui /
Wee seem to want to do an embedded project with an 68 Processor (in fact
a "Fido" chip by Innovasic, that provides the "CPU32" variant of the 68K
CPU).
This project does not use a normal OS, it just is a "program", no GUI,
no standard API.
The SDK for the chip supports the gnu tool chain and
On 09/05/2011 05:28 PM, Michael Schnell wrote:I'd like to do an
improvement to this project, but I got stuck.
I wanted to do it in a way that the active unit can unmodified be used
to be integrated in some regression test to be run unmonitored.
One of the test cases I do is "
On 08/31/2011 10:09 AM, michael.vancann...@wisa.be wrote:
THandle has a 'windows-only' ring to it.
I'm not a native speaker but AFAIK, a "handle" is just something you can
grasp some object at.
So a handle (type THandle) might be something to denote a certain object
without forcing to have it
On 09/05/2011 04:51 PM, michael.vancann...@wisa.be wrote:
Attach it to a Mantis bug report, and include in project 'Patches'
Thanks,
Done.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org
The FPC team is working on enabling the compiler to create (Android)
Java code.
Now the Wiki Page http://wiki.lazarus.freepascal.org/Android_Interface
does not yet seem to reflect this.
Here we read:
* method 1> Write the Pascal application as a library connected to
the Java applica
On 08/23/2011 03:34 PM, Felipe Monteiro de Carvalho wrote:
And please also create test projects for those and send to the bug
tracker. I think it would be good to start linking each item in those
tables to a test project in the lazarus source tree
I updated my testing project so that it now can
On 08/31/2011 03:37 PM, Martin wrote:
- Toolbutton (as in the toolbutton on top of the disass window) => now
that sghould always send the step-asm instuction
My silly old eyes did not see _these_ Tool buttons. In fact they do
work. Thanks !
IMHO, acknowledging that the Assembler Window has th
On 08/31/2011 02:20 PM, Martin wrote:
To be absolutely sure:
- you are using the toolbutton, not the keyboard shortcut?
I tried the toolbutton, the F7-Key and the Run->Step Into menu entry.
All do the same action as if the source code editor and not the
"Assembler" window would have the focu
On 08/31/2011 01:11 PM, Martin wrote:
If it does not work for you, please open the "Debug output" window
from "view" / "debug windows" and check what command is sent to gdb.
Same problem here (using the current svn version on Linux (X86 32 Bits)
The debug output is:
<-exec-step>
^running
On 08/31/2011 10:15 AM, Felipe Monteiro de Carvalho wrote:
line 153 is
line 153 of which files?
Ooops. fpguiobject.inc.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo
On 08/31/2011 10:09 AM, michael.vancann...@wisa.be wrote:
I think
Result := PtrUint(Timer);
is better and safer. THandle has a 'windows-only' ring to it.
I suppose you are correct, but the source code of the function in fact is
function TFpGuiWidgetSet.CreateTimer(Interval: integer; TimerFun
(using Linux X86 32 Bit):
Initiating TTimer with fpGUI Widget Type issues a Range check error:
Project eventtest raises exception class 'RunError(201)'
line 153 is
Result := PtrInt(Timer);
PtrInt in fact is "LongInt".
When stepping my example the value for the Timer variable is $B761AA0
On 08/29/2011 10:55 PM, Graeme Geldenhuys wrote:
On 29/08/2011, Michael Schnell wrote:
BTW when starting a TTimer that does not do anything, (while in the IDE)
the fpGUI flavor of the test projects makes the IDE hang.
I have no idea what you test project does, but here I use many timers
for
On 08/23/2011 03:34 PM, Felipe Monteiro de Carvalho wrote:
And please also create test projects for those and send to the bug
tracker.
Where to place the testing project ?
Currently the testing project has a GUI and needs manual interaction. Is
it viable to do automatic regression tests ? How
On 08/26/2011 05:32 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
On 08/25/2011 12:04 PM, Hans-Peter Diettrich wrote:
I can update that documentation myself, no need to bother others
with patches.
Patches are invented for managing concurrent updates.
No, that's C
On 08/25/2011 12:04 PM, Hans-Peter Diettrich wrote:
I can update that documentation myself, no need to bother others with
patches.
Patches are invented for managing concurrent updates.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.la
On 08/24/2011 03:47 PM, Michael Schnell wrote:
(supposedly somehow via Dispatch).
Maybe via SendMessage() that uses the same "Message" parameter and
simply calls Dispatch.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.free
eOn 08/24/2011 02:09 PM, Graeme Geldenhuys wrote:
I would imagine in the case of LCL-fpGUI, it is simply not implemented.
fpGUI itself does have fpgPostMessage() and fpgSendMessage() functions,
that work fine for what they were designed for.
Pleas don't get me wrong ! I did not intend to nag on t
On 08/24/2011 12:24 PM, Marco van de Voort wrote:
Where? The synchronize queue is in sysutils.
The events created by GUI actions and those created by
TZThread.Synchronize and those created by PostMessage and aimed to
"procedure...message" finally create actions calling the "Dispatch"
mechanism
On 08/24/2011 12:23 PM, Marco van de Voort wrote:
QueueAsync is a Lazarus call. The Delphi 2006+ call for it is .queue, but
that is still unimplemented in FPC.
In fact Delphi implements TThread.Queue. while Lazarus/FPC currently don't.
The LCL provides Application.QueueAsyncCall.
Both procedu
On 08/24/2011 10:46 AM, Felipe Monteiro de Carvalho wrote:
I was talking mostly about PostMessage and QueueAsync. I had a vague
memory about Synchronize requiring something from lcl-interfaces, but
now I did a search here and it seams that the only thing that
lcl-interfaces need to do for it is t
On 08/24/2011 10:12 AM, Marco van de Voort wrote:
Strange, I always thought tthreads was in classes, with the primary
checksynchronize in sysutils?
Yep, but "TThread.Synchronize" interfaces to the Widget Type (aka
"Interface") code that is used by "TApplication" and when compiling
selected acc
On 08/23/2011 09:10 PM, Marco van de Voort wrote:
None of those are widgetset features, since they are non visual.
It would be great if they were not. But in fact regarding the way they
are (or maybe even need to be) implemented, they are.
(btw.: TTimer is not visual as well and it is in this
On 08/23/2011 03:34 PM, Felipe Monteiro de Carvalho wrote:
Please add to "Status of features on each widgetset"
OK, I'll try to do this tomorrow.
And please also create test projects for those and send to the bug
tracker. I think it would be good to start linking each item in those
tables to a
On 08/23/2011 12:56 PM, Graeme Geldenhuys wrote:
[http://wiki.freepascal.org/Roadmap],
Would anybody mind me adding TApplication.QueuAsyncCall,
TThread.Synchronize, and PostMessage to the "Status of native controls
on each widgetset" list ?
-Michael
--
___
On 08/22/2011 05:54 PM, Luiz Americo Pereira Camara wrote:
On 22/8/2011 07:38, ik wrote:
http://sourceforge.net/projects/becape/
Looks great (on the first glance).
Anyway, I do prefer an incremental backup system that does not need a
dedicated tool for restoring. A GUI tool for the backup is
On 08/22/2011 02:23 PM, Marco van de Voort wrote:
There are windows versions too, and there is http://librsync.sourceforge.net/
Even the better ...
But rsync relies on hardlinks. I do know that recent versions of NTFS do
support links, but I am not sure about the features.
I do know that rsy
On 08/22/2011 12:38 PM, ik wrote:
To manage things in a more easy way.
Dirvish is _very_ easy. And the advantage of rsync is that it does an
incremental backup without the need for any restore tool. A file browser
just works for this
Even a daemon for automated backups with rsync is good.
Yo
On 08/21/2011 07:30 PM, ik wrote:
Hi,
Does any of you know of a good backup system written using
FPC/Lazarus, working inside Linux and open source ?
Why would you want this ? In most cases rsync does a perfect job. Doing
rsync with the help of Dirvish performs the backup perfectly automatic.
On 08/19/2011 09:48 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
OK. My impression that each TApplication instance needs it's own
thread to work decently.
Sorry, I don't understand that whole discussion
IMHO both kinds of "Shared Object GUI" might be us
On 08/19/2011 01:53 PM, David W Noon wrote:
The 2011 C++ standard does not, but GCC and a few other compilers offer
a facility called OpenMP that parallelises loops; it works for C, C++
and FORTRAN, at least within GCC.
I do know about OpenMP and I seem to remember that there is an article
abou
On 08/19/2011 01:45 PM, Juan Sánchez wrote:
Yes, they've got different hex values both in main an dll.
IMHO this proves that the complete static memory of the LCL is
duplicated. So in fact it should be possible to overcome the fact that
"the LCL is not reentrant" and have the Shared Object cre
1201 - 1300 of 2156 matches
Mail list logo
