Re: [lazarus] Debugging SetCursor in Carbon Lazarus
James Chandler Jr wrote: I need to go back and look more closely, but cursor-setting (for both controls whose cursors work and controls whose cursors don't work) eventually passes thru a SetTempCursor(). But there may be more than one instance of a SetTempCursor() method in there somewhere. Would need to look closer. I think that CarbonCommon_SetCursor (CarbonPrivateCommon.inc) brings problem. function CarbonCommon_SetCursor(... ... ACursor := Screen.Cursor; if ACursor = crDefault then begin ACursor := AWidget.LCLObject.Cursor; <-- here is problem end; WidgetSet.SetCursor(Screen.Cursors[ACursor]); ... AWidget.LCLObject is TWinControl, so all the time it will parent of our graphic control. To solve problem we must search for child Controls (not WinControls) that are placed on our AWidget.LCLObject. Carbon is the most difficult (for developing) widgetset for me since I have no Mac :) I hope you or Tomas or Felipe can fix problem. Or I will try myself but later. Best regards, Paul Ishenin. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
Just tried to being implementing this for but it to work there would have to be a function TLRSObjectReader.GetStackPath(Root: TComponent): string; for me to use in procedure TDefaultTranslator.TranslateStringProperty to get the component path Ideias? please Luís On Mon, 2007-10-08 at 01:39 +0100, Luis Rodrigues wrote: > > > ... > > Good questions. > > > In big project using third party packages you will easily get value > > > clashes. And the same value must be translated differently depending > > > on the context. So merging would be fatal. > > > I'm not sure, how the lcltranslator should know, where to lookup up > > > the translations for each unit. Maybe the IDE should create lists > > > which unit belongs to which package/project and put this for example > > > into an include file. > > > > > > > > > > Is some languages are already translated how should that be handled? > > > > > > There is the tools/updatepofiles tool. It is not yet integrated > > > into the IDE. > > > > Has anybody ideas, suggestions, remarks? > > > > Just a taught, maybe we could store the translation String in the .po as > msgid "FORM1.LABEL1.Caption=hello I'm Luis" > msgstr "Ola eu sou o luis" > > then the LRSTranslator would search for the translation of > "FORM1.LABEL1.Caption=hello I'm Luis" and not "hello I'm Luis". With ths > solution we would never the problem of value clashes. I also don't think > it would create a problem for the translators. > > Would also have to find a solution of the .rst conversion since this one > is only good for the forms. > > > _LR_ > > > > > Mattias > > > > _ > > 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 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
> > ... > Good questions. > > In big project using third party packages you will easily get value > > clashes. And the same value must be translated differently depending > > on the context. So merging would be fatal. > > I'm not sure, how the lcltranslator should know, where to lookup up > > the translations for each unit. Maybe the IDE should create lists > > which unit belongs to which package/project and put this for example > > into an include file. > > > > > > > Is some languages are already translated how should that be handled? > > > > There is the tools/updatepofiles tool. It is not yet integrated > > into the IDE. > > Has anybody ideas, suggestions, remarks? > Just a taught, maybe we could store the translation String in the .po as msgid "FORM1.LABEL1.Caption=hello I'm Luis" msgstr "Ola eu sou o luis" then the LRSTranslator would search for the translation of "FORM1.LABEL1.Caption=hello I'm Luis" and not "hello I'm Luis". With ths solution we would never the problem of value clashes. I also don't think it would create a problem for the translators. Would also have to find a solution of the .rst conversion since this one is only good for the forms. _LR_ > > Mattias > > _ > 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
Re: [lazarus] App Localization
Great thanks for your fixes. My knowledge if the Lazarus internals is not that good :( Before going on to packages I still have a problem: several components (including my TChat) have TStrings properties that should also be on the translation list. Should this be done for all od add a option in Project Options? Luís On Sat, 2007-10-06 at 16:04 +0200, Mattias Gaertner wrote: > On Sat, 6 Oct 2007 14:47:59 +0200 > Mattias Gaertner <[EMAIL PROTECTED]> wrote: > > > On Wed, 03 Oct 2007 18:51:24 +0100 > > Luis Rodrigues <[EMAIL PROTECTED]> wrote: > > > >[...] > > > > > > It collects the .rst and .lrt file for each project file - > > > > > > even if the file > > > > > does > > > > > > not belong to the project. Add a check > > > > > > (Project1.Files[i].IsPartOfProject). > > > > > > > > > > thanks done > > > > > > > > > > > It puts them all together into one stringlist and checks with > > > > > > a linear > > > > > search > > > > > > for doubles. That's too slow for the several thousand strings. > > > > > > > > > > You are right. just rewrote it, but the insert into .po is still > > > > > O(n*m) where m=number of items in .po and n number of total > > > > > strings in forms > > > > > > > > > > Do you think as is is acceptable or should I implement a better > > > > > method? I did it like this so I would not overwrite whatever the > > > > > user as already changed in .po between compiles. > > > > > > > > Too slow. For example the IDE has more than 3000 strings for 70 > > > > forms. Other projects have hundreds of forms. So, it should work > > > > with m=10.000 and n=10.000. So, goal is O((n+m)*log(m)). > > > > > > I should have thought about that. Now I load everything into a > > > hashtable so it's O(m) where M is number of strings in modified > > > files. > > > > Good idea, but TStringHashList will not work in this case. Its > > internal hash function only uses the first 30 characters for the > > hash, but the lrt identifiers are often longer and starts with the > > same 30 characters. For example: > > TCustomApplicationOptionsForm.EClassName > > So the TStringHashList will be a linear search here. > > Maybe I will improve it. > > Sorry, I just saw, that it looks up the values, not the names. I guess > for values the problem is not that big. > > > >[...] > > Minor ToDos: > > - AddFiles2Po: Reduce the amount of temporary strings. > > - Replace TStringHashList with a TStringToStringTree or a hash list > > with a better hash function. > > - Use AddFiles2Po and something similar to UpdateProjectPOFile for > > packages. The existing packages, that already have .po files must > > combine the existing translations for the new system. This must be > > announced and described in the wiki. > > > > I just tested it, and found a design flaw. > > The currently created lrt files look like this: > > TFORM1.CAPTION=Form1 > > TBUTTON.CAPTION=Button1 > > TBUTTON.CAPTION=Button2 > > > > Obviously the property paths are ambiguous. The only guaranteed path > > would be the full lfm path: > > TForm1.ComponentName.SubComponentName...SubPersistent.PropertyName > > > > I will improve it. > > Done. > > > > > How should the packages .po files be integrated into the > > > application .po? > > > Should they just be called packages.po and merged all together? > > > > Good questions. > > In big project using third party packages you will easily get value > > clashes. And the same value must be translated differently depending > > on the context. So merging would be fatal. > > I'm not sure, how the lcltranslator should know, where to lookup up > > the translations for each unit. Maybe the IDE should create lists > > which unit belongs to which package/project and put this for example > > into an include file. > > > > > > > Is some languages are already translated how should that be handled? > > > > There is the tools/updatepofiles tool. It is not yet integrated > > into the IDE. > > Has anybody ideas, suggestions, remarks? > > > Mattias > > _ > 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
Re: [lazarus] UTF-8 vs UTF-16 support
On Fri, Oct 05, 2007 at 01:14:23PM +0200, Luca Olivetti wrote: > 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, Like Chinese? Just a billion people use it...not a real problem at all... :-\ > I think you can assume that for 99.99% of currently spoken languages every > character will be exactly 2 bytes long. Wrong as I said before. > 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. You have to go through the string for UTF-8 and UTF-16 encodings so the advantages are at least questionable... ciao -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Mac FPC/Lazarus project, SpeedButtons with Transparency
Great! I'll grab a snapshot tomorrow night. Peter Gannon wrote: I downloaded and installed the latest build of Lazarus, and can confirm that the SpeedButton transparency is working great in our Carbon program. Thanks again Peter _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch: codetools/directorycacher.pas (fixes finding files)
Hello Matthias, I'm afraid it is not fixed. I had spent hours to verify the validity of my submission. It really really is the wrong search function. With this search function, you just don't find some files. The list has been sorted with a different search function. Also, the binary search algorithm does not search in any "direction". It uses two indices, one starting at 0 and the other starting at FListing.NameCount-1. So the whole list is searched, and if you use the correct search function, then you will find it without looking in another direction. Cheers, Tobias Matthias wrote: > The problem was probably something that the algorithm only searched in > one direction, not the wrong search function. Can you test, if it is > fixed? as a reply to my original submission: > > I would like to submit the attached patch. I noticed that some of my > > source files could not be found by the IDE. The reason is that in > > TCTDirectoryCache.FindUnitSource, the binary search uses a different > > comparison function from the one that FListing was originally sorted > > with. > > > > Sorting a list with one comparison function, then doing a binary > > search with a different one, can cause the binary search to fail. > > > > On Mac OS X, the binary search failed when filenames with underscores > > were used. Some comparison functions sort the underscore _ before the > > letters, while other comparison functions sort the underscore after > > the letters. _ 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
Please create a bug report for fpc (not lazarus) (http://www.freepascal.org/mantis) and attach your files to the bug-report. Joost. Op zondag 07-10-2007 om 23:05 uur [tijdzone +0200], schreef Tobias Giesen: > Hello, > > there are one or two bugs in xmlreg.pp that can cause crashes. > > I am talking about the xmlreg.pp in fpcsrc\packages\fcl-registry\src. > > Around line 355, it is not verified whether Node.FirstChild is nil. > > Around line 720, the function does not return any value. > > I have copied the file into my project directory and made some fixes. > Luckily, the fpc compiler now uses my version rather than the default > version. > > I don't know how to submit the fixes so I've put the updated file here: > http://www.superflexible.com/xmlreg.pp > > Cheers, > Tobias Giesen > > > _ > 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
Re: [lazarus] TRegistry crash on Mac OS X
There are detailed instructions about how to create a patch here: http://wiki.lazarus.freepascal.org/Creating_A_Patch They are mostly about lazarus, but should apply to fpc too. In you case you should download the fpc source code from subversion, substitute your file on the currect place, and then do a svn diff > mypatch.patch Also check the .patch file to see if there aren't any sincronization issues (changes that conflict with yours). And then submit it to fpc guys. I'm not sure exactly where, maybe on the bug tracker or on fpc-devel mailling list. -- Felipe Monteiro de Carvalho _ 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
Hello, there are one or two bugs in xmlreg.pp that can cause crashes. I am talking about the xmlreg.pp in fpcsrc\packages\fcl-registry\src. Around line 355, it is not verified whether Node.FirstChild is nil. Around line 720, the function does not return any value. I have copied the file into my project directory and made some fixes. Luckily, the fpc compiler now uses my version rather than the default version. I don't know how to submit the fixes so I've put the updated file here: http://www.superflexible.com/xmlreg.pp Cheers, Tobias Giesen _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Mac FPC/Lazarus project, SpeedButtons with Transparency
I downloaded and installed the latest build of Lazarus, and can confirm that the SpeedButton transparency is working great in our Carbon program. Thanks again Peter - Original Message - From: "Peter Gannon" <[EMAIL PROTECTED]> To: Sent: Saturday, October 06, 2007 10:12 AM Subject: Re: [lazarus] Mac FPC/Lazarus project, SpeedButtons with Transparency Is their a way to get SpeedButtons with transparency on Mac/Lazarus/FPC ? <<< Tom: This should be fixed in svn revision 12349. Thanks Tom! Looking forward to it. Peter - Original Message - From: "Tom Gregorovic" <[EMAIL PROTECTED]> To: Sent: Saturday, October 06, 2007 8:05 AM Subject: Re: [lazarus] Mac FPC/Lazarus project, SpeedButtons with Transparency Dominique Louis napsal(a): You beat me to it, I'm also porting a rather large commerical Delphi app to Mac OS X and found the same problem. Also while I'm here, is there a RichTextEdit component for Mac OS X? Certiainly for example MLTE, but I don't know any implemented for Lazarus. Dominique. Peter Gannon wrote: As described in a previous email, we have converted a Delphi/Windows music program to Mac/FPC/Lazarus (Carbon widgets), with great success. I have a question about SpeedButtons. Do they have a transparency property? On Delphi and FPC/Lazarus/Windows , if Flat property is set to true, it behaves transparenttly, but not on Mac/Lazaurus. Is their a way to get SpeedButtons with transparency on Mac/Lazarus/FPC ? This should be fixed in svn revision 12349. Tom _ 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 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] r12175/gtk1 doublebuffering causes huge slowdowns
Since revision r12175 Lazarus/synedit responds very slow on each keypress. (approx 5 sec) I'm using linux/gtk1 through vnc. I didn't test locally, but since I didn't hear anybody else about this problem, I guess the problem is only noticeable through vnc. Joost _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Strange Parameter being passed to .app on startup...
Hi all, The basic conversion is now over, so the debugging begins. When the application is started via the Application Bundle a strange parameter is passed to the executable as the first parameter. The parameter looks like this "-psn_0_", where the ns represent some number value that changes every time the application is run. What is this parameter? This application uses the first parameter to load up a data file, so this is throwing things out abit. Any guidance welcome. Dominique. _ 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
Hi, I was surfing wikipedia and I found a good reason why not to use UCS-2. It seams to be prohibited to distribute software in mainland china that only partially supports the chinese characters (like is the case for UCS-2). Source: http://en.wikipedia.org/wiki/GB18030 "In a move of historic significance for software supporting Unicode, the PRC decided to mandate support of certain code points outside the BMP. This means that software can no longer get away with treating characters as 16 bit fixed width entities (UCS-2). Therefore they must either process the data in a variable width format (such as UTF-8 or UTF-16), which are the most common choices, or move to a larger fixed width format (such as UCS-4 or UTF-32). Microsoft made the change from UCS-2 to UTF-16 with Windows 2000." Of course, if your don't plan on distributing software on China, this is irrelevant, but a general purpose library needs to take this into account. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
