Re: [Lazarus] What happened to TNoteBook?
http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes#TNotebook_and_TPage In short: Someone implemented TNotebook wrongly and then people started using it as a TPageControl. They should use TPageControl instead and leave TNotebook for it's real purpose, which is a multi-paged control without borders and without tabs. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Did the executable output path change?
2011/2/14 Graeme Geldenhuys graemeg.li...@gmail.com: Op 2011-02-11 15:27, Andreas Schneider het geskryf: He who wants to be heard (by me) must follow *my* rules :-] Yeah, but it's not your list and you aren't the only one who reads it. Just saying because what you wrote sounds pretty egocentric. Where is the list moderator/maintainer now? HTML email is NOT allowed in the mailing list as for as I know. I choose not to respond in this thread. It is not forbidden to write HTML mails, I agree is it not wise, because less people can read it. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Did the executable output path change?
Op 2011-02-14 10:40, Vincent Snijders het geskryf: It is not forbidden to write HTML mails, I agree is it not wise, because less people can read it. OK, could you maybe create a Lazarus mailing list etiquette page like what was done for fpc-pascal as shown below. This could include attachment size limit, preferred mail format, quote size etc. This information could be very useful to new mailing list subscribers. http://lists.freepascal.org/mailman/listinfo/fpc-pascal Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] substr return wrong string with some utf8 char
On 02/11/2011 06:44 PM, Jürgen Hestermann wrote: I think the decision for UTF8 is very good. AFAIK, the decision to use UTF8 is due to Linux using this encoding and so no conversion is done in the LCL system API. This of course is bad with Windows, as here the API uses UTF16 and everything needs to be recoded in the LC System API on entry and exit. Supposedly doing different string types - UTF8String vs (a reference counting version of UTF-16-encoded) WideString - for Linux and Windows at the LCL-user-Code interface is too confusing. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On 02/12/2011 06:49 PM, Marco van de Voort wrote:And currently UTF8String is defined as AnsiString, so there is currently no difference That's what I thought. So why did they [FPC team] actually bother to create the UTF8String type then? It's an alias for literal programming purposes. While I disagree on much of his wording I so agree with the OP, that with having ANSIString and UTF8String an alias for exactly the same - only to allow for keeping in mind what coding the user manually introduces - is very confusing. These names strongly suggest that a statement myANSIString := MYUTF8String either is detected as illegal or forces appropriate conversion. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On 02/13/2011 11:15 PM, Bo Berglund wrote: In serial components I have used with Delphi before there was always a property to set the buffer sizes (both Tx and Rx). But I cannot find a way to do this with SdpoSerial. Does SdpoSerial use buffers at all ? With AsyncPro, Buffers necessary to convert the blocking System interface into the event driven AsyncPro user API by doing the blocking system calls in threads. With the receiver, the collected data needs to be buffered until the main thread is available to handle it, With the sender, the data generated by the main thread needs to be buffered until the system API unblocks the interface it blocked to prevent overrun of the system buffers. Without using threads the user just sees a blocking interface and no buffers are necessary. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] substr return wrong string with some utf8 char
On Mon, 14 Feb 2011 10:58:24 +0100 Michael Schnell mschn...@lumino.de wrote: On 02/11/2011 06:44 PM, Jürgen Hestermann wrote: I think the decision for UTF8 is very good. AFAIK, the decision to use UTF8 is due to Linux using this encoding and so no conversion is done in the LCL system API. No, that was just a nice goody. The decision was made at a time where many Linux distributions still use ISO character sets and most Windows used UCS-2. UTF-8 was chosen, because the LCL should use only one string type for easy usage, UTF-8 supports the whole unicode range, there was no reference counted widestring in FPC and porting existing code is easier with UTF-8. This of course is bad with Windows, as here the API uses UTF16 and everything needs to be recoded in the LC System API on entry and exit. In almost all cases the overhead is insignificant compared to the GUI. For non gui tasks the overhead may be a problem, but that has nothing to do with the LCL. Supposedly doing different string types - UTF8String vs (a reference counting version of UTF-16-encoded) WideString - for Linux and Windows at the LCL-user-Code interface is too confusing. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On 02/14/2011 11:29 AM, Michael Schnell wrote: Without using threads the user just sees a blocking interface and no buffers are necessary. Don't do this in the main thread, otherwise the complete application hangs. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On Sat, Feb 12, 2011 at 6:49 PM, Marco van de Voort mar...@stack.nl wrote: This is all undecided. I lean towards splitting operating system targets into a utf8 and a utf16 one for most platforms(*), since nobody will ever agree on one encoding. Not even per platform. (*) and a legacy ansi one if need be. Why do we need targets? Wouldn't it be better to simply duplicate all string functions for utf8 and utf16 and ansi if necessary? That was my idea from the start in case the new string was merged. For example: CompareText UTF8CompareText UTF16CompareText The versions with a fixed encoding could refer to a generic unicode version with undefined encoding. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Component rename in lazarus...
By accident I just discovered a feature of Lazarus that I was not aware of: I had misnamed a component and wanted to correct it, so I gave it a new name in the property editor. Then I planned on going over the code and change the places where the component was used to the new name. But it was already done! Apparently Lazarus keeps tabs on such renames and changes the places in the form code where the old name was used to the new name! Excellent!! :-) This is something I had wanted in Delphi too... Now I am just wondering what other goodies are hidden in Lazarus? Pleasant surprieses await, no doubt. Question: In Delphi I really wanted a feature of the VisualBasic 6 editor but it never materialized in Delphi: Case correction. This means that if I write a function like this: function MyFunc: boolean; var MyVar: byte; MyOtherVar: word; begin myvar := 23; myothervar := myVar + 56; then the editor will immediately correct the case of the variables so the code comes out like this: MyVar:= 23; MyOtherVar := MyVar + 56; And if I later change the declaration to: Myvar: byte; then the places it is used will change to the new case style. Is there some way one can make this happen in Lazarus? (I made a quick test but it did not work right off the bat at least) Bo Berglund -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Op 2011-02-14 13:16, Felipe Monteiro de Carvalho het geskryf: Why do we need targets? I would imagine that such a new string type (possibly UnicodeString) would default to the encoding used per platform by default. eg: * a Linux UnicodeString will default to UnicodeString(utf8) * a Windows UnicodeString will default to UnicodeString(utf16) etc.. But that doesn't limit the developer, because the developer could simply define a new string type and use that instead. eg: // alias types with their encodings set to something specific UTF8String = UnicodeString(utf8); UTF16String = UnicodeString(utf16); CP850String = UnicodeString(cp850); etc... Wouldn't it be better to simply duplicate all string functions for utf8 and utf16 and ansi if necessary? Why? CompareText and all other such functions should simply take a UnicodeString types as parameter (in addition to the already existing WideString, AnsiString and ShortString versions). The Unicode enabled version of CompareText will then query the encodings used and do a automatic conversion if needed, then do the comparison and return the result. eg: var u8: UTF8String; u16: UTF16String; s850: CP850String; r: integer; begin u8 := ...; u16 := ...; s850 := ...; r := CompareText(u8, u16); ... r := CompareText(u8, s850); ... end; CompareText UTF8CompareText UTF16CompareText So for every possible encoding and code page you want to make a new function? That doesn't sound like a good plan to me. The encoding information is inside the string type, so use it to do automatic conversions. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On Mon, Feb 14, 2011 at 1:08 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: But that doesn't limit the developer, because the developer could simply define a new string type and use that instead. Maybe I used a bad example, but anyway, var parameters need to be exact So for every possible encoding and code page you want to make a new function? Of course not! Only the important ones. For me this means only UTF-8, but I supposed some people might want UTF-16 too. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Op 2011-02-14 14:15, Felipe Monteiro de Carvalho het geskryf:
Maybe I used a bad example, but anyway, var parameters need to be exact
alias types are not really new types, so will not affect var
parameters. So in my previous example, UTF16String will still be a
UnicodeString. The only difference will be that UTF16String has its
internal encoding bit set to UTF-16.
Here is a test program using latest FPC 2.4.3 showing that TMyString =
String - the compiler sees no difference between the two types. So the
same should be valid for UnicodeString vs UnicodeString(...) that have
their encoding bit set to something other than the platform default.
---8---8---8---8---8---
program project1;
{$mode objfpc}{$H+}
uses
Classes
type
TMyText = String;
procedure TestMe(var AText: string);
begin
writeln(AText);
AText := 'Hello ' + AText;
end;
var
s: TMyText;
begin
s := 'Graeme';
TestMe(s);
writeln(s);
end.
---8---8---8---8---8---
So for every possible encoding and code page you want to make a new
function?
Of course not! Only the important ones. For me this means only UTF-8,
but I supposed some people might want UTF-16 too.
Again I don't see why that is needed. You might only require UTF-8, but
somebody else wants UTF-16, and somebody else wants CP850 versions etc
etc.. Where does it end?
A simple function like:
function CompareText(const S1: UnicodeString;
const S2: UnicodeString): integer;
should be able to work with any UnicodeString parameters (including
alias types that have different encoding bits set). So it should work
fine for your UTF-8 text, and somebody else's UTF-16 etc. text.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
On Mon, 14 Feb 2011 13:06:50 +0100 Bo Berglund bo.bergl...@gmail.com wrote: By accident I just discovered a feature of Lazarus that I was not aware of: I had misnamed a component and wanted to correct it, so I gave it a new name in the property editor. Then I planned on going over the code and change the places where the component was used to the new name. But it was already done! Apparently Lazarus keeps tabs on such renames and changes the places in the form code where the old name was used to the new name! Excellent!! :-) This is something I had wanted in Delphi too... I thought Delphi does that? Now I am just wondering what other goodies are hidden in Lazarus? Pleasant surprieses await, no doubt. Question: In Delphi I really wanted a feature of the VisualBasic 6 editor but it never materialized in Delphi: Case correction. This means that if I write a function like this: function MyFunc: boolean; var MyVar: byte; MyOtherVar: word; begin myvar := 23; myothervar := myVar + 56; then the editor will immediately correct the case of the variables so the code comes out like this: MyVar:= 23; MyOtherVar := MyVar + 56; Ctrl+Space (identifier completion) copies the case. Automatic recasing may be unwanted if the declaration has no casing at all. For example SysUtils is nicer to read than sysutils. I'm not sure, maybe jcf can fix casing. And if I later change the declaration to: Myvar: byte; then the places it is used will change to the new case style. Is there some way one can make this happen in Lazarus? Shift+Ctrl+E renames variables and references. It does not yet find all references, but IMO it is already a useful tool. (I made a quick test but it did not work right off the bat at least) Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
14.02.2011 20:40, Mattias Gaertner wrote: But it was already done! Apparently Lazarus keeps tabs on such renames and changes the places in the form code where the old name was used to the new name! Excellent!! :-) This is something I had wanted in Delphi too... I thought Delphi does that? Delphi does not rename all uses of component in the code. Ctrl+Space (identifier completion) copies the case. Automatic recasing may be unwanted if the declaration has no casing at all. For example SysUtils is nicer to read than sysutils. I'm not sure, maybe jcf can fix casing. Only using fixed list of words like: Assign, WriteLn Best regards, Paul Ishenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On Mon, Feb 14, 2011 at 2:35 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Here is a test program using latest FPC 2.4.3 showing that TMyString = String - the compiler sees no difference between the two types. So the same should be valid for UnicodeString vs UnicodeString(...) that have their encoding bit set to something other than the platform default. It is pure speculation to assume that this behavior will remain valid. -- Felipe Monteiro de Carvalho -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Old OpenSUSE 10.2 and Laz 29544
I have an OpenSUSE 10.2 where I succeded to run Lazarus 0.9.31 up to now. After upgrading to 29544, I'm getting this error when trying to build a project /usr/bin/ld: cannot find -lgdk_pixbuf-2.0 Strange thing is, the IDE has no problems to build itself and is obviously not missing libgdk_pixbuf-2.0 I know I should probably upgrade this Linux Installation, otoh, if a simple solution exists... Does anybody know what's wrong here? Thank you Theo Lazarus 0.9.31 r29544 FPC 2.4.2 i386-linux-gtk 2 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Op 2011-02-14 16:00, Felipe Monteiro de Carvalho het geskryf: It is pure speculation to assume that this behavior will remain valid. Well, it seems obvious to me that it should [and would]. From my previous examples, the alias type is still a UnicodeString type. So why wouldn't methods/procedures/functions that take UnicodeString types as parameters work? If the FPC implementation of such a UnicodeString (and the baviour I described) cannot handle such cases, then I would have to say that the FPC implementation would be seriously crippled. Lets hope it doesn't go that route. Not that I care (because Delphi doesn't do everything perfect), but how does Delphi 2010 handle such alias types - especially when passed as parameters (var and const)? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OpenGL conversion
On Mon, 14 Feb 2011 07:51:35 +0200 Juha Manninen juha.mannine...@gmail.com wrote: DeleD has types and functions defined only on Windows. Should be no problem if the Lazarus prog shall only run on windows. ;) At least types: HGLRC PixelFormatDescriptor AFAIR HGLRC is not needed on other platforms and the PFD must be ported depending on the OS specific 'glue-library' for example GLX on Linux. and functions: wglMakeCurrent wglDeleteContext wglCreateContext There are equivalent functions for other platforms glxMakeCurrent etc. (This is context handlig stuff) wglUseFontBitmaps wglUseFontOutlines Not available on other platforms. Can not be ported. You need to emulate these functions (with freetype you should be able to code a multi platform solution). Better replace them with a different text-output function. (Not that easy) SwapBuffers Should call wglSwapBuffers and belongs to the context handling stuff. ZeroMemory Don't know what it does. ChoosePixelFormat SetPixelFormat Needs to be done on context creation and is platform dependend. TOpenGLControl does this for you in Lazarus but AFAIR it is not very flexible regarding the PixelFormat. That is no problem if the Delphi program does not do anything fancy (for example initializing an akkumulation buffer or such nonsense). ActivateRenderingContext Don't know what it does. There are more... So if automatic conversion shall be achieved the converter must know about the platform dependent differences and have functions in place to replace the windows stuff. That is not easy to achieve especially without OpenGL knowledge. Perhaps you want to take a look at $LazarusDir/components/opengl/examples. You will see that the context handling is taken care of by TOpenGLControl so you don't need most of the windows functions you named. I fear at the moment the only way to port the program is by hand. R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On Mon, 14 Feb 2011 11:29:06 +0100, Michael Schnell mschn...@lumino.de wrote: On 02/13/2011 11:15 PM, Bo Berglund wrote: In serial components I have used with Delphi before there was always a property to set the buffer sizes (both Tx and Rx). But I cannot find a way to do this with SdpoSerial. Does SdpoSerial use buffers at all ? With AsyncPro, Buffers necessary to convert the blocking System interface into the event driven AsyncPro user API by doing the blocking system calls in threads. With the receiver, the collected data needs to be buffered until the main thread is available to handle it, With the sender, the data generated by the main thread needs to be buffered until the system API unblocks the interface it blocked to prevent overrun of the system buffers. Without using threads the user just sees a blocking interface and no buffers are necessary. AFAICT SdpoSerial is a wrapper for the Synaser blocking serial component to make it more user friendly by providing receive events when data arrive. And my question is really about the existence of buffers and in that case how to adjust them? I don't want to mess with the component files myself, they are way too intricate, I just want to use the serial comm functions. But I need to know if there will be loss of data if I use a write command with a very big string argument and the communications buffers are not big enough to store this string. What will happen? - Loss of data? - Reverting to blocking operations (ouch!)? Of course I can test it by actually sending a large chunk of data, but then I might use test data that are just a tad too short to reveal a buffer problem. Better to know how it will react. And another important thing should I not need to set a buffer size: How can I know when the data I submitted to SdpoSerial has actually left the serial port on to the wire? A TxBuffer.DataCount property or similar would come in handy here if it existed Bo Berglund -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
On Mon, 14 Feb 2011 14:40:17 +0100, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Mon, 14 Feb 2011 13:06:50 +0100 Bo Berglund bo.bergl...@gmail.com wrote: By accident I just discovered a feature of Lazarus that I was not aware of: I had misnamed a component and wanted to correct it, so I gave it a new name in the property editor. Then I planned on going over the code and change the places where the component was used to the new name. But it was already done! Apparently Lazarus keeps tabs on such renames and changes the places in the form code where the old name was used to the new name! Excellent!! :-) This is something I had wanted in Delphi too... I thought Delphi does that? Only for events that are linked to the component, like OnClick for a button. These change name when the button changes name. But no other references to the button name in code are fixed... then the editor will immediately correct the case of the variables so the code comes out like this: MyVar:= 23; MyOtherVar := MyVar + 56; Ctrl+Space (identifier completion) copies the case. Automatic recasing may be unwanted if the declaration has no casing at all. For example SysUtils is nicer to read than sysutils. I tested with the following: var .. Data: string; begin ... Data := 'something'; Then I changed the declaration to DaTa. If I now put the cursor at the declaration name and hit Ctrl-Space a list is shown that starts with Date. And if I put the cursor in the reference in the code and hit Ctrl-Space a list is shown which starts with DaTa : string; So if I know that an identifer needs to be fixed I can use this shortcut to change it but it won't modify anything else so all other instances of the wrong casing stays the same... I'm not sure, maybe jcf can fix casing. And if I later change the declaration to: Myvar: byte; then the places it is used will change to the new case style. Is there some way one can make this happen in Lazarus? Shift+Ctrl+E renames variables and references. It does not yet find all references, but IMO it is already a useful tool. This actually does work by finding all references to the same identifier within scope and renaming to whatever is put into the editbox. Although not entirely what I was looking for it may still help to clean up the code after typing along without proper casing. -- Bo Berglund Developer in Sweden -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Object Inspector odd behavior (ComboBox issue)
My setup: LCL=carbon (OS X), I build svn daily, and fpc is 2.5.1 from svn A couple of weeks ago, I noticed that *single*-clicking in the Object Inspector actually increments the value of any property displayed with ComboBoxes. That can't be the intended behavior, can it? And then, you can't re-click it to increment it again; you have to drop the list down and *double*-click on an item to select the new value. This seems really strange to me and counter-intuitive. I had to carefully go back through my entire project to make sure I haven't accidentally changed a value simply by single-clicking in the object inspector (several indeed had been changed). Every svn update, I rebuild hoping it's not going to do it anymore, but it still does. I actually hope this is a bug, because it's just really weird. Where would I look in the sources to change this behavior so that it only increments on double-click, not single-click? Related to TComboBox, the behavior on carbon (not sure about other platforms) is not consistent. If it's a read-only list, single-clicking on an item in the drop-down list selects it and the list goes back up. If it's not read-only, you must double-click on a list item to make the list go back up (proper behavior on OS X is for the item to be selected and the list go back up with just a single click). Again, where would I look in the sources to change this behavior? This one is really important for my project, because it goes against the Apple HI Guidelines and might cause my app to get rejected. -- John -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Old OpenSUSE 10.2 and Laz 29544
theo wrote: I have an OpenSUSE 10.2 where I succeded to run Lazarus 0.9.31 up to now. After upgrading to 29544, I'm getting this error when trying to build a project /usr/bin/ld: cannot find -lgdk_pixbuf-2.0 Strange thing is, the IDE has no problems to build itself and is obviously not missing libgdk_pixbuf-2.0 I know I should probably upgrade this Linux Installation, otoh, if a simple solution exists... Does anybody know what's wrong here? Thank you Theo Lazarus 0.9.31 r29544 FPC 2.4.2 i386-linux-gtk 2 Does ls -l /usr/lib/libgdk_pixbuf-2.0* tell you anything useful? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
On Mon, 14 Feb 2011 17:46:35 +0100 Bo Berglund bo.bergl...@gmail.com wrote: [...] On Mon, 14 Feb 2011 14:40:17 +0100, Mattias Gaertner I thought Delphi does that? Only for events that are linked to the component, like OnClick for a button. These change name when the button changes name. But no other references to the button name in code are fixed... Strange. I wonder why. then the editor will immediately correct the case of the variables so the code comes out like this: [...] If I now put the cursor at the declaration name and hit Ctrl-Space a list is shown that starts with Date. I meant if you use Ctrl+Space while writing code the case is automatically copied from the declaration and the editor will immediately correct the case. For example: var Date: string; begin dat| Ctrl+Space will fix this to Date. Note: As I wrote: automatic fixing of not touched code is not always wanted. [...] Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Old OpenSUSE 10.2 and Laz 29544
Mark Morgan Lloyd wrote: Does ls -l /usr/lib/libgdk_pixbuf-2.0* tell you anything useful? No, this lib doesn't seem to be installed here, but this was no problem so far. I haven't even changed the compiler (*2.4.2 [2010/11/22] for i386) I have only upgraded Lazarus from one of the first 0.9.31 versions to *0.9.31 r29544, and now the linker wants libgdk_pixbuf-2.0. As I said, this is when I try to build even the simplest project, the IDE itself builds and runs without complaining about this lib, so it is not strictly necessary it seems. Thank you Theo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On 2/14/2011 11:32, Bo Berglund wrote: AFAICT SdpoSerial is a wrapper for the Synaser blocking serial component to make it more user friendly by providing receive events when data arrive. And my question is really about the existence of buffers and in that case how to adjust them? i don't know if this makes any difference but i'm trudging thru the synapse library attempting to work with its mime coding stuff... in my travels thru the documentation i note that synapse is synchronous instead of asynchronous (see: http://www.ararat.cz/synapse/doku.php/about )... the third and fourth paragraphs are important... since the synapse library has synaser as one of its sub(?)libraries, i assume that we're talking about the same library... the reason i mention the above is because i'm not sure how it might affect what you are attempting to do and if buffers are really needed... it has been a while since i did any comm coding which, at that time, was done directly to the com port or via a FOSSIL driver (which greatly alleviated and abstracted much)... i hope this helps in some small way... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Graeme Geldenhuys schrieb: A simple function like: function CompareText(const S1: UnicodeString; const S2: UnicodeString): integer; should be able to work with any UnicodeString parameters (including alias types that have different encoding bits set). So it should work fine for your UTF-8 text, and somebody else's UTF-16 etc. text. Do you mean that the compiler should convert the strings as needed in the background (as between different integer types and/or floats) so that you can call ListBox1.Items.Add(x) with x beeing UTF8string or UTF16string or...? I am not sure whether this is a good idea because the programmer no longer knows how many conversions take place and therefore cannot judge the performance impact anymore. On the other hand it would make the life easier for beginners. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object Inspector odd behavior (ComboBox issue)
Related to TComboBox, the behavior on carbon (not sure about other platforms) is not consistent. If it's a read-only list, single-clicking on an item in the drop-down list selects it and the list goes back up. If it's not read-only, you must double-click on a list item to make the list go back up (proper behavior on OS X is for the item to be selected and the list go back up with just a single click). Again, where would I look in the sources to change this behavior? This one is really important for my project, because it goes against the Apple HI Guidelines and might cause my app to get rejected. I'm afraid this is how Apple designed Carbon (intentionally i suspect to force everyone to use Cocoa). You can actually test by using Interface Builder. Create a window and place a combobox on it. Add some items to the combobox and run the simulation. You'll see that combobox is behaving in the same. This is possible to fix, but it required some additional efforts, and nobody ever wanted to fix Apple's bugs for them. This bug doesn't present in Cocoa combobox. So it will be working once Cocoa widgetset is mature enough, however it's still Alpha and almost unusable. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object Inspector odd behavior (ComboBox issue)
On Mon, Feb 14, 2011 at 12:07 PM, dmitry boyarintsev skalogryz.li...@gmail.com wrote: I'm afraid this is how Apple designed Carbon (intentionally i suspect to force everyone to use Cocoa). You can actually test by using Interface Builder. Create a window and place a combobox on it. Add some items to the combobox and run the simulation. You'll see that combobox is behaving in the same. This is possible to fix, but it required some additional efforts, and nobody ever wanted to fix Apple's bugs for them. This bug doesn't present in Cocoa combobox. So it will be working once Cocoa widgetset is mature enough, however it's still Alpha and almost unusable. Hmm, didn't know it was a Carbon combobox thing, since I've only every used Cocoa in the past, and it is definitely different. Ok, good enough. However, I'm still curious as to why on earth Object Inspector increments properties on *single*-click. That is just annoying the hell out of me. You can't even click to see the list of available properties without changing the value. I've tried delving into the source but can't locate where to fix this. -- John -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Old OpenSUSE 10.2 and Laz 29544
I was wrong. The libs are there, but they are in /opt/gnome/lib on this system. For a reason, the latest version doesn't find them like the versions before. If I add -Fl/opt/gnome/lib, everything is fine. Thank you Theo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object Inspector odd behavior (ComboBox issue)
On Mon, Feb 14, 2011 at 12:14 PM, John Stoneham captnjamesk...@gmail.comwrote: However, I'm still curious as to why on earth Object Inspector increments properties on *single*-click. That is just annoying the hell out of me. You can't even click to see the list of available properties without changing the value. I've tried delving into the source but can't locate where to fix this. Alright, this is definitely a bug. I tried it on the 0.9.28.2 release and it definitely does not happen there. I can't recall when it started. I'm not sure if it affects other widgets sets. -- John -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] SizeConstraint in Lazarus Form
hi! I'm missing the property Constraints that controls Max Min size of a Form in RunTime. Someone already told something about it? William de Oliveira Ferreira Bacharel em Sistemas de Informação -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Old OpenSUSE 10.2 and Laz 29544
Ah, I thought this was obsolete. I added it to the LCL. Thank you, problem solved. Theo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On Mon, 14 Feb 2011 20:13:45 +0100 José Mejuto joshy...@gmail.com wrote: Hello Lazarus-List, Monday, February 14, 2011, 7:03:31 PM, you wrote: JH Do you mean that the compiler should convert the strings as needed in JH the background (as between different integer types and/or floats) so JH that you can call ListBox1.Items.Add(x) with x beeing UTF8string or JH UTF16string or...? I am not sure whether this is a good idea because the JH programmer no longer knows how many conversions take place and therefore JH cannot judge the performance impact anymore. On the other hand it would JH make the life easier for beginners. I'm unable to see the great problems with UnicodeString. The conversions should be the minimun needed, and they will be. Problem would be in the RTL, but not at user level. Yes, since for example Linux allows non valid UTF-8 as file names, so any auto conversion of file names to UTF-16 is an error. You say that the programmer will not know how many conversions take place, that's right, but I think they are garanteed to be the minimum except in some corner cases like CompareText(UTF8String,WideString) as one of both must be converted, but whichever one, could be a fixed situation or platform dependent, I do not know. Many people are concerned about speed due hidden conversions, so can anybody tell me why ? Maybe I'm blind and I can not see something that is absolutly a problem (except some pieces of RTL). For instance searching needs a lot of compares. Comparing two strings normally fails on the very first characters. An auto conversion will always convert the whole string including allocating and releasing memory, easily slowing down the conversion by an order of magnitude. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On Mon, 14 Feb 2011 13:00:36 -0500, waldo kitty wkitt...@windstream.net wrote: On 2/14/2011 11:32, Bo Berglund wrote: AFAICT SdpoSerial is a wrapper for the Synaser blocking serial component to make it more user friendly by providing receive events when data arrive. And my question is really about the existence of buffers and in that case how to adjust them? i don't know if this makes any difference but i'm trudging thru the synapse library attempting to work with its mime coding stuff... in my travels thru the documentation i note that synapse is synchronous instead of asynchronous (see: http://www.ararat.cz/synapse/doku.php/about )... the third and fourth paragraphs are important... since the synapse library has synaser as one of its sub(?)libraries, i assume that we're talking about the same library... the reason i mention the above is because i'm not sure how it might affect what you are attempting to do and if buffers are really needed... it has been a while since i did any comm coding which, at that time, was done directly to the com port or via a FOSSIL driver (which greatly alleviated and abstracted much)... i hope this helps in some small way... Gosh, I did not know this For TCP/IP work I always use Indy, which is now also available and maintained for freepascal. But in the serial comm projects I am used to components that are non-blocking, which means that a send method returns immediately even before all data have been sent. Then the data are handled by a thread maintained by the component internals (or Windows perhaps). The net effect is that the main application is not blocked and non-responsive while the transfer takes place. In my case I am using SdpoSerial because it is included with FPC/Lazarus. I am sending a data block that potentially can be 1 Mbytes in size over a channel operating at 38400 baud or slower. Theoretically this means a transfer time of 273 seconds (4.5 min) or more. My application must meanwhile give some feedback to the user that the transfer is happening and also how it is proceeding. So I need to know in the case of SdpoSerial that it is possible without data loss to write a string of 1 Mbytes size. I also need to know how I can examine the progress of the transfer so I can control a progress bar or similar on screen while the transfer is running. While the transfer runs my program sits and waits for an ACK coming back from the other end after it has checked the checksum. That is a loop with Application.Processmessages, Sleep and a timeout... In a blocking design this wait loop would of course not have been needed becaus ethe Write would not return until all data have been written to the output. Bo Berglund -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
On Mon, Feb 14, 2011 at 08:13:45PM +0100, Jos? Mejuto wrote: Many people are concerned about speed due hidden conversions, so can anybody tell me why ? Maybe I'm blind and I can not see something that is absolutly a problem (except some pieces of RTL). Typical example is you mix two codebases which have a different opinion about the string type. Then for every transition between those two codebases you have a fair chance that a conversion is needed. It is throughout possible that if you do an Tstringlist.indexof() that you do as many conversions as elements in the stringlist (if your passed stringtype is different from the tstringlist one). A minimum conversion scheme uses one type internally and only converts at the bounderies of the system. But even that has worst cases, e.g. like operating on large database exports in a different format than native. But at least that kind of problems is fairly localised. It is harder if it is everywhere in the codebase, like the former example. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Hello Lazarus-List, Monday, February 14, 2011, 8:29:04 PM, you wrote: I'm unable to see the great problems with UnicodeString. The conversions should be the minimun needed, and they will be. Problem would be in the RTL, but not at user level. MG Yes, since for example Linux allows non valid UTF-8 as file names, MG so any auto conversion of file names to UTF-16 is an error. Hmmm... To me it looks like a Linux problem/bug for that kind of access it is logical to me to use low level APIs. OK, that way you can not access those files ? yes, but also in Windows there are similar problems, some files can not be accessed using regular APIs and some tricks must be used. Many people are concerned about speed due hidden conversions, so can anybody tell me why ? Maybe I'm blind and I can not see something that is absolutly a problem (except some pieces of RTL). MG For instance searching needs a lot of compares. Comparing two MG strings normally fails on the very first characters. An auto conversion MG will always convert the whole string including allocating and releasing MG memory, easily slowing down the conversion by an order of magnitude. This are the some corner cases which can not be handled in the usual conversion, operation, conversion back, but I think there are not much cases like this. Of course, there are cases like a TStringList with 10 items in UTF16 and perform a search using an UTF8String, so or a conversion request to the stringlist (convert all elements in one go) or you must use your unicodestring using default unicode format for the platform. I would like to see an example of such problem (snippet) which could be a headache, but maybe in the fpc mailing lists ? -- Best regards, José -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
Hello Lazarus-List, Monday, February 14, 2011, 8:32:37 PM, you wrote: BB While the transfer runs my program sits and waits for an ACK coming BB back from the other end after it has checked the checksum. That is a BB loop with Application.Processmessages, Sleep and a timeout... BB In a blocking design this wait loop would of course not have been BB needed becaus ethe Write would not return until all data have been BB written to the output. So you can send in small chuncks (64 bytes) and give feedback every 250ms. Or use a send thread. -- Best regards, José -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Hello Lazarus-List, Monday, February 14, 2011, 8:52:27 PM, you wrote: Many people are concerned about speed due hidden conversions, so can anybody tell me why ? Maybe I'm blind and I can not see something that is absolutly a problem (except some pieces of RTL). MvdV Typical example is you mix two codebases which have a different opinion MvdV about the string type. Then for every transition between those two codebases MvdV you have a fair chance that a conversion is needed. It is throughout MvdV possible that if you do an Tstringlist.indexof() that you do as many MvdV conversions as elements in the stringlist (if your passed stringtype is MvdV different from the tstringlist one). But you are in the same trouble if you use any other approach, or you use your data in the same unicode format as the other codebase or you update the codebase to use your new unicode format. There isn't a solution for such situation. I'm currently working with GeckoPort which uses WideString in every place and other special strings. I know that conversions must happend so when I need to scan for a string first convert my data to the native format and them perform the scan. I think expecting a TStringList in ansi encode to work transparently and optimal using unicodestrings is just a dream, programmers should update their codebase, but at least only for speed (reduce autoconversions) and do not need to decide constantly which encoding format is needed to call this or that function. Using a different RTL for each encoding is even worst IMHO. But this is just a simple opinion. -- Best regards, José -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] substr return wrong string with some utf8 char
Michael Schnell schrieb: AFAIK, the decision to use UTF8 is due to Linux using this encoding and so no conversion is done in the LCL system API. IMO more important: no new string and char type (Wide...) is required, no duplicate set of stringhandling procedures. This may be essential for databases and communication as well. This of course is bad with Windows, as here the API uses UTF16 and everything needs to be recoded in the LC System API on entry and exit. The overhead may be neglectable in direct API calls, when these do real work. Strings in (visual) components can be converted once, into the internally used (OS display conforming) representation, and again the conversion overhead can be low until undetectable in the GUI. Supposedly doing different string types - UTF8String vs (a reference counting version of UTF-16-encoded) WideString - for Linux and Windows at the LCL-user-Code interface is too confusing. A *portable* UTF string implementation should be restricted, eliminating direct and indexed access to chars (which become substrings). A dedicated UTF16 class/type can be added at any time, as an optional package. OTOH I agree that the weak (non-existing) distinction between Ansi and UTF8 strings is not pleasing. But here I'd establish a strong boundary between general (Unicode=UTF8) strings, and application specific strings of a single (immutable) codepage - remember that Ansi is not a single specific encoding, instead it's a collection of single-byte-char encodings, including UTF-8. Then the user can choose a specific codepage (or UTF-16) for use inside his application, with e.g. an AppString type. Then it's clear where conversions are required and have to be inserted automatically by the compiler. The Delphi model, with differently encoded strings in the same string type, can result in much uncontrollable conversion overhead, easily outweighting the few possible optimizations with current AnsiStrings (assuming SBCS[1] only). The new ABI also is incompatible with existing DLLs of earlier Delphi/BCB versions, causing trouble with third-party components that are not available in the new ABI. Okay, no such problems exist with open source components, but not all Lazarus add-ons or apps are necessarily open source. [1] With MBCS charsets the same rules apply as to UTF-8, so that UTF-8 can immediately replace all MBCS encodings. So the decision about new string types *only* affects current SBCS Ansi users, even ASCII users are not affected. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
Bo Berglund schrieb: Now I am just wondering what other goodies are hidden in Lazarus? Pleasant surprieses await, no doubt. Have a look at the editor context menu: Refactoring|Rename Identifier... DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Old OpenSUSE 10.2 and Laz 29544
theo kirjoitti maanantai 14 helmikuu 2011 16:15:15: I know I should probably upgrade this Linux Installation, .. FYI: OpenSUSE 10.2 supports zypper dup (= Distro Update). You don't need to download and burn CD images to update your system. It works also in practice, unlike a similar feature in some other distros. Maybe wait till the new version 10.4 before updating. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What happened to TNoteBook?
14.02.2011 23:59, Hans-Peter Diettrich пишет: Felipe Monteiro de Carvalho schrieb: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes#TNotebook_and_TPage In short: Someone implemented TNotebook wrongly and then people started using it as a TPageControl. They should use TPageControl instead and leave TNotebook for it's real purpose, which is a multi-paged control without borders and without tabs. Then at least the example applications should be updated accordingly. It's not a good idea to ship broken examples with a new release :-( Fixed in r29551. Hope it will lessen the number of sad smileys from you. ;) -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object Inspector odd behavior (ComboBox issue)
On Mon, Feb 14, 2011 at 12:30 PM, John Stoneham captnjamesk...@gmail.comwrote: On Mon, Feb 14, 2011 at 12:14 PM, John Stoneham captnjamesk...@gmail.comwrote: However, I'm still curious as to why on earth Object Inspector increments properties on *single*-click. That is just annoying the hell out of me. You can't even click to see the list of available properties without changing the value. I've tried delving into the source but can't locate where to fix this. Alright, this is definitely a bug. I tried it on the 0.9.28.2 release and it definitely does not happen there. I can't recall when it started. I'm not sure if it affects other widgets sets. Just tried Lazarus svn on Ubuntu and single-clicking on a property in the Object Inspector does *not* increment its value -- unlike the weird behavior in the Object Inspector on OS X. Someone who has more familiarity with the source than me will have to determine if it's because of a bug introduced in the carbon widgets sometime after 0.9.28.2, or if it's a bug in the IDE code itself which somehow only shows with the carbon widget set. -- John -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component rename in lazarus...
On Mon, Feb 14, 2011 at 23:40, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Mon, 14 Feb 2011 13:06:50 +0100 Bo Berglund bo.bergl...@gmail.com wrote: And if I later change the declaration to: Myvar: byte; then the places it is used will change to the new case style. Is there some way one can make this happen in Lazarus? Shift+Ctrl+E renames variables and references. It does not yet find all references, but IMO it is already a useful tool. See also http://bugs.freepascal.org/view.php?id=17618 -- Alexander S. Klenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SdpoSerial Tx and Rx buffers?
On 14/02/2011 19:32, Bo Berglund wrote: First one thing, your message subject is too broad: Are we talking about the RX or thr TX buffer? Then, are we talking about the component, the library or the OS buffers? And then are we talking about Windows 32, 64 bits or Linux? It is hard to answer for all cases... But in the serial comm projects I am used to components that are non-blocking, which means that a send method returns immediately even before all data have been sent. Then the data are handled by a thread maintained by the component internals (or Windows perhaps). The net effect is that the main application is not blocked and non-responsive while the transfer takes place. Synaser is blocking both for writing and reading. The SdpoSerial component creates a thread to listen and generates an event when bytes are received. So reading can be non-blocking. The write methods are direct calls to the Synaser ones and they are blocking. In my case I am using SdpoSerial because it is included with FPC/Lazarus. I am sending a data block that potentially can be 1 Mbytes in size over a channel operating at 38400 baud or slower. Theoretically this means a transfer time of 273 seconds (4.5 min) or more. My application must meanwhile give some feedback to the user that the transfer is happening and also how it is proceeding. So I need to know in the case of SdpoSerial that it is possible without data loss to write a string of 1 Mbytes size. In a blocking way (the function will only return when most of the bytes are already sent), all bytes will be transmitted. I also need to know how I can examine the progress of the transfer so I can control a progress bar or similar on screen while the transfer is running. For that, you must break your transmission in small block and use the completion of each transfer to signal the progress. While the transfer runs my program sits and waits for an ACK coming back from the other end after it has checked the checksum. That is a loop with Application.Processmessages, Sleep and a timeout... I don't know if that is an option but I would break such big transmission in smaller packets each one with its own checksum... Paulo Costa -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What happened to TNoteBook?
On 2/14/2011 15:59, Hans-Peter Diettrich wrote: Felipe Monteiro de Carvalho schrieb: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes#TNotebook_and_TPage In short: Someone implemented TNotebook wrongly and then people started using it as a TPageControl. They should use TPageControl instead and leave TNotebook for it's real purpose, which is a multi-paged control without borders and without tabs. Then at least the example applications should be updated accordingly. It's not a good idea to ship broken examples with a new release :-( agreed! +1~ this is a problem that i've run into more than once in the last few years that i've been trying to work with lazarus and FPC... sadly it has caught me out in numerous instances and, being a newbie to the FPC and/or Lazarus environments and methodologies, i don't know what to ask about or where to properly ask... so i read and read and read and hope that i come across a workable answer at some point... but then i operate a lot differently than others, too ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What happened to TNoteBook?
On 2/14/2011 17:33, Maxim Ganetsky wrote: 14.02.2011 23:59, Hans-Peter Diettrich пишет: Felipe Monteiro de Carvalho schrieb: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes#TNotebook_and_TPage In short: Someone implemented TNotebook wrongly and then people started using it as a TPageControl. They should use TPageControl instead and leave TNotebook for it's real purpose, which is a multi-paged control without borders and without tabs. Then at least the example applications should be updated accordingly. It's not a good idea to ship broken examples with a new release :-( Fixed in r29551. Hope it will lessen the number of sad smileys from you. ;) i'm pulling this fix now... hope to see some goodness as well as crossing fingers and hoping that the update methods i've pulled from the wiki operate in cohesion ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OpenGL conversion
- Original Message - From: Juha Manninen juha.mannine...@gmail.com To: Lazarus mailing list lazarus@lists.lazarus.freepascal.org Sent: Monday, February 14, 2011 5:12 AM Subject: [Lazarus] OpenGL conversion Hi Are there any conversion guides or examples of how OpenGL Delphi program can be converted to Lazarus. I would try to automate it with Delphi converter but I don't know much about graphics programming myself. I am testing the converter with DeleD 3-D program which would be an extremely cool porting project. On January Birger Jansen wrote: Project conversion Delphi - FreePascal: success! which mentions OpenGL so it seems to be possible. Juha Hi Juha, IIRC, Freepascal/Lazarus uses the units GL.pas, and GLU.pas as opposed to Delphi's OpenGL.pas. I think this is correct, and I hope this helps :) cheers, Paul -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Does Lazarus support a complete Unicode Component Library?
Op 2011-02-14 21:13, José Mejuto het geskryf: right, but I think they are garanteed to be the minimum except in some corner cases like CompareText(UTF8String,WideString) as one of both must be converted, but whichever one, Exactly, auto-conversion would be kept to a minimum without any user intervention. In the above example CompareText() could quickly check each strings encoding, and if one matches the platform default, that string doesn't need a conversion. So in your example above, if you ran that under Linux, only the second parameter would require an encoding conversion. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OpenGL conversion
Paul Nicholls kirjoitti tiistai 15 helmikuu 2011 04:40:12: Hi Juha, IIRC, Freepascal/Lazarus uses the units GL.pas, and GLU.pas as opposed to Delphi's OpenGL.pas. I think this is correct, and I hope this helps :) Hi Yes, that is the easy part. Delphi converter in Lazarus already replaces the unit names automatically. The problem comes with Windows specific types and calls. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
