Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
Wow, is that what I really sound like? tl;dr,ldo What I meant to say was: I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window. What is the best approach to get one's Designer into both IDE's? Thanks, and sorry for so many words. -gmt - Original Message - Hello Lazarusians. I'm working on a component with a relatively fat design-time footprint (that is, compared to it's run-time footprint -- it's a smallish sub-project but I expect ~75% of the code to be as design-time-only). My objective is simple, so I'd might as well just spell it out: I'm building a component to manage and encapsulate trivial configuration metadata at the module level in a platform-independent way. The basic approach I'm relying on right now is to give the user a TFrobCollection with various metadata-attributes, kind of like database columns. There will be some fairly straightforward slice-and-dice of the metadata, including aggregation across module boundaries. I want my code to be operational and maintainable in bleeding edge Delphi and Lazarus environments. I don't care too much about old versions. Being able to back-port to, say, D7, without horrible agonies, would be vaguely preferable, but it's far from a priority. I am pretty confident all of the run-time and business-logic aspects of this can be implemented without any need to step outside of the standard VCL/LCL mainstay design-patterns. The only thing that still has me still scratching my head is the design-time stuff. Specifically, I would ideally like to be able to code up my Collection property designer just once, and without utterly pathological usage of precompiler features. BTW even if it worked, I don't think I can just do form inheritance off TCollectionEditor or whatever it's called -- I'm looking to do something considerably more sophisticated than show a list and let the Object Inspector do all the real work -- probably showing the user a hierarchical representation even though the underlying data will be flat. What's troubling me is that Lazarus and Delphi seem to diverge more and more radically the deeper I push towards OTA territory. However, without some fairly elaborate designers I just can't see my component being both cross-platform and application-designer-friendly (I really hate when app. designers are forced to click back-and-forth bazillions of times, like monkeys, to accomplish semantically simple tasks, as too-often seems to be the case with Components supporting lots of TPersistents and Collections, but poor, buggy, or non-existent property designers... I won't name any names, but I'm sure many of you have been that monkey at some point or another (I know I have) and didn't like it :S Anyhow... can some of you with more experience with the LCL - ide state-of-the-art give me some advice on where is the right place to draw the line? i.e.: Should I just ignore all of the various Collection property editors and so forth and do something from scratch which absolutely minimizes OTA dependencies or will Lazarus be able to accommodate some more aggressive approach? Are there any particular OTA interoperation oases that work really well right now? Any hard-core face-slappers that I will need to fix upstream in Lazarus or the LCL before doing /anything/ meaningful along these lines? So far my TOwnedCollection skeleton works like a charm in both IDE's using the default designers, btw. I didn't have to use a single kludge. But my initial efforts at design-time stuff have ended up looking hopelessly pathological in one IDE or the other. Thanks for any help/advice you may have for me, -- -gmt -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Progress on Ubuntu 11.10 Gnome shell
I use neither Ubuntu nor Gnome nor Unity, but I'm curious: 1 Are other applications broken too? 2 Using LCL-Qt the problems appear too? 3 Using LCL-fpgui (but obviously not in the IDE) the problems appear too? -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
Gregory M. Turner g...@malth.us hat am 19. Oktober 2011 um 08:10 geschrieben: Wow, is that what I really sound like? tl;dr,ldo What I meant to say was: I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window. What is the best approach to get one's Designer into both IDE's? Thanks, and sorry for so many words. Thanks for summing up. You need two design time packages, the Delphi dpk and the Lazarus lpk. Each one needs one unit for the IDE dependent part, for example registering a menu item and registering an event when the selected designer components changes. These two units access the shared unit, which implements your fancy designer window. You can safely put the Delphi and Lazarus package into one directory. The shared unit uses only the LCL/VCL, which are quite compatible, so you probably don't need any compiler directives at all. Mattias -gmt - Original Message - Hello Lazarusians. I'm working on a component with a relatively fat design-time footprint (that is, compared to it's run-time footprint -- it's a smallish sub-project but I expect ~75% of the code to be as design-time-only). My objective is simple, so I'd might as well just spell it out: I'm building a component to manage and encapsulate trivial configuration metadata at the module level in a platform-independent way. The basic approach I'm relying on right now is to give the user a TFrobCollection with various metadata-attributes, kind of like database columns. There will be some fairly straightforward slice-and-dice of the metadata, including aggregation across module boundaries. I want my code to be operational and maintainable in bleeding edge Delphi and Lazarus environments. I don't care too much about old versions. Being able to back-port to, say, D7, without horrible agonies, would be vaguely preferable, but it's far from a priority. I am pretty confident all of the run-time and business-logic aspects of this can be implemented without any need to step outside of the standard VCL/LCL mainstay design-patterns. The only thing that still has me still scratching my head is the design-time stuff. Specifically, I would ideally like to be able to code up my Collection property designer just once, and without utterly pathological usage of precompiler features. BTW even if it worked, I don't think I can just do form inheritance off TCollectionEditor or whatever it's called -- I'm looking to do something considerably more sophisticated than show a list and let the Object Inspector do all the real work -- probably showing the user a hierarchical representation even though the underlying data will be flat. What's troubling me is that Lazarus and Delphi seem to diverge more and more radically the deeper I push towards OTA territory. However, without some fairly elaborate designers I just can't see my component being both cross-platform and application-designer-friendly (I really hate when app. designers are forced to click back-and-forth bazillions of times, like monkeys, to accomplish semantically simple tasks, as too-often seems to be the case with Components supporting lots of TPersistents and Collections, but poor, buggy, or non-existent property designers... I won't name any names, but I'm sure many of you have been that monkey at some point or another (I know I have) and didn't like it :S Anyhow... can some of you with more experience with the LCL - ide state-of-the-art give me some advice on where is the right place to draw the line? i.e.: Should I just ignore all of the various Collection property editors and so forth and do something from scratch which absolutely minimizes OTA dependencies or will Lazarus be able to accommodate some more aggressive approach? Are there any particular OTA interoperation oases that work really well right now? Any hard-core face-slappers that I will need to fix upstream in Lazarus or the LCL before doing /anything/ meaningful along these lines? So far my TOwnedCollection skeleton works like a charm in both IDE's using the default designers, btw. I didn't have to use a single kludge. But my initial efforts at design-time stuff have ended up looking hopelessly pathological in one IDE or the other. Thanks for any help/advice you may have for me, -- -gmt -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Mon, Oct 3, 2011 at 4:35 PM, Henry Vermaak henry.verm...@gmail.com wrote: That's good news, thanks! Hello, Could you test the very latest Pascal Widestring Manager? Just disable cwstring and then add paswstring as the first unit in your projects uses clause. The Pascal Widestring Manager is completed, but it needs more testing =) -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
- Original Message - Gregory M. Turner g...@malth.us hat am 19. Oktober 2011 um 08:10 geschrieben: Wow, is that what I really sound like? tl;dr,ldo What I meant to say was: I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window. What is the best approach to get one's Designer into both IDE's? Thanks, and sorry for so many words. Thanks for summing up. No problem -- sometimes I need to write the Great American Novel before I can figure out what I'm trying to say. There are worse character flaws, but I sometimes wish I more often had the good sense not to press Send :S You need two design time packages, the Delphi dpk and the Lazarus lpk. Each one needs one unit for the IDE dependent part, for example registering a menu item and registering an event when the selected designer components changes. These two units access the shared unit, which implements your fancy designer window. You can safely put the Delphi and Lazarus package into one directory. The shared unit uses only the LCL/VCL, which are quite compatible, so you probably don't need any compiler directives at all. That sounds perfectly reasonable. I think I was afraid the Oracle would put a hex on me if I did this, but after trying it the other way, I think she's much more likely to condone this tiny sacrifice. In fact, by encouraging me to limit the OTA's inevitably wicked and corrupting influence on my design(-er), your suggestion will probably result in a better outcome than if I had simply hacked up an IDE-specific implementation. Thanks, -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Mon, Oct 03, 2011 at 04:31:20PM +0200, Felipe Monteiro de Carvalho wrote: Ok, I changed the define in rev 32655. But you should note that when paswstring gets finished it will phase out cwstrings. Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] LCL Message handling
Can somebody explain the purpose of e.g. WindowProc, WndProc and MainWndProc, in the LCL? What's the purpose of TWinControl.MainWndProc, when it's never called or used otherwise, does nothing, and is not virtual? In Delphi MainWndProc calls the handler assigned to WindowProc, enclosed in try-finally and try-except blocks. WindowProc typically is initialized with WndProc. Why is this implemented differently in the LCL, and how? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 12:06 PM, Marco van de Voort mar...@stack.nl wrote: Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. What is the difference between using cwstring and paswstring? Any reason for not wanting to use paswstring? They should be 100% equal, except that one does not require any external libraries. If you can test and check if there are any differences of course would be excelent =) -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wednesday 19 October 2011 13.14:50 Felipe Monteiro de Carvalho wrote: On Wed, Oct 19, 2011 at 12:06 PM, Marco van de Voort mar...@stack.nl wrote: Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. What is the difference between using cwstring and paswstring? Any reason for not wanting to use paswstring? Where is paswstring? Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
On Wed, Oct 19, 2011 at 1:56 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Can somebody explain the purpose of e.g. WindowProc, WndProc and MainWndProc, in the LCL? Delphi compatibility. AFAIK WndProc works for messages = WM_USER In Delphi MainWndProc calls the handler assigned to WindowProc, enclosed in try-finally and try-except blocks. WindowProc typically is initialized with WndProc. Why is this implemented differently in the LCL, and how? I remember that some people did not like how this worked in Delphi so it didn't work like that, then we had a define to pass messages = WM_USER to WndProc. I think the define later got changed into always active. I don't remember anyone asking for messages WM_USER, so probably till now they are not passed to WndProc. I'm just typing from memory, so I could be wrong in parts of this. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
Marco van de Voort schrieb: On Mon, Oct 03, 2011 at 04:31:20PM +0200, Felipe Monteiro de Carvalho wrote: Ok, I changed the define in rev 32655. But you should note that when paswstring gets finished it will phase out cwstrings. Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. After some discussions in Embarcadero groups I would like to learn more about the FPC implementation and goals of the new (Unicode...) strings. Where should I have a look? In detail it turned out that Delphi only supports CP_ACP strings for Ansi codepages, not including UTF-8. Strings with other encodings may be converted properly (not yet), but otherwise should not be used with standard stringhandling procedures. Will this be changed in the FPC RTL, so that at least UTF8Strings are also supported properly? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 1:24 PM, Martin Schreiber mse00...@gmail.com wrote: Where is paswstring? http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/lazutils/paswstring.pas?view=markuproot=lazarus It uses lazutf8 (which includes most importantly UTF16ToUTF8 and viceversa and utf8LowerCase and utf8UpperCase) and lconvencoding (which includes encoding tables) which are in the same folder. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
Felipe Monteiro de Carvalho schrieb: On Wed, Oct 19, 2011 at 1:56 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Can somebody explain the purpose of e.g. WindowProc, WndProc and MainWndProc, in the LCL? Delphi compatibility. AFAIK WndProc works for messages = WM_USER WndProc can preprocess *any* kind of messages, which must be handled in a non-standard way in a specific control, e.g. the TripleClick messages. WndProc finally calls Dispatch, to invoke the implemented message handler of the control, or DefaultHandler for all messages without assigned handlers. In Delphi MainWndProc calls the handler assigned to WindowProc, enclosed in try-finally and try-except blocks. WindowProc typically is initialized with WndProc. Why is this implemented differently in the LCL, and how? I remember that some people did not like how this worked in Delphi so it didn't work like that, then we had a define to pass messages = WM_USER to WndProc. I think the define later got changed into always active. I don't remember anyone asking for messages WM_USER, so probably till now they are not passed to WndProc. I'm just typing from memory, so I could be wrong in parts of this. I fear that Delphi compatibility is broken, when MainWndProc does nothing. When it is not removed, it should do what Delphi does, so that it can be used in code ported from Delphi. Otherwise it should be removed, together with WindowProc, so that every attempt to use it will result in compiler errors. I also don't understand the parallel or different WM..., LM..., CM... and CN... message IDs. Is that separation related to messages handled (or not handled) by widgets or by the LCL? Or have the LM... message IDs been added only to prevent cyclic unit references? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
On Wed, Oct 19, 2011 at 2:52 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: WndProc can preprocess *any* kind of messages, which must be handled in a non-standard way in a specific control, e.g. the TripleClick messages. WndProc finally calls Dispatch, to invoke the implemented message handler of the control, or DefaultHandler for all messages without assigned handlers. You can wait some days to see if anyone is against the change and if not (Vincent didn't like this as far as I remember, so it would be good to hear from him). If there is no answer in 1 week then you can send a patch to bug tracker where this can then be further discussed. I also don't understand the parallel or different WM..., LM..., CM... and CN... message IDs. Is that separation related to messages handled (or not handled) by widgets or by the LCL? Or have the LM... message IDs been added only to prevent cyclic unit references? LM messages are sent from the LCL-Widgetsets to the LCL, so they are cross-platform. WM messages are only for Windows. I don't know what CM/CN messages are. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
2011/10/19 Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com: On Wed, Oct 19, 2011 at 2:52 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: WndProc can preprocess *any* kind of messages, which must be handled in a non-standard way in a specific control, e.g. the TripleClick messages. WndProc finally calls Dispatch, to invoke the implemented message handler of the control, or DefaultHandler for all messages without assigned handlers. You can wait some days to see if anyone is against the change and if not (Vincent didn't like this as far as I remember, so it would be good to hear from him). If there is no answer in 1 week then you can send a patch to bug tracker where this can then be further discussed. Since I hardly do any win32 programming for Lazarus anymore, I hardly have to say anything anymore. What I was against, is letting all windows messages bubble up from the win32 widgetset interface into the LCL. I am more a proponent of only passing those messages to the LCL what are handled by the LCL, not all and very messages that the win32 widget generate. I cannot remember having said about what the LCL should handle messages. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
Am 19.10.2011 14:08, schrieb Hans-Peter Diettrich: Marco van de Voort schrieb: On Mon, Oct 03, 2011 at 04:31:20PM +0200, Felipe Monteiro de Carvalho wrote: Ok, I changed the define in rev 32655. But you should note that when paswstring gets finished it will phase out cwstrings. Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. After some discussions in Embarcadero groups I would like to learn more about the FPC implementation and goals of the new (Unicode...) strings. Where should I have a look? In detail it turned out that Delphi only supports CP_ACP strings for Ansi codepages, not including UTF-8. Strings with other encodings may be converted properly (not yet), but otherwise should not be used with standard stringhandling procedures. Will this be changed in the FPC RTL, so that at least UTF8Strings are also supported properly? Uhm... isn't this better suited in fpc-devel? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Cannot compile trunk
Hi, I'm trying to compile Trunk with fpc 2.7.1 (also from trunk), and I'm getting this while trying to do a make clean all: lconvencoding.pas(6123,8) Hint: Conversion between ordinals and pointers is not portable lconvencoding.pas(6163,8) Hint: Conversion between ordinals and pointersis not portable paswstring.pas(368,43) Error: Incompatible types: got address of procedure(PWideChar,var AnsiString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PWideChar,var RawByteString,Word,Int64);Register paswstring.pas(369,43) Error: Incompatible types: got address of procedure(PChar,var WideString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PChar,Word,var WideString,Int64);Register paswstring.pas(407,46) Error: Incompatible types: got address of procedure(PWideChar,var AnsiString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PUnicodeChar,var RawByteString,Word,Int64);Register paswstring.pas(408,46) Error: Incompatible types: got address of procedure(PChar,var UnicodeString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PChar,Word,var UnicodeString,Int64);Register paswstring.pas(421) Fatal: There were 4 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [lazutils.ppu] Error 1 make[1]: se sale del directorio «/home/leonardo/Desarrollo/lazarus/components/lazutils» make: *** [lazutils] Error 2 -- Leonardo M. Ramé http://leonardorame.blogspot.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot compile trunk
On 2011-10-19 11:13:13 -0300, Leonardo M. Ramé wrote: Hi, I'm trying to compile Trunk with fpc 2.7.1 (also from trunk), and I'm getting this while trying to do a make clean all: lconvencoding.pas(6123,8) Hint: Conversion between ordinals and pointers is not portable lconvencoding.pas(6163,8) Hint: Conversion between ordinals and pointersis not portable paswstring.pas(368,43) Error: Incompatible types: got address of procedure(PWideChar,var AnsiString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PWideChar,var RawByteString,Word,Int64);Register paswstring.pas(369,43) Error: Incompatible types: got address of procedure(PChar,var WideString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PChar,Word,var WideString,Int64);Register paswstring.pas(407,46) Error: Incompatible types: got address of procedure(PWideChar,var AnsiString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PUnicodeChar,var RawByteString,Word,Int64);Register paswstring.pas(408,46) Error: Incompatible types: got address of procedure(PChar,var UnicodeString,Int64);Register expected TUnicodeStringManager.procedure variable type of procedure(PChar,Word,var UnicodeString,Int64);Register paswstring.pas(421) Fatal: There were 4 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [lazutils.ppu] Error 1 make[1]: se sale del directorio «/home/leonardo/Desarrollo/lazarus/components/lazutils» make: *** [lazutils] Error 2 I had to revert to rev 32966 to compile it successfully. -- Leonardo M. Ramé http://leonardorame.blogspot.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot compile trunk
Does it compile with rev 32982 (latest svn)? -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot compile trunk
On 2011-10-19 16:44:50 +0200, Felipe Monteiro de Carvalho wrote: Does it compile with rev 32982 (latest svn)? Yes, thanks!. -- Leonardo M. Ramé http://leonardorame.blogspot.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
Vincent Snijders schrieb: What I was against, is letting all windows messages bubble up from the win32 widgetset interface into the LCL. I am more a proponent of only passing those messages to the LCL what are handled by the LCL, not all and very messages that the win32 widget generate. IMO such a separation already exists. The WM messges are sent *to* (Windows) widgets, like widget-specific EM (Edit), BM (Button) etc. messages. A widget itself sends back *notification* messages (EN, BN...), for use in an application or in the VCL/LCL. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
Felipe Monteiro de Carvalho schrieb: I also don't understand the parallel or different WM..., LM..., CM... and CN... message IDs. Is that separation related to messages handled (or not handled) by widgets or by the LCL? Or have the LM... message IDs been added only to prevent cyclic unit references? LM messages are sent from the LCL-Widgetsets to the LCL, so they are cross-platform. WM messages are only for Windows. Since no message IDs exist for other platforms, I'd assume that the LM messages are equivalent to the WM IDs. But why new names for old names? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 01:14:50PM +0200, Felipe Monteiro de Carvalho wrote: On Wed, Oct 19, 2011 at 12:06 PM, Marco van de Voort mar...@stack.nl wrote: Not that I know. And btw, I also use arm-linux without android, so please keep that target intact and aligned with normal linux ports. What is the difference between using cwstring and paswstring? Any reason for not wanting to use paswstring? Simply integrating with the OS, and avoid inclusion of tables when not necessary. Moreover you are stating something as a fact here that was not discussed at all. They should be 100% equal, except that one does not require any external libraries. If you can test and check if there are any differences of course would be excelent =) I haven't been testing it, and don't plan to. I'm not interested in it, and am not interested in growing the binaries unnecessarily. I have no problem with having a second option for the people that do want it, but that is something entirely different from what you were saying. Cwstring is staying on all normal targets as far as I know. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 6:47 PM, Marco van de Voort mar...@stack.nl wrote: Moreover you are stating something as a fact here that was not discussed at all. I am confused by your statements, the discussion here is about the usage of cwstring in the LCL, then I said that I want to replace cwstring with paswstring in the LCL (after making sure it is completely equivalent). Are you also discussing about the usage of cwstring in the LCL? Your comments make me think that you are assuming I am talking about the RTL or something like that. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
2011/10/19 Hans-Peter Diettrich drdiettri...@aol.com: Vincent Snijders schrieb: What I was against, is letting all windows messages bubble up from the win32 widgetset interface into the LCL. I am more a proponent of only passing those messages to the LCL what are handled by the LCL, not all and very messages that the win32 widget generate. IMO such a separation already exists. The WM messges are sent *to* (Windows) widgets, like widget-specific EM (Edit), BM (Button) etc. messages. A widget itself sends back *notification* messages (EN, BN...), for use in an application or in the VCL/LCL. No, IIRC, currently every message that gets into the win32 message handlers, is passed to the LCL. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wednesday 19 October 2011 18.59:06 Felipe Monteiro de Carvalho wrote: On Wed, Oct 19, 2011 at 6:47 PM, Marco van de Voort mar...@stack.nl wrote: Moreover you are stating something as a fact here that was not discussed at all. I am confused by your statements, the discussion here is about the usage of cwstring in the LCL, then I said that I want to replace cwstring with paswstring in the LCL (after making sure it is completely equivalent). Are you also discussing about the usage of cwstring in the LCL? Your comments make me think that you are assuming I am talking about the RTL or something like that. Ah, sorry, I read it wrong too... Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 06:59:06PM +0200, Felipe Monteiro de Carvalho wrote: I am confused by your statements, the discussion here is about the usage of cwstring in the LCL, then I said that I want to replace cwstring with paswstring in the LCL (after making sure it is completely equivalent). Are you also discussing about the usage of cwstring in the LCL? Your comments make me think that you are assuming I am talking about the RTL or something like that. No, sorry. Though I still think that is not a good thing either. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
2011/10/19 Marco van de Voort mar...@stack.nl: On Wed, Oct 19, 2011 at 06:59:06PM +0200, Felipe Monteiro de Carvalho wrote: I am confused by your statements, the discussion here is about the usage of cwstring in the LCL, then I said that I want to replace cwstring with paswstring in the LCL (after making sure it is completely equivalent). Are you also discussing about the usage of cwstring in the LCL? Your comments make me think that you are assuming I am talking about the RTL or something like that. No, sorry. Though I still think that is not a good thing either. I guess Felipe gave up waiting on a Unicode RTL for the time being and goes for a full UTF8 pseudo RTL in LazUtils. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, Oct 19, 2011 at 6:33 PM, Martin Schreiber mse00...@gmail.com wrote:
Does it use locale specific collation in PasUnicodeCompareStr and
PasUnicodeCompareText?
Good point, no, not yet. But this affects only turkish, azeri and
lithuanian AFAIK
Adding turkish and azeri is trivial, because UTF8LowerCase supports
them, but I did not understand yet the rules for Lithuanian, they are
quite convoluted, depend on nearby chars and stuff like that.
Is the performance of UTF8LowerCase and UTF8UpperCase OK?
UTF8LowerCase was heavily optimized. UTF8UpperCase still needs to be
more optimized.
6 million UTF8LowerCase operations in the string АБВЕЁЖЗКЛМНОПРДЙГ
takes 2,6 seconds in my computer. It outperforms iconv by a factor of
2,5x aprox:
UTF8LowerCase-- Performance test took: 804 ms 1896 ms
2318 ms 3460 ms 2647 ms 1847 ms 2526 ms 2496 ms
1830 ms 1975 ms
CWString SysUtils.UnicodeLowerCase-- Performance test took:
2456 ms 2461 ms 6594 ms 6170 ms 5347 ms 6939 ms
4398 ms 4429 ms 2285 ms 2411 ms
For this strings:
if j = 0 then Str := UTF8LowerCase('abcdefghijklmnopqrstuwvxyz');
if j = 1 then Str := UTF8LowerCase('ABCDEFGHIJKLMNOPQRSTUWVXYZ');
if j = 2 then Str := UTF8LowerCase('aąbcćdeęfghijklłmnńoóprsśtuwyzźż');
if j = 3 then Str := UTF8LowerCase('AĄBCĆDEĘFGHIJKLŁMNŃOÓPRSŚTUWYZŹŻ');
if j = 4 then Str := UTF8LowerCase('АБВЕЁЖЗКЛМНОПРДЙГ');
if j = 5 then Str := UTF8LowerCase('名字叫嘉英，嘉陵江的嘉，英國的英');
if j = 6 then Str :=
UTF8LowerCase('AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuWvVwXxYyZz');
if j = 7 then Str :=
UTF8LowerCase('AAaaBBbbCCccDDddEEeeFFffGGggHHhhIIiiJJjjKKkkLLllMMmm');
if j = 8 then Str := UTF8LowerCase('abcDefgHijkLmnoPqrsTuwvXyz');
if j = 9 then Str := UTF8LowerCase('ABCdEFGhIJKlMNOpQRStUWVxYZ');
Do UTF8LowerCase and UTF8UpperCase cover all upper/lowercase Unicode
(possibly accented) characters?
UTF8LowerCase currently covers all characters in the latest Unicode
spec AFAIK. Of course I might have forgotten something, but I have
tests for chars from to 0580 and more tests for other clusters.
UTF8UpperCase is currently implemented from to 0450, but I will
add the rest.
Does it handle decomposed characters (cwstring doesn't)?
I think that decomposed characters should work naturally. See, for
example, if we have: [0]=~ (tilde accent, but the special version for
composition) [1]=A which forms à and then we pass lowercase into it,
we would get [0] without change and [1]=a which forms ã. Or am I
wrong?
If you are talking about handling for CompareText, then the answer
would be that AFAIK it would be too inneficient to handle that in
CompareText ... so we would need another routine for that
NormalizedCompareText or something like that, which executes
normalization, then lowercase and finally the comparison.
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On 10/19/11, Vincent Snijders vincent.snijd...@gmail.com wrote: I guess Felipe gave up waiting on a Unicode RTL for the time being and goes for a full UTF8 pseudo RTL in LazUtils. Well, after a lot of discussion I got convinced that Lazarus should give a try at the UTF-8 mode of the RTL when this appears, and this might be very useful for our usage of TStringList, TComponent, TStream, etc. I think this solution has major problems, but it was claimed that my proposed solutions have much worse problems, so in the end I concluded that we should try the UTF-8 mode of the RTL when it appears. But this does not mean that LazUtils would not be useful then. My proposals to add UTF-8 routines to the RTL and even FCL were rejected, so we UTF-8 users would need to be stuck with only whatever routines Embarcadero invents. That's not nearly good enough and not nearly fast enough. UTF8LowerCase is very superior to the existing RTL LowerCase. To start with, the RTL in existing release doesn't even have a UTF8String LowerCase (no idea about 2.7). Also, UTF8LowerCase has a second parameter to specify the language, so we can test and support Turkish without having to change our locale to turkish, and it outperforms SysUtils.UnicodeLowerCase by 250% aprox in my Mac, and it has zero external dependencies while depending on zero initialization code, zero global variables and having 1k lines of code (half of them comments), which is not that much. As you can see it vastly outperforms even what the UTF-8 mode of the RTL would offer for this. Just like UTF8LowerCase, other things provided by LazUtils will also be useful options for Lazarus and other libraries/applications, regardless of FPC offering something similar. And then I think that everyone will be happy. People that want Delphi compatibility (excluding string and PChar, since they will not match in the RTL mode used by Lazarus) will be happy, they can use RTL routines and get compatibility. Lazarus will still be using string and TStringList, TComponent, etc. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
On Wed, 19 Oct 2011, Felipe Monteiro de Carvalho wrote: On 10/19/11, Vincent Snijders vincent.snijd...@gmail.com wrote: I guess Felipe gave up waiting on a Unicode RTL for the time being and goes for a full UTF8 pseudo RTL in LazUtils. Well, after a lot of discussion I got convinced that Lazarus should give a try at the UTF-8 mode of the RTL when this appears, and this might be very useful for our usage of TStringList, TComponent, TStream, etc. I think this solution has major problems, but it was claimed that my proposed solutions have much worse problems, so in the end I concluded that we should try the UTF-8 mode of the RTL when it appears. But this does not mean that LazUtils would not be useful then. My proposals to add UTF-8 routines to the RTL and even FCL were rejected, Correction: Your proposals were not rejected. No decision as to which character sets will be used in the basic RTL has been taken. Any action you take now is therefor premature. So it was suggested you would wait till things settle down till and the final shape of things are more clear. This really is not the same as 'rejected'. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
2011/10/19 Michael Van Canneyt mich...@freepascal.org: On Wed, 19 Oct 2011, Felipe Monteiro de Carvalho wrote: On 10/19/11, Vincent Snijders vincent.snijd...@gmail.com wrote: I guess Felipe gave up waiting on a Unicode RTL for the time being and goes for a full UTF8 pseudo RTL in LazUtils. But this does not mean that LazUtils would not be useful then. My proposals to add UTF-8 routines to the RTL and even FCL were rejected, Correction: Your proposals were not rejected. Thanks for the clarification. No decision as to which character sets will be used in the basic RTL has been taken. Any action you take now is therefor premature. So it was suggested you would wait till things settle down till and the final shape of things are more clear. That is why I said: gave up waiting This really is not the same as 'rejected'. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL Message handling
Vincent Snijders schrieb: What I was against, is letting all windows messages bubble up from the win32 widgetset interface into the LCL. I am more a proponent of only passing those messages to the LCL what are handled by the LCL, not all and very messages that the win32 widget generate. IMO such a separation already exists. The WM messges are sent *to* (Windows) widgets, like widget-specific EM (Edit), BM (Button) etc. messages. A widget itself sends back *notification* messages (EN, BN...), for use in an application or in the VCL/LCL. No, IIRC, currently every message that gets into the win32 message handlers, is passed to the LCL. Where do all the messages originate in the non-Windows widgetsets? Aren't these generated by the widgetsets? Any hints where I could find out more about details? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
Hello, On 2011-10-19 21:03, Felipe Monteiro de Carvalho wrote: On Wed, Oct 19, 2011 at 6:33 PM, Martin Schreibermse00...@gmail.com wrote: Does it use locale specific collation in PasUnicodeCompareStr and PasUnicodeCompareText? Good point, no, not yet. But this affects only turkish, azeri and lithuanian AFAIK Adding turkish and azeri is trivial, because UTF8LowerCase supports them, but I did not understand yet the rules for Lithuanian, they are quite convoluted, depend on nearby chars and stuff like that. I am native Lithuanian so I think can help at least providing info, but I must understand what is the problem first. Do I understand correctly, that collation means sorting order? In that case Lithuanian does not depend on near by characters. There are 32 letters and they follow this order: Aa Ąą Bb Cc Čč Dd Ee Ęę Ėė Ff Gg Hh Ii Įį Yy Jj Kk Ll Mm Nn Oo Pp Rr Ss Šš Tt Uu Ųų Ūū Vv Zz Žž And there are some accented characters which are used only in linguistic texts (for example, dictionaries). (All list is here: http://developer.mimer.com/charts/lithuanian.htm) The funny thing is that in dictionaries when sorting words, Aa and Ąą (also: Ee and Ęę and Ėė; Ii and Įį and Yy; Uu and Ųų and Ūū) are treated as the same letter. BUT, for example words šieną sieną sieną - all three are different words (no accents in these characters). BUT I believe that accented characters should be treated as the same letter: šiẽną = šieną; siena = síena, because it is the same word (accents do not change word meaning and are totally not required to be provided by the text writer). I don't know if I managed to explain anything, but if you'll need some help with Lithuanian language - feel free to contact me. Regards, Žilvinas Ledas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] cwstring in arm-linux
Hello,
2011/10/19 Žilvinas Ledas zilvinas.le...@dict.lt:
I am native Lithuanian so I think can help at least providing info, but I
must understand what is the problem first.
I am mostly interested in LowerCase / UpperCase. Could you explain how
it works in Lithuanian and provide test cases for it?
Test cases should be in this format:
AssertStringOperationUTF8LowerCase('Unicode 0460 UTF8LowerCase', '',
'ѠѡѢѣѤѥѦѧѨѩѪѫѬѭѮѯ', 'ѡѡѣѣѥѥѧѧѩѩѫѫѭѭѯѯ');
Even better if they are in patches to the file
lazarus/tests/lazutils/testunicode.pas
First param is the label, the second the locale (in this case maybe
something like 'lt', what is the ISO identifier for lituanian? Then
UpperCase and then LowerCase.
And try to make some tricky tests, to defeat partial implementations.
3 tests for lowercase and 3 for uppercase should be enough
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
