[lazarus] Debugging SetCursor in Carbon Lazarus
Hi I'm working with Peter Gannon and Adriaan Van Os on a music app that was ported from Delphi2006 to PC Lazarus, and then ported into a Carbon Lazarus program compiling/debugging in XCode. We have worked out most problems and we are mopping up a few remaining issues. Overall it is working great except for a few niggling problems that are likely bugs to fix in carbon LCL. Have encountered two LCL cursor issues. I fixed one minor cursor problem and will submit a change on that. A couple of entries in the array that maps Laz cursor numbers into AppearanceManager cursor numbers were wrong, so that setting screen.cursor sometimes showed the wrong cursor. Am trying to fix another cursor issue. Would like some more ideas what to look for. Setting screen.cursor seems to work fine. Setting the Cursor property for TButtons and TComboBoxes causes the proper cursor to appear when you move the mouse over it. Perhaps the Cursor property works correctly for many other controls, but Buttons and ComboBoxes are the only two I've verified. However, setting the Cursor property at design-time for a TPaintBox doesn't cause any visible cursor change when you move the mouse over a TPaintBox. And setting a TPaintBox.cursor programmatically doesn't do anything either. Since screen.cursor works, I could fudge our desired behavior with Screen.cursor, but it would be nice to fix the TPaintBox. These TPaintBoxes are embedded in a TPanel, but maybe that isn't a contributor to the bug, because the TButtons whose Cursors work correctly, are embedded in TPanels too. A TButton (which works), descends from TButtonControl which descends from TWinControl which descends from TControl A TPaintBox descends from TGraphicControl which descends from TControl. TControl has a FCursor property and virtual SetTempCursor(). TWinControl inherits the TControl's FCursor, and overrides SetTempCursor. Debug-tracing thru the SetCursor code paths, it looks like a TPaintBox passes thru some TWinControl code, unless XCode is playing tricks on me. So maybe the different heritage of TControl versus TGraphicControl is spurious. LCL is big, and maybe in practice TWinDontrol and TControl work about the same because of some line I haven't noticed. Both the TButton that works, and the TPaintBox that doesn't work, seem to pass thru a similar path on a SetCursor or MouseMove-- involving SetCursor, SetTempCursor. UpdateMousecursor. So does anyone have some ideas on how better to zero-in on the difference which prevents SetCursor from working on a TPaintBox? Thanks. jcjr _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Docking Message window into Source editor
Notes: - It does not handle any other docked window. - It does not fix the positioning code in the IDE for the message If you can given explanations to me which I seek of what you speak? Thanks Mattias -- Laurent. My Web : http://wile64.neuf.fr/ French Forum : http://lazforum-fr.tuxfamily.org/index.php
Re: [lazarus] Debugging SetCursor in Carbon Lazarus
James Chandler Jr wrote: [skip] These TPaintBoxes are embedded in a TPanel, but maybe that isn't a contributor to the bug, because the TButtons whose Cursors work correctly, are embedded in TPanels too. Is TPaintBox.Cursor works when it placed to form (without TPanel layer)? A TButton (which works), descends from TButtonControl which descends from TWinControl which descends from TControl A TPaintBox descends from TGraphicControl which descends from TControl. This is the big difference since TWinControl have own window handle while TGraphicControl do all job through its parent (wich must be TWinControl). So TPaintBox trying to set it cursor through TPanel. Please check if TPanel.Cursor will work. Please create bug tracker report for this problem with test application. This way you will give us ability to reproduce the same situation as you have. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] UTF-8 vs UTF-16 support
Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) * Most widget toolkits and libraries have WideString API's already. (Win32, Xft, Xlib etc..) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, 5 Oct 2007, Graeme Geldenhuys wrote: Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? It uses less memory. These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) It means BufferSize = Length*Sizeof(Widechar). On UTF-8, you need to calculate it. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] More icons
Very little more :( What you chose for the Project icon? -- Laurent. My Web : http://wile64.neuf.fr/ French Forum : http://lazforum-fr.tuxfamily.org/index.php attachment: menu_reopen.png
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, 5 Oct 2007 09:27:59 +0200 Graeme Geldenhuys [EMAIL PROTECTED] wrote: Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) This all assumes UTF-16 has only 2-byte characters, but there are 4-byte characters too. The above is true for UTF-32. * Most widget toolkits and libraries have WideString API's already. (Win32, Xft, Xlib etc..) And all platforms have functions for UTF-8. The main reason is: UTF-8 is more compatible to existing pascal programs, because they use 'string', not widestring. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Michael Van Canneyt schreef: On Fri, 5 Oct 2007, Graeme Geldenhuys wrote: Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? It uses less memory. These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) It means BufferSize = Length*Sizeof(Widechar). On UTF-8, you need to calculate it. I think they mean numofchar(widestring) = bytes allocated / 2. For an UTF8 string you need to parse it, to get the length. So length(widestring) is a O(1) operation, lenght(UTF8String) is a O(n) operation. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Graeme Geldenhuys wrote: Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? Is UTF-16 cover all languages? As I know it have problems with Chinese and/or Japanese languages. While utf-8 doesnot have such problems. More over most software uses English as default language. UTF-8 encoded English words are still the same as non-encoded English words. Btw, I dont know other advantages. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, 5 Oct 2007 09:36:59 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Fri, 5 Oct 2007, Graeme Geldenhuys wrote: Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? It uses less memory. These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) It means BufferSize = Length*Sizeof(Widechar). This works only for 'most' languages, so this trick can only be used for specific applications. A LCL interface should support the full encoding, which means it must calculate the length of UTF-16. On UTF-8, you need to calculate it. @Graeme: google for UTF-8 UTF-16 comparison to find lots of arguments for both sides. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, 05 Oct 2007 16:00:41 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? Is UTF-16 cover all languages? As I know it have problems with Chinese and/or Japanese languages. While utf-8 doesnot have such problems. More over most software uses English as default language. UTF-8 encoded English words are still the same as non-encoded English words. Btw, I dont know other advantages. UTF-8, UTF-16 and UTF-32 are just different encodings for the same unicode characterset. UTF-16 is often confused with UCS-2, which is indeed only 2-byte characters and has the widestring advantage (length=#words). But for the price, that it does not support all characters. That's why M$ switched from UCS-2 to UTF-16 keeping the W functions, which may be one of the main reasons for the confusion. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On 10/5/07, Mattias Gaertner [EMAIL PROTECTED] wrote: On Fri, 05 Oct 2007 16:00:41 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? Is UTF-16 cover all languages? As I know it have problems with Chinese and/or Japanese languages. While utf-8 doesnot have such problems. More over most software uses English as default language. UTF-8 encoded English words are still the same as non-encoded English words. Btw, I dont know other advantages. UTF-8, UTF-16 and UTF-32 are just different encodings for the same unicode characterset. UTF-16 is often confused with UCS-2, which is indeed only 2-byte characters and has the widestring advantage (length=#words). But for the price, that it does not support all characters. That's why M$ switched from UCS-2 to UTF-16 keeping the W functions, which may be one of the main reasons for the confusion. As far as I know the Unicode organization no longer support in UCS-2 and recommend that any implementation of such encoding will be used as UTF-16. Another issue, is that on UTF-8 I think that some of the languages such as Korean and Japanese does not include all of the symbols it requires, but I'm not sure. I believe that all the encoding should be supported, and be used according to the way that the developers of the software will decide rather then to force them in choosing specific encoding. Mattias Ido -- http://ik.homelinux.org/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] PkgOptionsDlg has no form?
On Fri, 05 Oct 2007 03:21:16 +0100 Luis Rodrigues [EMAIL PROTECTED] wrote: Hi, In my i18n work i've been looking at the package system and have a quick question: Why is the form sometimes built with code? why is there no .lfm file. Two reasons: Either the dialog was created long ago as some features of the IDE designer were not ready Or it was planned to create dynamic content. This happens in a unit I need to change: PkgOptionsDlg.pas I this case both reasons became obsolete, so feel free to convert it to a .lfm. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
Graeme Geldenhuys wrote: Hi, I asked a similar question in the MSEgui newsgroup as well. What was the reason for choosing to support UTF-8 instead of UTF-16? - Quoted Mattias from 6 months ago -- The LCL will support UTF-8 and provide some extra functions for UTF-16, because UTF-8 is more compatible to existing pascal programs --- END -- Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? These are the pro points I received for using UTF-16 in MSEgui. * It is faster to work with UTF-16 (and so WideString) encoded text compared to UTF-8. * Easier to implement. * WideString allows indexed [] accessing individual chars. * Has predictable length() value. (not sure what they meant here) * Most widget toolkits and libraries have WideString API's already. (Win32, Xft, Xlib etc..) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives * WideString allows indexed [] accessing individual chars. This does not seem to be correct. I read that utf16 can be 4 byte long.. Then calculation is needed sometimes... Marton Papp _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] a litle question about freevision
I think lazarus must include all fpc packages. I want to create TProjectFileDescriptor descendants for freevision Application, Desktop, Window, etc. Maybe is good that lazarus user's, know fpc include a TurboVision replacement. (Sorry my bad english). Thanks Vincent. 2007/10/4, Vincent Snijders [EMAIL PROTECTED]: Carlos German Tejero schreef: Why the fpc bundled in the lazarus-win32 installer don't include freevision?? Because Lazarus does not need that. I never thought anybody would use Lazarus to create freevision applications. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Carlos Germán Tejero
Re: [lazarus] a litle question about freevision
I think lazarus must include all fpc packages. I want to create TProjectFileDescriptor descendants for freevision Application, Desktop, Window, etc. Maybe is good that lazarus user's, know fpc include a TurboVision replacement. (Sorry my bad english). Thanks Vincent. Sorry for the previous two mail. 2007/10/4, Vincent Snijders [EMAIL PROTECTED]: Carlos German Tejero schreef: Why the fpc bundled in the lazarus-win32 installer don't include freevision?? Because Lazarus does not need that. I never thought anybody would use Lazarus to create freevision applications. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Carlos Germán Tejero
Re: [lazarus] a litle question about freevision
Carlos German Tejero schreef: I think lazarus must include all fpc packages. I want to create TProjectFileDescriptor descendants for freevision Application, Desktop, Window, etc. Maybe is good that lazarus user's, know fpc include a TurboVision replacement. (Sorry my bad english). Maybe it is better to use the fp ide to create freevision applications. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, 5 Oct 2007 10:45:18 +0200 ik [EMAIL PROTECTED] wrote: On 10/5/07, Mattias Gaertner [EMAIL PROTECTED] wrote: On Fri, 05 Oct 2007 16:00:41 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: Does this mean UTF-8 was chosen only because it is more compatible with existing pascal programs? Any other reasons? Is UTF-16 cover all languages? As I know it have problems with Chinese and/or Japanese languages. While utf-8 doesnot have such problems. More over most software uses English as default language. UTF-8 encoded English words are still the same as non-encoded English words. Btw, I dont know other advantages. UTF-8, UTF-16 and UTF-32 are just different encodings for the same unicode characterset. UTF-16 is often confused with UCS-2, which is indeed only 2-byte characters and has the widestring advantage (length=#words). But for the price, that it does not support all characters. That's why M$ switched from UCS-2 to UTF-16 keeping the W functions, which may be one of the main reasons for the confusion. As far as I know the Unicode organization no longer support in UCS-2 and recommend that any implementation of such encoding will be used as UTF-16. Another issue, is that on UTF-8 I think that some of the languages such as Korean and Japanese does not include all of the symbols it requires, but I'm not sure. I believe that all the encoding should be supported, and be used according to the way that the developers of the software will decide rather then to force them in choosing specific encoding. For compatibility, complexity and usability reasons the LCL should use only one encoding. For example TControl.Caption is a string on all platforms. There will be no CaptionW or CaptionA or CaptionUTF32, because this would be more confusing than it would help. Of course FPC/Laz provides converter functions for those prefering widestring or UTF-16 or UTF-32. The LCL are visual components, so the speed cost of converting the strings is hardly measurable against the cost of drawing the unicode characters on the screen. OTOH it can matter if you often traverse a tree with ten thousand nodes. Looking at the lazarus code the LCL encoding of UTF-8 was a good choice, because the multibyte encoding is only important in synedit and the LCL interfaces. With UTF-16 additional conversions would be needed for all text file operations including codetools, which would slow down a lot. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
On 10/5/07, Luca Olivetti [EMAIL PROTECTED] wrote: Unless you're dealing with klingon and ancient languages, I think you can assume that for 99.99% of currently spoken languages every character will be exactly 2 bytes long. You are forgetting about chinese. Some billion people speak it =) And you can't represent all chinese characters with ucs-2 -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] UTF-8 vs UTF-16 support
En/na [EMAIL PROTECTED] ha escrit: * WideString allows indexed [] accessing individual chars. This does not seem to be correct. I read that utf16 can be 4 byte long.. Then calculation is needed sometimes... Unless you're dealing with klingon and ancient languages, I think you can assume that for 99.99% of currently spoken languages every character will be exactly 2 bytes long. There's a risk of having some character with more that 2 bytes but it is a small risk. With utf-8 the risk is bigger, so you have always to traverse the string if you need access to a specific character index. -- Luca _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] a litle question about freevision
Graeme Geldenhuys schreef: On 05/10/2007, Vincent Snijders [EMAIL PROTECTED] wrote: Maybe it is better to use the fp ide to create freevision applications. I tend to disagree... Not sure if it exists, but maybe Lazarus should ship _without_ the compiler packaged as an option. I for one develop non-LCL based applications all day with Lazarus. They may not be FreeVision application, but they sure ain't LCL ones either. Why?? Because Lazarus is a brilliant IDE. Cool plugin/packages support (Editor Toolbar and Procedure List come to mind), nice searching (Find in Files) plus all the other nice things like Code Completion, parameter hints, jumping between the Interface and Implemenation of code etc... The FP IDE as far as I know doesn't support most of what I mentioned. I wouldn't want to use any other editor for my Object Pascal development. But it supports debugging of console applications better. And that is why I would suggest fp ide for freevision applications. Just the other day I needed to setup a Windows PC with Lazarus and FPC 2.2. I had to download the bundled Lazarus+FPC 2.0.4 setup (the only windows choice), just to delete all the FPC 2.0.4 directories and replace it with FPC 2.2. I think that's a waste. As far as I remember the Linux and Mac OS X versions of Lazarus doesn't come bundled with FPC. A. You don't need to remove fpc 2.0.4, unless your hard disk is too full. B. The Lazarus packages for Linux and Mac OS X are for one fpc version too, so if you changed version, you'd to redownload a different Lazarus package too. C. If you want to use a fpc version different for the supplied one, just install that version for example in c:\fpc\2.2.0 and adjust the paths in the environment options. If you have a previous installed Lazarus and want to continue to use that, use that, otherwise download a source zip. If you change fpc version, you need to (re-)compile the LCL (anyhow). Conclusion: I am not convinced (yet) :-). Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] patch for editbtn.pas
Paul Ishenin ha scritto: Giuliano Colla wrote: Paul Ishenin ha scritto: I dont like bliny and kvass too much and I never followed chess matches :) I prefere beer, eat sometimes hot dogs and drinking coke :) But I've found that you DO live in Krasnoyarsk, which was just the first Russian town name who came to my mind when I was thinking of a russian stereotype! :) However I agree with you about chess and kvass, and also about bliny, if you stuff them with smetana, but if you stuff them with caviar, then they become quite palatable ;-) Giuliano -- Giuliano Colla Still using C++ and Visual Studio? I'm using Object Pascal and Lazarus. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] a litle question about freevision
On 05/10/2007, Vincent Snijders [EMAIL PROTECTED] wrote: Maybe it is better to use the fp ide to create freevision applications. I tend to disagree... Not sure if it exists, but maybe Lazarus should ship _without_ the compiler packaged as an option. I for one develop non-LCL based applications all day with Lazarus. They may not be FreeVision application, but they sure ain't LCL ones either. Why?? Because Lazarus is a brilliant IDE. Cool plugin/packages support (Editor Toolbar and Procedure List come to mind), nice searching (Find in Files) plus all the other nice things like Code Completion, parameter hints, jumping between the Interface and Implemenation of code etc... The FP IDE as far as I know doesn't support most of what I mentioned. I wouldn't want to use any other editor for my Object Pascal development. Just the other day I needed to setup a Windows PC with Lazarus and FPC 2.2. I had to download the bundled Lazarus+FPC 2.0.4 setup (the only windows choice), just to delete all the FPC 2.0.4 directories and replace it with FPC 2.2. I think that's a waste. As far as I remember the Linux and Mac OS X versions of Lazarus doesn't come bundled with FPC. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] a litle question about freevision
On 05/10/2007, Vincent Snijders [EMAIL PROTECTED] wrote: But it supports debugging of console applications better. And that is why I would suggest fp ide for freevision applications. Fair enough. I've spent all of 30 minutes with the FP IDE so take your word for it. ;-) A. You don't need to remove fpc 2.0.4, unless your hard disk is too full. Personally I don't like FPC inside the Lazarus directory... but hey, that's just me, and surely must have make the installation easier under Windows. use that, otherwise download a source zip. If you change fpc version, you need to (re-)compile the LCL (anyhow). Yup, that's what I do... I just needed a Lazarus.exe to do the recompile, though it that case I guess I could just as well have downloaded the Lazarus source only and do a make from the command line. I'll remember it for next time. :) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TRegistry crash on Mac OS X
Dominique Louis napsal(a): As mentioned I'm porting a Delphi app to Mac OS X and noticed that every time it tries to make use of the TRegistry functions an AV occurs. Does anyone know why this may be happening, and also where does it save these Registry settings? I have just tested it and it works well for me. The TRegistry should be saved to reg.xml file in the same dir as the executable. Please create a bug report with further description. Tom _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Debugging SetCursor in Carbon Lazarus
Thanks very much Paul. I'll check that this morning. jcjr On Oct 5, 2007, at 2:57 AM, Paul Ishenin wrote: James Chandler Jr wrote: [skip] These TPaintBoxes are embedded in a TPanel, but maybe that isn't a contributor to the bug, because the TButtons whose Cursors work correctly, are embedded in TPanels too. Is TPaintBox.Cursor works when it placed to form (without TPanel layer)? A TButton (which works), descends from TButtonControl which descends from TWinControl which descends from TControl A TPaintBox descends from TGraphicControl which descends from TControl. This is the big difference since TWinControl have own window handle while TGraphicControl do all job through its parent (wich must be TWinControl). So TPaintBox trying to set it cursor through TPanel. Please check if TPanel.Cursor will work. Please create bug tracker report for this problem with test application. This way you will give us ability to reproduce the same situation as you have. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] crash on compiler-options
Hi all, Beginner in Lazarus, experience in Delphi since 1.0 Installed snapshot 20071005 on winXP. Open Compiler Options, click on tab Messages A lot of jittering on the tab and then: Unknow RT Error 202 OK to ignore, Cancel to kill. Cancel kills the IDE, ignoring and trying again kills the IDE without asking. Must be something simple I guess? Kind regards, John _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] crash on compiler-options
On 10/5/07, John vd Waeter [EMAIL PROTECTED] wrote: Hi all, Beginner in Lazarus, experience in Delphi since 1.0 Installed snapshot 20071005 on winXP. Open Compiler Options, click on tab Messages A lot of jittering on the tab and then: Unknow RT Error 202 OK to ignore, Cancel to kill. It's a reported bug. See reports: http://www.freepascal.org/mantis/view.php?id=9494 http://www.freepascal.org/mantis/view.php?id=9631 http://www.freepascal.org/mantis/view.php?id=9583 Regards, Gerard.
Re: [lazarus] More icons
2007/10/5, Paul Ishenin [EMAIL PROTECTED]: wile64 пишет: Very little more :( What you chose for the Project icon? As I know project4.png had the best feedback (2 pro 0 contra) :) Best regards, Paul Ishenin. Like this? -- Laurent. My Web : http://wile64.neuf.fr/ French Forum : http://lazforum-fr.tuxfamily.org/index.php attachment: open_project.pngattachment: project_new.pngattachment: save_project.pngattachment: saveas_project.pngattachment: project_inspector.pngattachment: close_project.pngattachment: project_options.png
Re: [lazarus] TRegistry crash on Mac OS X
Hi Tom, I'll step through the code this week-end and write something up. Dominique. Tom Gregorovic wrote: Dominique Louis napsal(a): As mentioned I'm porting a Delphi app to Mac OS X and noticed that every time it tries to make use of the TRegistry functions an AV occurs. Does anyone know why this may be happening, and also where does it save these Registry settings? I have just tested it and it works well for me. The TRegistry should be saved to reg.xml file in the same dir as the executable. Please create a bug report with further description. Tom _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Docking Message window into Source editor
2007/10/5, wile64 [EMAIL PROTECTED]: Notes: - It does not handle any other docked window. - It does not fix the positioning code in the IDE for the message If you can given explanations to me which I seek of what you speak? Thanks Mattias There is nobody other which can explain or link towards explanations? I would like to understand :) Regards -- Laurent. My Web : http://wile64.neuf.fr/ French Forum : http://lazforum-fr.tuxfamily.org/index.php
Re: [lazarus] Docking Message window into Source editor
On Fri, 5 Oct 2007 08:39:51 +0200 wile64 [EMAIL PROTECTED] wrote: Notes: - It does not handle any other docked window. - It does not fix the positioning code in the IDE for the message If you can given explanations to me which I seek of what you speak? The first is just a fact. It is no problem, as long as no other window is docked to the source editor window. The second: The IDE positions/hides/shows the message window at various places. For example when you select 'restore' in the environment options for the message window, the window is not restored, but is positioned too wide left and up. Probably there are more cases. IMO not serious. Such things should be handled by a dock manager. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
