On 04/25/2014 07:35 PM, Sandro Cumerlato wrote:
SendMessage(Memo1.Handle, EM_LINESCROLL, 0, Memo1.Lines.Count);
AFAIK, this is a Windows-only option that does not work cross-platform
(and hence should not be recommended). OTOH, I don't know a better one
:-( .
-Michael
--
On 04/24/2014 12:05 PM, Hans-Peter Diettrich wrote:
I don't see how and why somebody would use such a framework, as long
as no component library (like LCL) is implemented for it. Using the
LCL requires that the components are of the basic types (TComponent,
TControl, TCustomForm...).
On 04/21/2014 12:49 PM, Felipe Monteiro de Carvalho wrote:
On Sat, Apr 19, 2014 at 4:07 PM, Luca Olivetti l...@wetron.es wrote:
BTW, the name of the unit isn't really meaningful (NowUTC and
GetTickCount64, the only 2 functions defined in that unit, don't seem to
have any relation with utf8).
On 04/10/2014 07:33 PM, Martin Frb wrote:
Look at the log, if you see the -exec-... and the work then all is ok.
I have the ARM machine in question (a topless QNAP NAS) at home and
will try to make sense of this during the weekend.
BTW.:
In fact the helpful person from Austria did start to
On 04/10/2014 05:30 PM, Martin Frb wrote:
So I will not add those gdb/gdbserver myself.
I do not know, if anyone else wants to work on that.
I did try (see the other mail).
Also which installer should they be added to?
I suppose you mean installer for Lazarus ?
The only installer which does
On 04/09/2014 06:27 PM, Bernd Mueller wrote:
I stepped through the program until the problem occurred and hit then
pause. As far as I could see, nothing happened. Then I hit stop.
I once was told that with using gdbserver, Pause (while not hitting a
breakpoint) is not possible.
That is
On 04/10/2014 03:30 PM, Martin Frb wrote:
The IDE ssh debugger, can not pause the app either.
I don't understand why this should be the case.
Manually using gdb via ssh (to bash) can do it, So why should the IDE
not be able to ? (Or does - when in non-remote mode - the IDE really
send a
On 04/10/2014 05:06 PM, Michael Schnell wrote:
Manually using gdb via ssh (to bash) can do it, So why should the IDE
not be able to ? (Or does - when in non-remote mode - the IDE really
send a SigInt *directly* to the application and not via the debugger )
Hum.
Re-Thinking:
When manually
On 04/10/2014 03:30 PM, Martin Frb wrote:
On 10/04/2014 14:14, Michael Schnell wrote:
Moreover I found that, with an embedded target, finding or creating a
normal gdb might be a lot easier that finding or creating the cross
gdb (running on PC but understanding the Target's files) plus
On 04/10/2014 05:14 PM, Martin Frb wrote:
Or do you have another way?
A wild Idea might be to open two SSH sessions: one for gdb (maybe in
sync mode of this makes sense), and another that just accesses a little
SIGINTServer application that is used to send the signal when appropriate..
On 04/10/2014 05:33 PM, Martin Frb wrote:
That would work. (and I would accept a patch (adding an option / not
making it mandatory)
Sounds nice to me, especially regarding that gdbserver is not that
common and hence not easily to come by in some cases.
But at this stage, I prefer the
On 04/06/2014 09:50 PM, Marc Santhoff wrote:
floating
Bells ringing Firemonkey :-) ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 04/02/2014 10:53 PM, Roberto P. wrote:
I'd like to point out that CPortLaz is multithreaded
Does it work similar to AsyncPro ?
In fact, IMHO, it would be desirable to have a component that
_internally_ uses TThread to handle blocking ports (either using just a
byte-FIDO - this is what
On 04/03/2014 12:53 PM, Mark Morgan Lloyd wrote:
I think the two would need to be designed together, even if in
practice one was coded first.
In fact I am planning to do a NoGUI WidgetType some day (hopefully
soon), and since some time I do know how this in fact can be done.
Unfortunately
On 03/31/2014 07:51 PM, Flávio Etrusco wrote:
TTimer in Windows (and the basic timer support in Windows ) is
implemented using window messages and you're not allowing the app to
process messages inside your loop.
This necessity is not limited to Windows nor to TTimer.
Any Object Pascal
On 03/31/2014 01:44 AM, Bob Axtell wrote:
can someone show a newbie how to use the two system timers?
What do you mean by system timers ?
In a normal GUI based application you normally use TTimer for time-based
actions.
You easily can create as many TTimers as you like (as well visually
On 03/19/2014 12:53 AM, Hans-Peter Diettrich wrote:
This queue may be unusable for LCL messages (dunno).
It _is_ used for the said purpose, simply because the TThread class is
provided by the fpc RTL (not the LCL) and here it can't do other but
feed the Queue in the RTL. And this obviously
On 03/18/2014 05:52 PM, Joao Morais wrote:
I missed the async part, sorry. What about reuse App.QueueAsyncCall
with interface?
Combining the Interface idea with asynchronous signaling in fact is a
nice idea.
The real issue is that in many cases you need to queue not only the call
but the
On 03/19/2014 02:04 AM, Hans-Peter Diettrich wrote:
For Windows applications you should eventually know some bits about
the main thread message queue.
Not really, as LCL and RTL provide as well TThread.Queue and
Application.QueueAsyncCall in Windows and Linux (and Mac, AFAIK). In
Delphi you
On 03/19/2014 01:00 PM, Martin Schreiber wrote:
Maybe have a look how it is done in MSEgui with
tmseevent/tobjectevent, application.postevent() and friends? IIRC you
already played with them?
:-) :-) :-)
Yep ! I do like this stuff !
On behalf of OS and Widget-Set independent and user
On 03/17/2014 11:22 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
This is a Windowish left-over and really alien regarding the
OS-independent making of the LCL (even though In fact the LCL even
simulates PostMessage in Linux.
How would you handle keyboard and mouse input
On 03/17/2014 10:38 PM, Sven Barth wrote:
Am 17.03.2014 19:15 schrieb Hans-Peter Diettrich
drdiettri...@aol.com mailto:drdiettri...@aol.com:
How would you handle keyboard and mouse input and painting in an
application?
Like any other widgetset which does know nothing about PostMessage
On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote:
The LCL is based on the message queue, regardless of any OS or
widgetset. PostMessage is part of the message queue.
Yep. (Even though I prefer the term Event Queue as the queued
information this is not necessarily similar to Windowish
On 03/18/2014 02:13 PM, Hans-Peter Diettrich wrote:
Then try to explain how e.g. a key or button press event is processed
in your model.
I don't have a model. I just tried to describe what the LCL does.
You can see the multiple Queues in the source code:
- Queue in the fpc RTL that is fed
On 03/15/2014 08:10 AM, Richard Mace wrote:
Hi All,
I have never written a console app and was wondering 2 things.
Firstly, if I was to write an app that doesn't require a GUI, that
runs on both Windows and Linux (with no XServer) is that classed as a
console app?
And secondly, is it fairly
On 03/16/2014 02:47 AM, Marcos Douglas wrote:
Like all Windows programmer, I use PostMessage/SendMessage a lot.
Lazarus team has created Application.QueueAsyncCall method to
substitute the (old) Windowish method todo async calls aka
PostMessage.
Ok. But what is the best way to use
On 03/16/2014 09:23 AM, zeljko wrote:
Why you must substitute PostMessage ?
This is a Windowish left-over and really alien regarding the
OS-independent making of the LCL (even though In fact the LCL even
simulates PostMessage in Linux.
-Michael
--
On 03/17/2014 11:04 AM, Bart wrote:
The NoGUI WS doesn't allow this?
No. It does not provide an Event Queue for the main thread.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 03/17/2014 11:14 AM, Mattias Gaertner wrote:
Feel free to add it.
It's not as impossible as I initially thought, as the fpc RTL already
provides the basic Queue implantation that can be used (while all other
active Widget Types use a queue provided by the GUI infrastructure
they attach
On 03/17/2014 11:03 AM, zeljko wrote:
No, I'll keep using QueueAsyncCall as it is because it satisfies my
needs.
I am with you, as QueueAsyncCall additionally provides queuing a
parameter for the procedure to be called in the main thread.
-Michael
--
On 03/17/2014 01:31 PM, Marcos Douglas wrote:
Yes, but the QueueAsyncCall needs to know what procedure to call for a
especific object (instance)
I don't understand.
The definition of the function (I use) is
procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent;
Data: PtrInt);
On 03/17/2014 03:36 PM, Marcos Douglas wrote:
The pointer to the Event Procedure, the self pointer of it's instance
(both denoted by AMethod) and the pointer to the parameter to have it
called with (denoted byData are queued and when the main thread is
ready to handle the event, it calls
On 03/17/2014 04:09 PM, Michael Schnell wrote:
If you meant the self pointer of AMethod, I of course am with you (as
same is a procedure of object).
But that is rather trivial, and AMethod could be a procedure of any
class (inducing but not forcing the TThread instance that schedules
On 03/17/2014 04:20 PM, Michael Schnell wrote:
I'm not sure if you simply can do free; as the last instruction
before returning from the procedure.
I just did a test and even this seems to work: An object seemingly can
free itself and return to the caller of the function just
On 03/17/2014 05:42 PM, Marcos Douglas wrote:
Could you send the sources of this test?
I could if you are interested.
This is a testing project I did for the development of Widget Types
(with and without GUI Binding) on behalf of TThread.Synchronize,
TThread.Queue,
On 03/12/2014 07:08 PM, silvioprog wrote:
It is not hard to allow chars like ã, Ã, ñ, Ñ, ç, Ç, ä,
Ä etc. I left the function a little faster too:
These beasts in UTF-8 are not char s (but multi-Byte codes) so your
example code c: char ... will not work :-( .
-Michael
--
On 03/12/2014 02:53 PM, Richard Mace wrote:
I am trying to check to make sure the a string contains at least 1
uppercase character, 1 lowercase character and 1 number.
Any ideas as of the best way of coding this?
When using Unicode (under the hood) this is really difficult, as (AFAIK)
there is
On 03/06/2014 08:31 PM, Chavoux Luyt wrote:
Years ago I used Delphi (on Windows) to access a C or C++ API
You can't access a C++ API.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
Good news from Jy V
Original Message
Subject:Re: fpcup first native build working
Date: Thu, 20 Feb 2014 16:49:55 +0100
From: Jy V jyv...@gmail.com
To: Reinier Olislagers reinierolislag...@gmail.com, Michel Catudal
mcatu...@comcast.net, Michael Schnell mschn
On 02/18/2014 10:40 PM, Graeme Geldenhuys wrote:
Simply run:
docview file1+file2+file_n
or
docview path_to_INF_docs
or
docview ENV_variable_of_path_or_files
I was trying o use Docview integrated in in the Lazarus IDE. This is
fact worked rather nicely with multiple files. I seem to
On 02/13/2014 02:37 PM, Andrew Brunner wrote:
Chrome is by far the most widely versatile. FireFox did not spring
for MP3 licensing. Firefox requires streams as ogg.
For Videos I do on on Websites I now use HTM5 with both mp4 and ogg.
With that most browsers are happy (but not the old IE that
On 02/12/2014 10:36 PM, duilio foschi wrote:
video width=320 height=240 controls
This requires the browser to support HTML5 (nowadays most do)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/10/2014 09:19 PM, Graeme Geldenhuys wrote:
Yes, simply use DocView ...
Been there. Loved it.
But I never was able to generate the files for DocView from the current
revisions of the SVNs.
(Here, multiple files are necessary (language definition,. RTL, LCL,
Help on Help you name
On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote:
Window managers do not care about widgets,,,
So maybe I am confused about the term Window Manager (I think I did
not introduce it here)
-Michael
--
___
Lazarus mailing list
On 02/06/2014 05:39 PM, Mark Morgan Lloyd wrote:
OK, so assuming an OS similar to X, can a single app support two forms
on different displays, and/or move forms between displays? Because if
it could, one of those displays could be a local X session and the
other could be something like a VNC
On 02/07/2014 03:57 AM, Hans-Peter Diettrich wrote:
fill their video buffer,
This only sounds appropriate for pixel graphics, not for the complex
stuff widgets create and that result in object descriptions that are
rendered by the processor in the video adapter.
-Michael
--
On 02/07/2014 12:51 PM, William Oliveira Ferreira wrote:
KZDesktop could be followed by here...
http://www.raphaelz.com.br/page/KZDesktop-Uma-interface-robusta-para-seu-Lazarus!.aspx
http://www.raphaelz.com.br/page/KZDesktop-Uma-interface-robusta-para-seu-Lazarus%21.aspx
IMHO, non-English
On 02/07/2014 03:20 PM, William Oliveira Ferreira wrote:
But it's a brazillian project...
I know that its Portuguese. (I use to play keyboards in a band with a
Brazilian singer)
But I don't understand a word nonetheless
-Michael
--
___
Lazarus
On 02/05/2014 11:57 AM, Michael Schnell wrote:
by an xxx- WidgetType / xxx = one of ExtJS, JQuery, qooxdoo or dojo
(or whatever the hype is these days). :-)
By this, the application programmer would be enabled to switch between
the hype of the day java script tools by clicking a setting
On 02/05/2014 07:37 PM, Reimar Grabowski wrote:
OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus
and fpc and do everything in ASM.
And loose your job for missing deadline after deadline. ;)
...
What I meant by the sarcasm is: Even if there are other ways to reach a
On 02/06/2014 11:54 AM, Reimar Grabowski wrote:
You see that as shortcomings. Most others (even widgetset developers) see
thread-safe GUIs as nonsense without real benefit, else they would be available.
I think we can agreee to disagree.
This is a funny opinion indeed.
- we did a project in
On 02/06/2014 01:21 PM, Reimar Grabowski wrote:
So a gain for a small amount of apps but a lot of work to support the solution.
Correct, but this is not the definition of not being a shortcoming.
Currently there are other options but you do not want to use them. Your choice.
Can't you read ?
On 02/06/2014 02:13 PM, Hans-Peter Diettrich wrote:
When an application relies on high speed updates, it should serialize
these requests itself, as required, instead of leaving this to the
desktop manager and its arbitrary request scheduling.
Once again, this is not about serializing requests
On 02/06/2014 04:17 PM, Mark Morgan Lloyd wrote:
I think that the only thing remotely worth pursuing, bearing in mind
the current state of widget sets etc
I don't suppose this makes much sense unless the infrastructure called
by the LCL supports it in a proven way.
OTOH:
In the other
On 02/04/2014 07:10 PM, Hans-Peter Diettrich wrote:
Right, nobody tries to support threads in GUI related libraries,
because this doesn't make sense.
IMHO it does make sense in certain applications.
The one my colleagues did is a user interfaces application for a huge
(including many PCs
On 02/04/2014 03:19 PM, Mark Morgan Lloyd wrote:
I'm not unreservedly siding with MichaelS's position, since unless it
completely bypassed any existing widget set (and preferably drew
directly to the framebuffer) it could be screwed at any time by
off-project developers (i.e. the Gnome, Qt or
On 02/04/2014 03:42 PM, Michael Van Canneyt wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There
is therefor no need to have it refreshed in intervals that the brain
cannot discern anyway. What
On 02/04/2014 04:02 PM, Mark Morgan Lloyd wrote:
I'm afraid that's... highly questionable. The more video streams
(etc.) that are visible the smoother you want the overall presentation
to be: the human brain is /very/ sensitive to small timing differences.
Yep.
We don't do such systems, but
On 02/04/2014 04:02 PM, Reimar Grabowski wrote:
You can talk to the GPU from different threads (with a little
overhead) but you actually gain nothing, because of how the drivers work.
Very wrong, IMHO.
There is a lot to do for the CPU between the user programmer's code
calls an Language RTL-
On 02/04/2014 04:20 PM, Reimar Grabowski wrote:
It is not unusual to show the same frame three times to bring the
framerate up to 72fps to reduce the black screen time which will be
percieved as flickering. Motion blur helps a lot to make the
experience 'smooth'. Why do you think it is
On 02/04/2014 03:48 PM, Sven Barth wrote:
When you call a method of a widget that results in some GUI related
stuff Qt checks the current thread ID against the thread ID the
QApplication was created in (or more precisely: the thread ID the
event loop is running in) using an Assert. While there
On 02/04/2014 03:11 PM, Michael Van Canneyt wrote:
Exactly:
you can perfectly collect 20 stills and display a composed view of all
20 stills,
10 times a second. Should be perfectly in reach of a single thread.
Sounds correct on the first sight, but my colleagues found that this was
not good
On 02/05/2014 08:58 AM, Michael Van Canneyt wrote:
I have succesfully developed such (big) projects in Lazarus:
Server side is Lazarus (more specific: fcl-web and the
webdata/json-rpc modules)
Client side is ExtJS - but JQuery, qooxdoo or dojo (or whatever the
hype is these days) would work
On 02/05/2014 10:51 AM, Michael Van Canneyt wrote:
Judging by your explanation to Dido, it seems you must explain your
users the limits of their own brains. Adding monitors and indicators
does not
guarantee that they will process more info :)
Please see the discussion on surveillance camera
On 02/05/2014 11:40 AM, Mark Morgan Lloyd wrote:
I think a realistic question is how close can multiple threads get to
a form without fouling up the LCL or widget set.
Yep !
Seemingly not doable at the moment. The LCL _could_ be updated to be
reentrant, but if the Widget Set it binds to does
On 02/05/2014 12:15 PM, Reimar Grabowski wrote:
Talk to the driver directly ...
OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus
and fpc and do everything in ASM.
But in fact Lazarus is more fun :-) .
-Michael
--
___
On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote:
Then you have to include appropriate hardware, where multiple GPUs are
preferable to multiple CPUs when it comes to processing multiple video
streams concurrently.
In fact the system runs just fine for multiple customers right now with
many
On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote:
Please note that even a CPU with multiple cores doesn't have multiple
data busses for the cores. That's the narrowest bottleneck, which
limits the throughput on every standard machine.
Right, But this is why 1st Level cache has been invented
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
(And I learned that in fact XInitThreads() can be called in
On 02/04/2014 11:12 AM, Michael Van Canneyt wrote:
It kind of defeats the purpose, as it suggests that only 1 thread at a
time can access the display.
Of course concentrating the GUI stuff to a single thread makes things a
lot easier to handle.
But I already did explain the purpose I (once)
BTW.:
What we did to take advantage of the multicore architecture in fact was
creating multiple applications, each of which handles such a GUI element
in a dedicated Window that is automatically placed at the appropriate
location above the main window. But of course the overhead for
managing
On 02/04/2014 11:36 AM, Mark Morgan Lloyd wrote:
At that point why not bite the bullet and exploit GPU parallelism?
Yep ! :-)
(And this hint is going out to whom ? ;-) )
KDE and Qt are minor issues, far more significant is arbitrary
restrictions that GTK imposes because they envisage some
On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote:
Right, and the restriction to one widgetset resides in the Lazarus
widgetset handling.
I do know. But it does not make much sense to be nagging towards the
powers here about LCL not being reentrant, if the library (Widget Set,
...) it
On 02/04/2014 11:57 AM, Hans-Peter Diettrich wrote:
I've just visited the German Wikipedia page for Pascal, and found it
in questionable state, too.
+1
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as
well. Certain events like rendering are also checked for the thread ID.
While I don't exactly see the point (as
On 02/04/2014 02:40 PM, Michael Van Canneyt wrote:
I play a video at full HD, 1 thread handles the screen display. It
works just fine,
Playing two videos at the same time does make sense in some applications
(we create 20 small videos in our application to have the user see
what the system
On 01/17/2014 06:25 PM, Sven Barth wrote:
Wouldn't help much, because e.g. Qt does not allow usage of GUI
widgets in multiple threads.
http://qt-project.org/doc/qt-4.8/threads.html
I did not thoroughly read this but it seems that QT is thread-aware
-Michael
--
On 01/20/2014 11:10 AM, Sven Barth wrote:
Trust me, I'm currently working with Qt's internals as I've just
finished the port of Qt to my company's OS, so I know what I'm talking
about... (and I've already hit an assertion regarding this)
I see.
In fact I already came across applications
On 01/20/2014 11:01 AM, Michael Van Canneyt wrote:
http://qt-project.org/doc/qt-4.8/threads-starting.html
Note that QCoreApplication::exec() must always be called from the
main thread
(the thread that executes main()), not from a QThread. In GUI
applications,
the main thread is also
On 01/17/2014 01:25 PM, Marcos Douglas wrote:
is better not use global variables in the DLL.
Of course I agree.
A reason for using global variables in a DLL might be to access that
value as well in the DLL as in the main program.
Is this even possible ?
(To allow for this loading the DLL
On 01/17/2014 03:06 PM, Marcos Douglas wrote:
But why do you need a global var in the DLL? IMHO (and for many
programmers around the world), global var is not good, even in the
application code.
I don't suppose I'll ever want to do this. :-) - I just was being nosy.
-Michael
--
On 01/17/2014 05:47 PM, Marcos Douglas wrote:
I said: IMHO, not only programmers around the world... so, for me is
not a received wisdom, but a lesson learned. ;-)
Unfortunately Lazarus uses global variables in the LCL. Otherwise it
would be possible to create a project with a TApplication
On 01/13/2014 01:18 PM, Dimitrios Chr. Ioannidis wrote:
Windows 7 64bit
Compiling lazaruspackageintf.pas
PPU Loading
C:\Users\dimitris\Programming\Tools\fpc\2.6.x\units\i386-win32\fcl-e
xtra\ServiceManager.ppu
PPU Source: ServiceManager.pas not found
Recompiling ServiceManager, checksum
On 01/07/2014 06:11 PM, Mark Morgan Lloyd wrote:
IMHO, the Pascal way of handling such task is using a thread.
That's in the main code, not a background thread, and I have good
reasons for wanting to do it like that.
OK. There are decent reasons in certain projects. But Generally the
So this seems to be a project that can be done in a no-GUI way by
manually calling *CheckSynchronize* and implementing *WakeMainThread*,
so that the event queue can be managed and feed the queue by
TThread.Synchronize and/or TThread.Queue.
Let us know when you get it working.
-Michael
--
On 12/28/2013 10:07 PM, Mark Morgan Lloyd wrote:
Thanks, I'm reading stdin directly with a tight timeout using fpselect
so it sounds like I should be able to manage something.
This of course requests for a multithreaded application. (i.e. the
threads that handle the blocking pipes
On 01/05/2014 02:44 AM, Bart wrote:
such as the everlasting Unicode debates,
I feel that main causes of these debates are (1) that the definitions in
DXE are not nice (at least completely ignoring any portability issues),
but fpc/Lazarus is forced to follow rather closely whatever Delphi
On 01/07/2014 02:05 PM, Marc Santhoff wrote:
Graeme G. once posted the source of or a link to a unit called
ThreadTimer, in which there is TfpTimer. That one is independant
from LCL.
Unfortunately it only helps if thread communication (e.g. by
TThread.Queue) is used to notify the main thread).
On 01/07/2014 02:22 PM, Michael Van Canneyt wrote:
I think you misunderstand TThread.Queue. It does not notify the main
thread.
Yes it does (from the view of the user), when the environment is
decently crafted (in fact it does the same as TThread.synchronize only
that the thread does not wait
On 01/07/2014 04:16 PM, Paul Breneman wrote:
So please share what you can. Thanks!
Right now I am too busy with completely unrelated things to do the
planned active NoGui Widget Type :-( .
I just can provide some thoughts and offer to reply to any questions if
anybody wants to get on
On 01/07/2014 04:25 PM, Mark Morgan Lloyd wrote:
The OP, i.e. I, did not mention doing any I/O in threads.
He said: I'm reading stdin directly with a tight timeout
IMHO, the Pascal way of handling such task is using a thread.
-Michael
--
___
On 12/20/2013 07:22 AM, Juha Manninen wrote:
When Unicode is mentioned, usually people start to argue about how
it SHOULD be done.
:-) :-) :-)
Especially because the big boss Delphi does not provide a really good
model to go for. Delphi String handling is done with UTF16 (using other
On 12/02/2013 06:43 PM, waldo kitty wrote:
On 12/2/2013 4:06 AM, Michael Schnell wrote:
If your effort allows for compiling pascal to Java Script this might
be even
do you mean java or javascript above? ;)
Michael v.C. said:
That is exactly my plan: 1. Convert pascal to javascript
On 11/30/2013 09:08 AM, Martin Schreiber wrote: ...
If course I do remember very well, how ifi works. For me, it is a really
great idea to decently physically separate the business logic from the
GUI without completely loosing the RAD features Delphi, Lazarus and
mseGUI provide. At best you
On 11/29/2013 11:22 PM, Dariusz Mazur wrote:
Could You mention this problems?
I did not do tests myself, but when researching I was told that some Web
servers would kill the connection to the client and/or the fast-cgi and
would not recover decently.
At that time I did not know about
On 12/01/2013 04:57 PM, vfclists . wrote:
Are there some industry standards for specifying GUIs in JSON?
See Future of the Desktop right here.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 11/30/2013 01:44 PM, vfclists . wrote:
The 'desktop' for Delphi developers where many FreePascal come from
basically means Microsoft.
AFAIK, the mother of the Desktop is X11, which IIRC was invented by
Xerox (for headless Unix boxes).
Using the siblings of same, we now have KDE and
On 11/30/2013 01:38 PM, Michael Van Canneyt wrote:
Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all.
A really scalable solution would have to provide both:
- just compile the normal Lazarus / mseGUI based
On 11/30/2013 02:24 PM, Andrew Brunner wrote:
The more server off-loading the better.
This was the idea behind Silverlight.
But seemingly Silverlight is not actively supported any more, which IMHO
makes the idea of C# / CIL / .net rather senseless (obsolete).
-Michael
--
On 11/30/2013 04:28 PM, Michael Van Canneyt wrote:
Easy:
Because of all the advantages that Pascal has over the mess that
Javascript is.
+1
(so your idea would be a nice option to do javascript stuff even with no
gui actions involved)
The inventors of Javascript should be publicly
501 - 600 of 1996 matches
Mail list logo
