[Lazarus] Synedit Highligter: hide found character sequence
Hi SynEdit Experts, Doing a special kind of text editor (that in fact needs to feature an invisible signature for each word in the text): Is it possible to do a highlighter that results in hiding the character sequences found by the highlighting criterion (in fact on screen replaces it by a blank) ? Can we do software that with a cursor move event gets/finds the word under cursor plus the invisible "highlighted" string before that word ? Can the highlighted / invisible character sequence be protected from being modified by the user's text editing actions ? Is there a way to wrap the (visible) text to a predefined line length (using the usual line breaks as paragraph indicator) ? If such features are not available does it make sense to do a local fork of SynEdit to implement such options or would a different implementation be more viable ? Thanks for any comments ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Synedit tab
I tried to open an old project I once started to test using SynEdit. It does compile and work, but when trying to see the form I get an messages of not installed components. In fact the "sysEdit" tab that is described in the Wiki is not seen in the Lazarus IDE. How to activate it ? Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Synedit tab
On 06.02.2017 11:30, Ondrej Pokorny via Lazarus wrote: Check if you installed syneditdsgn package. In the "Install/Uninstall Packages" menu in the "Installed" Window there is "SynEditDsgn". But other than "SynEdit 1.0" same features a small green "+". No Idea if this is an error indication. In the "Package Info" it nonetheless says "not installed" (contradicting to it's being listed as "installed" ). Doing "use" in the "open installed packages did the trick: now the SynEdit tab is shown. :-) (Regarding Packages there seems to be some ambiguity with "installed" "used" and "loaded". ) Thanks a lot ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Synedit tab
On 06.02.2017 13:55, Mattias Gaertner via Lazarus wrote: The dialog is simple: left side will be installed. Yep. But if there are some that have a green cross (meaning "known" but not used/intstalled, as said SynEditDsgn claims: "Current state: selected for installation, not installed, RunAndDesignTime" ) the "save and rebuild" button is deactivated and so I can't make them "used" (or installed) in this dialog. (BTW.: this situation is triggered by "make clean all" for Lazarus.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Running an app on boot
On 25.01.2017 11:40, Ed Murashie via Lazarus wrote: No matter what I try I get “ Gtk-WARNING **: cannot open display: “. This also happen on a Beaglebone What am I doing wrong and how can I fix it? Do you *want* a GUI ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 15.01.2017 15:30, Martin Vahi via Lazarus wrote: have came to a conclusion that GUI-s are inherently something that require "dynamic programming" or the code gets really bloated. The nice thing about Lazarus "RAD" paradigm is that this is completely hidden (in the library) from application programmer. So (s)he only needs to write the code that is obviously useful for the task at hand. So adding a GUI for the single purpose of debugging / visualizing the application code makes a lot of sense. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to fpWeb...
On 14.01.2017 15:34, Marcos Douglas B. Santos via Lazarus wrote: I'm feeling we've started to go ahead writing complex Web systems Does fpweb / weblaz already support status messages from the server to the client (or will it some day) to allow for "Rich Web Applications") ? Thanks Michael and all those who have been contributing for these new features. +1 !!! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 16.01.2017 21:24, Lars via Lazarus wrote: Except when you find a bug in the lcl, and have to dig in to it.. I don't suppose Lazrus is so bad that it can't be used for the simple programs the students will start with when learning programming :-):-):-). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to fpWeb...
On 16.01.2017 20:19, Daniel Gaspary wrote: Can you give examples of these messages? And who (nginx, apache..?) and how they are implemented? In fact I can't, either, that is why I ask. I do know that there are several frameworks that support this by running rather complex Java script on the Client. (For Pascal there once was EXTPascal, but AFAIK, the project has died. ) AFAIK there are several "standard" ways to use a HTTP connection via a HTTP server in reverse direction, including polling by Java script, holding a connection open for an extended amount of time and using an additional TCP/IP socket. (I seem to remember names like "Comet" or "WebSocket". "WebAssembler" might be a future extension to this, in future potentially allowing to run projects created from Pascal code directly in the browser.) It would be nice to have a package Lazarus that supports such things. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to fpWeb...
On 16.01.2017 21:59, Leonardo M. Ramé via Lazarus wrote: The only framework I'm aware of implementing it is m0rm0t. What do you mean by "The only" ? The only at all (I suppose that there are several of those) or the only that explicitly supports pascal / fpc / Lazarus. (I don't know any at all). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to fpWeb...
On 17.01.2017 10:27, Michael Van Canneyt wrote: There is. Look for bauglirwebsocket. It implements the websocket protocol. That is good to know ! Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to fpWeb...
On 16.01.2017 22:21, Lars via Lazarus wrote: What is the exact name of it... couldn't find it: http://blog.synopse.info/category/Open-Source-Projects/mORMot-Framework -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 17.01.2017 10:22, Graeme Geldenhuys via Lazarus wrote: Yes, Delphi's VCL is a wrapper around the common Win32 widgets. LCL is a wrapper around Win32, Qt, Cocoa, Carbon and even fpGUI. And for ease of use as well Delphi as Lazarus come with an IDE that is a combination of source code editor, debugger, compiler controller and *GUI Designer*. Making the use of a simple GUI extremely easy (introducing and suggesting the (dreaded) RAD paradigm. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
On 05.10.2016 12:40, Ondrej Pokorny via Lazarus wrote: I am against. LCL is designed to be Delphi-compatible so the default events are what they are and they behave how they behave. This of course is granted by a property that is not existing in Delphi and defaults to the Delphi behavior. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Messages from who?
On 01.10.2016 14:01, DougC via Lazarus wrote: The FROM field is always the list, itself, now. Seems like a good idea. While Thunderbird has a dedicated "Reply to list" button (which I sometimes failed to hit :-( ), some other mail clients might only allow for "Reply" (unless you want multiple recipients). Now this "reply to sender only" does what is appropriate. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] WebAssembly
(Creating a new thread instead of using "Help System with Chromium Embedded component") On 09.11.2016 05:38, Lars via Lazarus wrote: On Tue, November 8, 2016 3:49 am, Michael Schnell via Lazarus wrote: On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: I seriously doubt that. It's just something that will exist next to javascript but in essence will perform the same tasks as javascript. ==OFF TOPIC== (so ignore if there is not a very short answer) Any plans for a webassembly support with FPC ? There is an old thread about it here: http://forum.lazarus.freepascal.org/index.php/topic,28836.0.html Many skeptics, but many think it is an interesting idea even though skeptical. And what happened to microsoft silverlight? did anyone care? IMHO Silverlight is dying because Java is the winner over C#, due to Android systems outselling any other OS architecture. Hence WebASM - that seems to be based on Java - might be successful in pushing the idea of allowing for precompiled byte code embedded in HTML. Regarding fpc/Lazarus, it obviously would be a huge benefit if on top of fpc's WebAdmin support, the LCL would provide decent support for an appropriate WidgetType that allows to simply cross-compile a "usual" Lazarus project to be runnable in a browser. The "WEB-LCL"code would need to access the Browser's "GUI" infrastructure using the appropriate API (supposedly defined as a part of the WebASM specs), in a way as compatible as possible to the other WidgetTypes (such as "Win32" or "GTK2"). Of course a "WEB-LCL" and "WEB-RTL" (dynamic Web-linkable) WEBASM files needs to be provided on a server and the project resources need to be embedded somehow. As a further extension, "in depth" support for communicating (using WebSocket) between the parts of a dual-issue application, one part running in native code on the Server "behind" the WebServer, one part running in the browser, would be very appropriate. (Doing a single "application" and seamlessly distributing it in that way had always been a promise of Silverlight's.) This is a great opportunity to beat Embarcadero :-):-):-) Michael (just dreaming) -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] WebAssembly
-> https://hacks.mozilla.org/2016/10/webassembly-browser-preview/ : However, assuming no issues are found that require substantial time to address, the WebAssembly Community Group would like to mark an initial version of the standard as “done” in Q1 2017 which would then enable browsers to start shipping WebAssembly without a flag. For our part, in Firefox, this green light would mean shipping WebAssembly in Firefox 52 (March 2017). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] WebAssembly
On 11.11.2016 02:26, Mattias Gaertner via Lazarus wrote: So it is not yet clear when it will be ready and how the end product will work on the various browsers. Mozilla promises "March 2017". Any information on other brands ? I only found "Microsoft says it is close to shipping the browser preview of WebAssembly on Microsoft Edge and ChakraCore" -> https://mspoweruser.com/microsoft-edge-get-webassembly-browser-preview-soon/ -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 17.10.2016 21:05, Lars via Lazarus wrote: The big issue with teaching using a RAD tool, is welding the program logic into the onclick events, instead of decoupling the logic in separate procedures that can be reused elsewhere. As you point out in the text this is as well a pro (easy fast solving of small unitary tasks) as a con (bad reusability, bad code when doing big projects). But as Learning of course starts with doing small unitary tasks RAD obviously is a great help to fight the FUD and prejudice the students might have regarding programming. Of course it's great to dedicate a (later) lesson to un-RAD-ing your code in order to be prepared for bigger tasks. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazmint
Seemingly "make bigide" on a 64 Bit Mint does not work this simply with the 32 bit fpc: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o when searching for /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o /usr/bin/ld: cannot find /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o /usr/bin/ld: cannot find -ldl /usr/bin/ld: cannot find -lc Error: Error while linking -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazmint
So I fetched the current fpc from svn. Trying to make same I get a similar error: Linking fpmake fpmake.pp(47,1) Warning: "crti.o" not found, this will probably cause a linking failure fpmake.pp(47,1) Warning: "crtn.o" not found, this will probably cause a linking failure /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o when searching for /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o /usr/bin/ld: cannot find /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o /usr/bin/ld: cannot find -lpthread /usr/bin/ld: cannot find -ldl /usr/bin/ld: cannot find -lc fpmake.pp(47,1) Error: Error while linking -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 13.10.2016 10:20, Graeme Geldenhuys via Lazarus wrote: +1 That would be the best solution. GUI programming is based on fundamentals than need to be understood first. -1 !! The OP explained that his main purpose is to introduce more fun in the education. That can be done by plunging into programming directly with GUI development. This is why RAD had been invented. Of course there are decent drawbacks regarding relying too much on RAD and about not really understanding the fundamentals behind it. But in the end the addressees are non-computer engineers. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 14.10.2016 00:13, Erwin van den Bosch via Lazarus wrote:
I'm not a big fan of the RAD development way any more. (I was years
ago). The problem is that you should separate your business logic and
the GUI.
This is absolutely true especially when doing large systems or
(embedded) systems that don't are tightly bundled with the GUI. But even
there using RAD for testing/debugging is a way for speed up the development.
And here the addressees are non-computer engineers who most likely will
not do large systems on their own, but just should understand what
programming means to enable them to talk decently with their colleagues
who will do the programming for appropriate projects.
So a fast way ("RAD") to do and test a rather simple working project
and understand the basics
With Delphi like RAD it's very difficult to do that. (but it is
possible) Everything is coded in events and connected to database
aware GUI controls. (In the case of a database application)
I don't think so.
With a more careful design it's absolutely possible to do "non RAD"
programs by doing "GUI units" and "business code Units" that interact
via Objects with functions, properties and events (callback-properties) .
I believe this is not more effort that using an external GUI designer.
I did this for embedded projects using the GUI units for debugging and
testing and then replacing them by dummies without needing to modify the
business code units and hence being able to start testing again at any
time, while the "GUI-stripped" executable can used on a "headless"
target system
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
Generally speaking: Getting confronted with the limits, imposed by lack of knowledge to your work to get a task done is a great motivation for learning. Being forced by the tutor to learn stuff you don't immediately need to get the task at hand done is a great motivation to give up. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 14.10.2016 16:10, Jürgen Hestermann via Lazarus wrote: In most cases they never get to the step "find out how it works". If it works, nobody wants to invest time anymore to look under the hood. So they always operate on the surface and repeat the same subobtimal programming over and over again because they don't know how to do it better. That is absolutely correct. But the point where the "knowing how it works" is just a matter of deliberate choice (or the professor, the student or the situation you get in and need to crawl deeper into the complexity of the matter.- - do I need know how/why the GUI builder creates the code that makes a Button visible on a Form and my Event handler be called when a button is pressed ? (I.e. do I need to be able to write the code myself without the help of the GUI builder ?) - do I need to know how the startup code works that make the Form visible on the screen ? - do I need to know how the Event-Queue and the checksynchronize() system works ? - do I need to know what system, calls the pascal program performs ? - do I need to know what ASM code is generated from a pascal instruction ? - do I need to know how semaphores are done by atomic instructions ? - do I need to tell the difference between CISC and RISC ? - do I need to know what microcode the CPU runs ? - do I need to know how a transistor works ? - do I need to know how dotating silicone is done ? In most cases it's better to first concentrate on the task at hand and dig deeper if necessary. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 24.10.2016 18:11, Travis Ayres via Lazarus wrote: With over 100 replies, we could have already written a course outline, introduction, ... It seems we have lost (or silenced) the OP long since :-( -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TThread.Synchronize
On 25.10.2016 13:21, LacaK via Lazarus wrote: My understanding is that, Synchronize schedules execution of MyForm.MyMethod to main thread, so method is not executed until control is returned from event handler in MyForm. Right? TThread.Synchronze pushes the procedure that is given as a parameter (including it's Self pointer) to the event queue and then the Therad that called TThread.Synchronize is stalled. Some time later the main (GUI) thread will execute the scheduled procedure. When this call returns, the thread that called TThread.Synchronize is activated. There also is TThread.Queue that works identically, only without stalling the thread. But in my case happens, that method is executed while execution of event handler does not finished yet ... is it expected behavior ? What is "that method"? If same is called by the thread after TThread.Synchronize, IMHO this can't be correct. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TThread.Synchronize
If you don't call CheckSynchronize within MyForm.MyMethod then yes. IMHO the (hardly documented) CheckSynchronize should not be called directly by an application that uses a Widget Type that features an Event Queue. Here the user should do "Application.ProcessMessages", that is decently documented. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 18.10.2016 17:16, Jürgen Hestermann via Lazarus wrote: Yes, therefore start with simple procedural (console) programs that let them have immediate success with all the elementary things that a program consists of (variables/types, loops, commands, etc.). Yep. Satisfying for a Nerd, but it does not get something useful done and hence frustrating for a beginning application developer. If you do it the other way round you only delay the date of frustration but you do not avoid it. That is true if (s)he one day will be confronted with large, complex, unusual or critical tasks. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to use strings properly with fixes_1_6 and FPC 3.0.0?
On 23.10.2016 11:31, Jürgen Hestermann via Lazarus wrote: But Unicode should have cared. It was made for its use on computers. I don't think so. I suppose it was defined top allow for printing out digital documents in mind, but not with working with them. At least this i what the outcome suggests: printing works just fine, but even trying to find out a very short information is identical is not decently possible. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 21.10.2016 11:09, Jürgen Hestermann via Lazarus wrote: What is the use of a program? Entertainment? Nowadays in 90% of the usage exactly this. Maybe other usage cases are more "important", but still the money is made with Entertainment. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to use strings properly with fixes_1_6 and FPC 3.0.0?
On 24.10.2016 13:34, Mattias Gaertner via Lazarus wrote: That depends on what you mean with "identical". You are absolutely right. Very sorry for being critical while being vague myself (again typing faster than thinking) ;) . I meant to point out exactly this ambiguity: identically coded vs. identically looking (e.g. combining codepoints), vs identical presumed letters if looking differently (ligatures), ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to use strings properly with fixes_1_6 and FPC 3.0.0?
On 24.10.2016 15:09, Mattias Gaertner via Lazarus wrote: These functions exist. This of course is great (while the lack of documentation supposedly makes them hard to use). In fact I am not asking, but the question is part of the OP's problem. And here I wanted to point out the ambiguity of the term "identical" on that behalf. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 21.10.2016 10:12, Lars via Lazarus wrote: Today's bloatware applications are so large no one can understand them IMHO, you did a good job to scare everybody away from even thinking about starting to try programming. So we should just stop "Teaching Pascal at College". -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 21.10.2016 09:51, Lars via Lazarus wrote: The concept of callbacks is very similar to events. The difference is that with a callback you usually know both sides and hence how exactly it is called, while with an event (especially when fired by the LCL on behalf of something that happens in the GUI, aka RAD) you don't need to know exactly how and why it is fired, you just place your user code in it and are happy (at least if you are not a nerd like myself). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 21.10.2016 14:05, Martin Schreiber via Lazarus wrote: Win32 API works with message queues. Happily, the application programmer does not need to know about that, as the LCL completely hides the underlying complexity. He sees the same type of "GUI"-events, independent of running on Winx (OS-introduced message queues) or Linux (Event Queues implemented by the LCL itself) (The reality is even more complex). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to use strings properly with fixes_1_6 and FPC 3.0.0?
On 21.10.2016 12:05, Gabor Boros via Lazarus wrote: 2016. 10. 21. 10:25 keltezéssel, Juha Manninen via Lazarus írta: * Please read the wiki page ... I read, I read but if contains buggy example... ;-) I need a quick and a rock solid solution. AFAIK, the only decent advice is never to use the numbers in Pos() / Length() / Copy() / Delete() for anything else tan with these functions. don't try to do any interpretation of these numbers. Never use the term "Character". -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
On 13.11.2016 21:37, Ondrej Pokorny via Lazarus wrote: On 05.10.2016 14:07, Michael Schnell via Lazarus wrote: If not set it will be the old OnChange behavior. Or they other way round: nboOldOnChange? Or do you have any other name suggestions? I suppose it will not be a Boolean but the user can select (two) options with "speaking" names describing the technical effect ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
On 15.11.2016 07:41, Ondrej Pokorny via Lazarus wrote: Then there's the problem with what behavior should be default. That supposedly can easily be defined by the general "mode" setting. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
On 16.11.2016 10:33, Ondrej Pokorny via Lazarus wrote: The mode settings have unit-scope. TPageControl/TCustomTabControl are in unit ComCtrls that is always built with objfpc mode. I see. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
On 15.11.2016 18:28, Bart via Lazarus wrote: Mode switches are about coding (how the compiler should behave), not about how components should behave once compiled. Of course I do know that they are used in that way. I just wanted to say that the Delphi compatibility modes *could* be used to define the *default* setting of this property. at compile time. Seems rather logical to me. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quad precision library for Free Pascal
On 19.11.2016 00:01, Ken Kashmarek via Lazarus wrote: Does anyone know of or have implemented a quad precision (128-bit) library for Free Pascal. I see there are some available for C or GCC but not Free Pascal directly. Your feedback is appreciated I read many threads about arbitrary precision fixed point and floating point libraries or FPC, especially in the German Lazarus Forum. Supposedly a rather "official" one is part of the Delphi Jedi project. But I would rather use a proven C library rapped in a DLL/so. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Teaching Pascal at College
On 12.10.2016 20:10, Adrian De Armas via Lazarus wrote: teach how to create rich GUI Applications and to my surprise the idea was well recieved. Now I have to make suggestions about how to prepar The GUI development in Lazarus is not "modern" at all (but IMHO a *very* decent way to do a GUI). Embarcadero Delphi changed to the "FireMonkey" GUI builder, that is intended to do a "modern" "dynamic" GUI, more suitable for mobile-trained users. Regarding building a GUI, the "RAD" paradigm seems not to to be widely accepted any more, but a dedicated GUI builder, separated from the language code, is recommended in many places, even though a lot more clumsy than Delphi-alike RAD. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] In search of a component for holding a table of strings
On 11.01.2017 15:58, Mattias Gaertner via Lazarus wrote: You need to check common cases, not uncommon IMHO it's very prone to error to deliberately define something as "common". Even if you do a decent statistic of usage cases, this can vary after some time. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] In search of a component for holding a table of strings
On 05.01.2017 18:10, Bart via Lazarus wrote: Just implemented sorting. Nice ! (Even if I don't see a straight forward understanding of two dimensional sorting). BTW.: Looking at the code I could imagine that auto-growing when using the Cell property to write an element might be appropriate. Read/Write form/to a file might be sensible. Here AFAIK, the fpc's TStringList does not yet feature setting the encoding, which Delphi does. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] In search of a component for holding a table of strings
On 06.01.2017 16:20, Bart via Lazarus wrote: That makes no sense to me, Instead of a two dimensional array of strings you could have use a single dimensional array of StringLists (a less symmetrical way, of course). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] In search of a component for holding a table of strings
On 09.01.2017 23:28, Werner Pamler via Lazarus wrote: I would be tempted to implement such a table in fpspreadsheet, but its problem is that it occupies memory for empty cells while the AVLTree stores only existing cells (at the expense of the cell record which contains row and column indexes). What about a two dimensional array of integers pointing to a one dimensional array of strings, and doing some garbage collection cells are set to empty strings ? (Maybe even identical strings can be managed...) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Zeos SQLite Linux
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 (On Linux it just shows an appropriate Error message.) So the question is to do Zeos / SQLite / Linux ? I failed to find such information yet. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
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 working in the IDE. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
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 "CustomDrawn", as this also uses Pascal Code to generate the (more complex) widgets. Such code would be translated to WebAssembly and at runtime be transferred to and then executed in the Browser in high speed. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
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... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Why lazarus is sorely needed: A plea for stability and backwards compatibility
+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) - MAC - Linux Desktop (PC / ARM / ARM64 / MIPS / ) - Linux Headless (I do have done a working draft for an "active NoGUI" Widget Type) - Android - iOS - with built-in Web Server, the GUI shown on a browser - As a Server based application (e.g. behind Apache or Microsoft IIS) with the GUI shown on a browser -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The new kid is growing up fast
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.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 use do the same. And a major tool for handling strings is TStrings and it's siblings. You hardly an avoid using same. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 type was definitely not the right choice. Notwithstanding the discussion about the mere wording, this only would hold, if the system would provide a differently named non "printable text" basic type that comes with the features needed for such usage: reference counting, lazy copy, simple operators for concatenating and element extraction and replacement, built-in function for substring locating, ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 Delphi-incompatibility. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 entities. The encoding of those varies: UTF-8, UTF-16 high byte first, UTF-16 low byte first, 64 bit low byte first, 64 bit high byte first, fpc and Delphi do support several of those as a string encoding (and with that crating any number of problems). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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 := is discussed in the paper. (Only for := there is no accessible encoding definition for the left operand.) If the encoding branding is one of those that already exist, the current definition is used. For "new" encoding brandings, such as CP_Byte, CP_Word, CP_DWord, CP_QWord, the working of the operators is obvious. It somebody tries to compare a printable Text string with a string of binary elements, maybe the behavior is undefined. There is no QWord codepage. That would be confusing. Of course the term "Codepage" Embarcadero chose for the encoding identification is misleading in this context. That is why in the said paper it's called "encoding style" (which is not a really appropriate wording, either, but hey, it's just an initial suggestion and not yet a final documentation, and it had been clear from the beginning that it's in vain, anyway. ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 aware strings at all. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 TStrings. Everything else will not provide an improvement of the class of problems under discussion since years. -Michael (knowing that this will never happen) -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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). Unfortunately in Delphi and FPC the appropriate work-alike existing type is called Char (with certain extensions). It would cause major problems to drop that name for something else, even if that would be appropriate. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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 another type of strings, which is nothing but a prerequisite for the main purpose. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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 brainlessly extended the existing "CP..." naming scheme. Your "dynamicstring" supports char, widechar, byte, word, dword, qword. Why not shortint or smallint? Why not boolean, single and variant? As pointed out this is just a draft of a proposal, prone to enhancement and improvement. What is the intention of your proposal? That is given in the instructional paragraph "The problem": "The most obvious candidate for pain on that behalf is “TStrings”. Only a fully dynamically encoded version of TStrings and friends would allow for a solution for many string encoding related problems, as the user can't modify the string encoding brand TStrings uses and hence will face the described problems when he uses TStrings with all but one of the String encoding brandings he can choose from. Enhancing the count of available encoding brandings is just a logical consequence of a less problem prone and more versatile (not implicitly restricted to printable text) overall string handling. -Michael (It's rather frustrating to discuss that obviously never will happen :-() -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 extension of the existing paradigm. I did not think about the necessity to also have a dynamically encoded Char type. If yes, it (like a string) would need the additional fields for encoding number and bytes_per_char, and the appropriate compiler magic to handle them appropriately (workalike to a on-element string). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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 TStrings (UTF-8 in fpc, UTF-16 in Delphi) implicitly triggers auto-conversion when handling the string. This has several consequences. It might be a really good idea when e.g. doing some code that in a loop needs certain operation that might be very fast with UTF-16 but TStringList would store the data in a more compact way. It might be time consuming when the conversion is done without being necessary. It might be error pone when the user stores some random stuff in the string that is not able to be handled by the conversion forth and back. In any case all this happens without the user being aware of, which might cause frustration. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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 natural enhancement. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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? Because the type for this stuff used in Delphi and and FPC is called "char". Is it possible you don't know Unicode beyond codepoints? In fact I did not explicitly talk about Unicode at all. the paper says it: "In this article, a "String" is thought of as a reference counted ordered array of a number of "Things" (aka elements). (I feel that this is what the name String suggests.)" ..."If the elements of the strings are printable characters or partial codes of UTF. OK, this is nice (provided the conversion functions are in place) and makes doing programs handling conventional problems very easy" ... Do you have plans to tackle also the complex issues of Unicode? Not at all. If not, then your efforts are useless because codeunits and codepoints are easy in any case. I know. The intention was to handle a completely different problem from that you suggest here. You use energy for a problem that does not exist. I wrote the paper because I once was requested to do so in the fpc forum. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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", as it is handled by the conversion functions the functionality of which is not touched. The paper is just about storing the information in the strings (including the "encoding brand" and "bytes per element") fields. So the actual meaning of the stuff that is stored in the strings is beyond the scope of the paper. And supposed to stay as it currently is. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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(), and friends work in terms of "bytes per element" bytes. The only difference to the current status is that with the "dynamic" string brand the content of the "bytes per element" field is not predefined by the variable declaration but can change when something is assigned to that (additional) brand of string variables (I feel that this is clearly stated in the paper). Hence for that (additional) brand of string variables the compiler needs to generate code to read this field when implementing the built-in functions. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 TStrings does not without forced auto-conversion support the string type the user is inclined to choose. This obviously requires an (additional) fully dynamic string brand. This (again obviously) is not the "Embarcadero way", but supposedly does not necessarily lead to incompatibility regarding the user code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 platforms (which E$ did not feel necessary when they released the encoding aware strings). Maybe a better solution can be found, but who would want to nudge the fpc / Lazarus developers to invest a huge amount of time to create it and then make sure it is decently tested stable ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) But I am perfectly aware that implementing this would be a huge effort (see other mail here), and nobody i entitled to ask for this. (I wrote the article just to elaborate what was discussed in the fpc mailing list at that time.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 complains in all the appropriate forums and mailing list. So not much additional harm can be done, anyway. I suggest that it should be according to the character_size definition stored S, and the operation c := S[x] should transfer the appropriate count of bits, provided the type of c allows for taking them. This seems to be compatible to the current implementation of any 1-Byte brand and UTF16. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The new kid is growing up fast
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 mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 more than a container for a character array and which should be constrained to have the same character encoding. A string should intuitively represent a string of text regardless of how many bytes are used to represent each character and with dynamic attributes to tell you how it is encoded. 4. FPC should clean up Delphi's mess for it. If a unified string type follows a consistent model then it should be possible to make all Delphi string types synonyms. You will need to allow exceptions for legacy programs that insist on manipulating the bytes themselves - but that is not rocket science. There is also the issue of the Windows API and its insistence on Wide Strings - but isn't that why calling conventions such as cdecl and stdcall exist - to tell the compiler when it needs to reformat the call for a given API convention. see -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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:
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support
-> Defining String variables and String types:
*CP_ANY* = $FF00 // ElementSize dynamically assigned // fully
dynamical String for intermediate storing string content // just
assigned to the Type or variable, never used in the "Encoding" field
in the string header.
Hence it stores the "branding" when it is assigned to from a string with
a fixed branding (such as *CP_UTF8*), and the content is auto-converted
if necessary when assigning form CP_ANY to a fixed branded string variable.
If (in your example) the data is read from a file, a CP_ANY Strings
based StringList would keep the encoding/char_size of the data as t is
in the file (it would need to somehow get to know the presumed encoding
of the file, anyway) and store that information in the
EncodingBrandNumber and ElementSize fields (which do exist in any
"NewString" variable, anyway), in each String read.
If the user assignes an element of the stringlist to a fixed branding
(such as *CP_UTF8*), the content obviously is auto-converted if
necessary when assigning form CP_ANY to a fixed branded string
variable, as usual.
In fact I suppose that the current implementation of TStringlist does
not use new strings to store the data on the heap, but I never said that
trying to implement such idea would not require a lot of work.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 such a thingy is. Hence a Unicode singe char would need to be just be a Unicode string. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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" and does not necessarily mean "String of printable stuff". The management Pascal always provided for strings (after the "Short String" was not the only string type) (i.e. Operators, built-in functions, lazy copy, reference counting) is perfectly applicable to "Strings of things", and don't force any known encoding at all. The drama only was introduced by Embarcadero's abysmal / sloppy implementation of automatic code conversion for strings. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 failed to do a decent specification and implementation. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 is part of what is discussed there. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
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" do you think of ? Could you give an example where such a difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 functions. That is why I feel empowering the string paradigm for such use would be more appropriate. (See the thread "dynamic string proposal"). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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" Delphi. While it in fact does support full Unicode, keeping MyChar:=MyString[i] in place suggests to presume UCS-2 coded text for "unaware" programmers. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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-ide.org/listinfo/lazarus
Re: [Lazarus] Android & iOS
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.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
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 list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] German lazarus forum down
Vielen Dank für den Hinweis ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Enqueuing a callback from a thread via other class - or am I overcomplicating this ?
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 lifetime is controlled by the dedicated thread (meaning only one thread is allowed to Free() it); Of course a queued event should not use an object that might get freed by other means. If you want to pass data to the event, a useful way to avoid this is to create a transfer object: Type TTransfer = class; procedure the_event; TData: the_data; . running in the WorkerThread: Transfer := TTransfer.Create(...) Transfer.the_data. . := queue(@Transfer.the_event); (no Transfer.Free in the thread !!!) running in the MainThread: procedure TTransfer.the_event() begin ... fetch something from the_data ... Free; (this is Actually Self.Free; ) end; -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
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 bunch of problems. You might want to read -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
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 those, IMHO, is abysmal, as well in Delphi, as in fpc. (Most obvious drawback: not flexibly typed TStrings.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] FPVectorial
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 the appropriate file / search directory (pdfvrsemantico\pdfvrsemantico) to the project. Then it did not compile, as "TvVectorialDocument" does not feature the property "EndPath" (and others). So for initial testing, I commented some four lines out and was able to compile the project. But when starting, I get an exception in what I suppose is Portuguese. I used 1.6.4. Is a newer Lazarus version improved on that behalf ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
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 mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
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 Widget Type. I found that it was not yet complete but rather promising. AFAIK, not much has changed since then . Anyway I also would suggest to use this to build on. This will be a lot easier that do something completely new. In fact, Widget Types need to be known to the Lazarus IDE, as same is able to have the user select them and force them via definition of conditionals fed to the compiler. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
