Re: [lazarus] [patch] printers4lazarus
- Original Message - From: "Christian Ulrich" <[EMAIL PROTECTED]> To: Sent: Tuesday, January 17, 2006 2:14 PM Subject: Re: [lazarus] [patch] printers4lazarus > > - PDev.Device:=PDev.DevMode.dmDeviceName; > > +// PDev.Device:=PDev.DevMode.dmDeviceName; > > sorry, was just a test [..] > > Christian > Thanks, Applied with changes. Jesus Reyes A. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug 0001055 Form autoscroll and Control.Align=alTop
On Tue, 2006-01-17 at 23:27, L505 wrote: > > > > Salvatore, > > > > So if I understand correctly, your panel is not put on the top of the > > form when you set the align property to alTop? It sure seems to be from > > your screenshot! > > > AlTop should place the panel at the top maximized widthwise. It is not > maximized > widthwise in the picture. Hence my remark. Either it's not set to alTop, or there's some bug that prevents alTop from working in the first place. Darius _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] patch to WidgetDebugReport
I've done some improvements of DebugReports
Darek
Index: lcl/interfaces/gtk/gtkproc.inc
===
--- lcl/interfaces/gtk/gtkproc.inc (wersja 8546)
+++ lcl/interfaces/gtk/gtkproc.inc (kopia robocza)
@@ -751,6 +751,7 @@
else begin
Result:=Result+'FG[N]:='+GdkColorToStr(@AStyle^.fg[GTK_STATE_NORMAL])+' ';
Result:=Result+'BG[N]:='+GdkColorToStr(@AStyle^.bg[GTK_STATE_NORMAL])+' ';
+
Result:=Result+'Base[N]:='+GdkColorToStr(@AStyle^.base[GTK_STATE_NORMAL])+' ';
Result:=Result+'BG_Pixmap[N]:='+DbgS(AStyle^.bg_pixmap[GTK_STATE_NORMAL])+' ';
Result:=Result+'rc_style='+GetRCStyleDebugReport(AStyle^.rc_style);
end;
@@ -767,6 +768,10 @@
{$IFDEF GTK1}
Result:=Result+'font_name="'+AStyle^.font_name+'" ';
Result:=Result+'fontset_name="'+AStyle^.fontset_name+'" ';
+Result:=Result+'FG[N]:='+GdkColorToStr(@AStyle^.fg[GTK_STATE_NORMAL])+' ';
+Result:=Result+'BG[N]:='+GdkColorToStr(@AStyle^.bg[GTK_STATE_NORMAL])+' ';
+
Result:=Result+'Base[N]:='+GdkColorToStr(@AStyle^.base[GTK_STATE_NORMAL])+' ';
+Result:=Result+'flagi:='+intTostr(AStyle^.color_flags[GTK_STATE_NORMAL])+'
';
{$ELSE GTK1}
{$WARNING TODO find GTK2 font naming}
{$ENDIF GTK1}
@@ -796,6 +801,10 @@
Result:=Result+'D';
if GTK_WIDGET_CAN_FOCUS(Widget) then
Result:=Result+'F';
+if GTK_WIDGET_RC_STYLE(Widget) then
+ Result:=Result+'St';
+if GTK_WIDGET_PARENT_SENSITIVE(Widget) then
+ result:=result+'Pr';
end;
Result:=Result+']';
end;
Re: [lazarus] bug 0001055 Form autoscroll and Control.Align=alTop
> Salvatore, > > So if I understand correctly, your panel is not put on the top of the > form when you set the align property to alTop? It sure seems to be from > your screenshot! AlTop should place the panel at the top maximized widthwise. It is not maximized widthwise in the picture. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bug 0001055 Form autoscroll and Control.Align=alTop
Salvatore, So if I understand correctly, your panel is not put on the top of the form when you set the align property to alTop? It sure seems to be from your screenshot! Darius On Tue, 2006-01-17 at 22:21, SALVATORE COPPOLA wrote: > Hi, > in the shot there is what I reported in the issoue 0001055 and it is still > there (recent Lazarus SVN) . Should I reopen the issoue or is exected > behavior? > Regards > Salvatore _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] bug 0001055 Form autoscroll and Control.Align=alTop
Hi, in the shot there is what I reported in the issoue 0001055 and it is still there (recent Lazarus SVN) . Should I reopen the issoue or is exected behavior? Regards Salvatore Immagine.png Description: Binary data
Re: [lazarus] TrayIcon preview
On 1/17/06, A.J. Venter <[EMAIL PROTECTED]> wrote: > 2) Is there a README or a short howto available ? Documentation is being constructed here: http://wiki.lazarus.freepascal.org/index.php/TrayIcon -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
Funky Beast/Tomas/Mattias, I'm very pleased with the discussion on this topic so far. What I would like to add is the following; - I would like to join in merging the tool that Tomas has made and LazDoc. I think both tools complement each other - I like what Funky Beast is proposing, making a class that parses the FPDoc files. Fortunately LazDoc has a lot of code in already that does the same. Please feel free to take out whatever you need. LazDoc can be changed then to use the new class. Btw there's also code in that extracts all the items in the code. Darius On Tue, 2006-01-17 at 10:33, Tomas Gregorovic wrote: > Funky Beast napsal(a): > > Mattias Gaertner wrote: > > > >> On 16 Jan 2006 21:36:09 +0100 > >> Darius Blaszijk <[EMAIL PROTECTED]> wrote: > >> > >> > >>> On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: > >>> > What we need: > 1. a hint window to right of the completion box. > 2. the search for the fpdoc/xml path > 3. the parsing of the fpdoc xml item and showing as formatted text > > If someone implements 1 and 3, I will do 2. > >>> > >>> > >>> The fpdoc/xml path is already known, you set it for LazDoc already, so > >>> perhaps you can use that. > >> > >> > >> > >> I meant the full path. Example > >> > >> docs/xml/lcl/controls.xml#TCustomControl.Paint > >> > >> > >> Mattias > >> > > > > I'll start with 3, 1 & 2 would be meaningless without 3. > > I'll create a class to store the properties of the found element. > > Below is a prototype, do add in if i missed something. > > > > //* > > > > > > TCompletionItemDesc = class > > sPackage: string; > > sModule: string; > > sShort: string; > > sDescription: string; > > sSeeAlso: string; > > end; > > > > TCompletionItemInfo = class(TComponent) > > private > > //Stores info of currently selected > > FCurrentElement: TCompletionItemDesc; > > //XML FileName (absolute path). > > //If filename different, load slLazDocXML again. > > //If file not found, clear slLazDocXML. > > FXMLFileName: string; > > > > procedure SetXMLFileName(sFileName: string); > > protected > > //Stores Doc XML > > slLazDocXML: TStrings; > > public > > constructor Create(AOwner: TComponent): override; > > destructor Destroy; override; > > > > //Locates and store info into CurrentElement returns true if found > > function Fill_CurrentElement(sElementName: string): Boolean; > > > > //Locate and fill CurrentElement by specifying a path > > //e.g. /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint > > //Function will parse sPath, > > //load XML file if necessary, file not found -- Exit, > > //locate Element specified at end of path, > > //finally fill up CurrentElement by parsing up to next '' tag. > > //Returns true if successful, clear CurrentElement members if false. > > function Get_Element_from_Path(sPath: string): Boolean; > > > > property CurrentElement: TCompletionItemDesc read FCurrentElement > > write FCurrentElement; > > property XMLFileName: string read FXMLFileName write SetXMLFileName; > > end; > > //* > > > > > > > > So basically the usage is to invoke function Get_Element_from_Path, > > if it succeeds, get the values from members of CurrentElement property. > > > > If above prototype is correct, i'll start working on the body. > > > > Should the above be placed in the SourceEditProcs.pas? > > > > Any content populated 'controls.xml' files i can test with? > > > > Initially i was planning to have a quick hint of the whole view of the item > > when the mouse moves over an item in the completion box. This can be > > achieved > > by a MouseMove method which calculates the Y value to know which item > > the mouse is pointing at. Then extracting the hint from a 'hint list' which > > is maintained by modifying PaintCompletionItem method to return the > > formated > > string to the hint list base on the index value. So the 'hint list' only > > needs > > to maintain a few number of strings=NBLinesInWindow (i.e. the displayed > > items). > > > > Funky Beast > > > > > > _ > > To unsubscribe: mail [EMAIL PROTECTED] with > >"unsubscribe" as the Subject > > archives at http://www.lazarus.freepascal.org/mailarchives > > > > > > Hi, > that idea sounds great. I can help you a bit with the second part of 3rd > statement. I have been developing a viewer for HTML help files that can > also parse and view FPDoc tags (remark, code, link...). The screenshot > is attached. > > Although it is still under construction, I think it evens the IPro HTML > viewer and for this purposes is more suitable. > > So, if you are interested, I can send you the code. > > tombo ___
Re: [lazarus] [patch] printers4lazarus
> - PDev.Device:=PDev.DevMode.dmDeviceName; > +// PDev.Device:=PDev.DevMode.dmDeviceName; sorry, was just a test i havend found why exactly but in the structure PDev.Name the name is truncated to 32 chars in EnumeratePrinters it has full length i have tried to find out where it is truncated but dont found it. then i used Printers[Printerindex] witch holds it in full length the change above was only to test from where the problem cames, please ignore it > To be sure let's give them a couple of days more and then I will try > some other path. ok Christian _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] [patch] printers4lazarus
--- Christian Ulrich <[EMAIL PROTECTED]> escribió: > the attatched patch fixes the winprinters.inc and makes printers > with names > 32 chars useable in win32 (most network printers) Why this change? - PDev.Device:=PDev.DevMode.dmDeviceName; +// PDev.Device:=PDev.DevMode.dmDeviceName; > works great for me with Lazreport (what about the licensing > problems with lazreport any progress ??) > No progress at all, still waiting response. About this I believe that there should be no problem using lazreport in commercial applications, lazreport is distributed under LGPL because it uses FreeReport code which is LGPL, FreeReport as far as I know may be used in commercial applications (just you don't get all features or support of FastReport)and so LazReport may be used too. I know there is some concern about the runtime-linking issue, but afaik the same applies to FreeReport. To be sure let's give them a couple of days more and then I will try some other path. > regards > Christian > Jesus Reyes A. ___ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TrayIcon preview
real nice work, i have tested it today and have some hints. 1. tooltips are mostly known as hints in lazarus/delphi so maybe you should rename the 2 properties 2. i think this component is visual better useable so its easyer to generate the events ... 3. its not easy to generate an icon handle in win32 i will try to make an function that generates an handle from an bitmap so the handle can be created from TIcom (witch is an TBitmap) it not avalible regards Christian _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] [patch] printers4lazarus
the attatched patch fixes the winprinters.inc and makes printers with names > 32 chars useable in win32 (most network printers) works great for me with Lazreport (what about the licensing problems with lazreport any progress ??) regards Christian printers.diff Description: Binary data
Re: [lazarus] Re: TrayIcon preview
On Tue, 17 Jan 2006 11:05:04 -0200 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > > Hello, > > New version attached. Please apply that. Adds copyright notices + many > corrections + more coments + various improvements. > > Works as I would like on Win32 and Gtk1 and gnome. The only thing that > does not work is the gtk2 interface. > > It would be very nice if someone can get the Gtk2 version to compile and > work. Just open the test program and compile for Gtk2. Currently it is a > copy of the Gtk1 code. > > I don't know much about Gtk and I am having a hard time with those Gtk1 > / Gtk2 differences. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
On Tue, 17 Jan 2006 21:07:48 +0800 Funky Beast <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > On Tue, 17 Jan 2006 17:04:57 +0800 > > Funky Beast <[EMAIL PROTECTED]> wrote: > > > > > >>Mattias Gaertner wrote: > >> > >>>On 16 Jan 2006 21:36:09 +0100 > >>>Darius Blaszijk <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: > > > >What we need: > >1. a hint window to right of the completion box. > >2. the search for the fpdoc/xml path > >3. the parsing of the fpdoc xml item and showing as formatted text > > > >If someone implements 1 and 3, I will do 2. > > The fpdoc/xml path is already known, you set it for LazDoc already, so > perhaps you can use that. > >>> > >>> > >>>I meant the full path. Example > >>> > >>>docs/xml/lcl/controls.xml#TCustomControl.Paint > > > > > > Every designtime package can register its own help files. > > Actually the help generates paths of type TPascalHelpContextList defined > > in ideintf/helpintf.pas > > For example: > > pihcFilename: '/path/of/your/package/docs' > > pihcType: 'TYourComponent' > > pihcProcedure: 'YourMethod' > > pihcParameterList: '' > > > > I see. > > > which is converted by the TFPDocHTMLHelpDatabase to the fpdoc html path. > > I will extend TFPDocHTMLHelpDatabase to create the fpdoc xml path. > > > > > > > >>I'll start with 3, 1 & 2 would be meaningless without 3. > >>I'll create a class to store the properties of the found element. > >>Below is a prototype, do add in if i missed something. > >> > >>//* > >** >** TCompletionItemDesc = class > >> sPackage: string; > >> sModule: string; > >> sShort: string; > >> sDescription: string; > >> sSeeAlso: string; > >> end; > > > > > > What's package and what's module? Can you add some comments? > > > I was extracting whatever tags i could find in the xml documents. > sPackage represents the tag e.g. at beginning > of every xml doc. > sModule represents the tag e.g. also at begin > of every xml doc. > If there are any irrelevent tags included, do not hesitate to remove it. > > > > > >>TCompletionItemInfo = class(TComponent) > >> private > >> //Stores info of currently selected > >> FCurrentElement: TCompletionItemDesc; > >> //XML FileName (absolute path). > >> //If filename different, load slLazDocXML again. > >> //If file not found, clear slLazDocXML. > >> FXMLFileName: string; > >> > >> procedure SetXMLFileName(sFileName: string); > >> protected > >> //Stores Doc XML > >> slLazDocXML: TStrings; > >> public > >> constructor Create(AOwner: TComponent): override; > >> destructor Destroy; override; > >> > >> //Locates and store info into CurrentElement returns true if found > >> function Fill_CurrentElement(sElementName: string): Boolean; > >> > >> //Locate and fill CurrentElement by specifying a path > >> //e.g. > >> /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint > >> //Function will parse sPath, //load XML file if necessary, file not > >> found -- Exit, //locate Element specified at end of path, > >> //finally fill up CurrentElement by parsing up to next '' > >> tag. //Returns true if successful, clear CurrentElement members if > >> false. function Get_Element_from_Path(sPath: string): Boolean; > >> > >> property CurrentElement: TCompletionItemDesc read FCurrentElement > >> write FCurrentElement; > >> property XMLFileName: string read FXMLFileName write SetXMLFileName; > >> end; > >>//* > >** >** > >> > >>So basically the usage is to invoke function Get_Element_from_Path, > >>if it succeeds, get the values from members of CurrentElement property. > >> > >>If above prototype is correct, i'll start working on the body. > >> > >>Should the above be placed in the SourceEditProcs.pas? > > > > > > No. Start a new unit, say 'CodeHelp' (ide/codehelp.pas). > Roger that. > > > > > > > >>Any content populated 'controls.xml' files i can test with? > > > > > > Maybe stdctrls.xml TEdit entries. > > > > > > > >>Initially i was planning to have a quick hint of the whole view of the > >>item when the mouse moves over an item in the completion box. This can > >be >achieved by a MouseMove method which calculates the Y value to know > >which >item the mouse is pointing at. Then extracting the hint from a > >'hint list' >which is maintained by modifying PaintCompletionItem method > >to return the >formated string to the hint list base on the index value. > >So the 'hint >list' only needs to maintain a few number of > >strings=NBLinesInWindow (i.e. >the displayed items). > > > > > > The PaintCompletionItem does not need the list, so you don't need them > > neither. Just retrieve the item on the fly as PaintCompletionItem. > >
[lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
Tomas Gregorovic wrote: Funky Beast napsal(a): Mattias Gaertner wrote: On 16 Jan 2006 21:36:09 +0100 Darius Blaszijk <[EMAIL PROTECTED]> wrote: On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: What we need: 1. a hint window to right of the completion box. 2. the search for the fpdoc/xml path 3. the parsing of the fpdoc xml item and showing as formatted text If someone implements 1 and 3, I will do 2. The fpdoc/xml path is already known, you set it for LazDoc already, so perhaps you can use that. I meant the full path. Example docs/xml/lcl/controls.xml#TCustomControl.Paint Mattias I'll start with 3, 1 & 2 would be meaningless without 3. I'll create a class to store the properties of the found element. Below is a prototype, do add in if i missed something. //* TCompletionItemDesc = class sPackage: string; sModule: string; sShort: string; sDescription: string; sSeeAlso: string; end; TCompletionItemInfo = class(TComponent) private //Stores info of currently selected FCurrentElement: TCompletionItemDesc; //XML FileName (absolute path). //If filename different, load slLazDocXML again. //If file not found, clear slLazDocXML. FXMLFileName: string; procedure SetXMLFileName(sFileName: string); protected //Stores Doc XML slLazDocXML: TStrings; public constructor Create(AOwner: TComponent): override; destructor Destroy; override; //Locates and store info into CurrentElement returns true if found function Fill_CurrentElement(sElementName: string): Boolean; //Locate and fill CurrentElement by specifying a path //e.g. /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint //Function will parse sPath, //load XML file if necessary, file not found -- Exit, //locate Element specified at end of path, //finally fill up CurrentElement by parsing up to next '' tag. //Returns true if successful, clear CurrentElement members if false. function Get_Element_from_Path(sPath: string): Boolean; property CurrentElement: TCompletionItemDesc read FCurrentElement write FCurrentElement; property XMLFileName: string read FXMLFileName write SetXMLFileName; end; //* So basically the usage is to invoke function Get_Element_from_Path, if it succeeds, get the values from members of CurrentElement property. If above prototype is correct, i'll start working on the body. Should the above be placed in the SourceEditProcs.pas? Any content populated 'controls.xml' files i can test with? Initially i was planning to have a quick hint of the whole view of the item when the mouse moves over an item in the completion box. This can be achieved by a MouseMove method which calculates the Y value to know which item the mouse is pointing at. Then extracting the hint from a 'hint list' which is maintained by modifying PaintCompletionItem method to return the formated string to the hint list base on the index value. So the 'hint list' only needs to maintain a few number of strings=NBLinesInWindow (i.e. the displayed items). Funky Beast _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives Hi, that idea sounds great. I can help you a bit with the second part of 3rd statement. I have been developing a viewer for HTML help files that can also parse and view FPDoc tags (remark, code, link...). The screenshot is attached. Very nice, that reminds me how much i missed pressing the F1 key :-). That would mean the 1st statement would be an HTML hint window, wouldn't it? Although it is still under construction, I think it evens the IPro HTML viewer and for this purposes is more suitable. So, if you are interested, I can send you the code. Please do, thanks. tombo _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
Mattias Gaertner wrote: On Tue, 17 Jan 2006 17:04:57 +0800 Funky Beast <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On 16 Jan 2006 21:36:09 +0100 Darius Blaszijk <[EMAIL PROTECTED]> wrote: On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: What we need: 1. a hint window to right of the completion box. 2. the search for the fpdoc/xml path 3. the parsing of the fpdoc xml item and showing as formatted text If someone implements 1 and 3, I will do 2. The fpdoc/xml path is already known, you set it for LazDoc already, so perhaps you can use that. I meant the full path. Example docs/xml/lcl/controls.xml#TCustomControl.Paint Every designtime package can register its own help files. Actually the help generates paths of type TPascalHelpContextList defined in ideintf/helpintf.pas For example: pihcFilename: '/path/of/your/package/docs' pihcType: 'TYourComponent' pihcProcedure: 'YourMethod' pihcParameterList: '' I see. which is converted by the TFPDocHTMLHelpDatabase to the fpdoc html path. I will extend TFPDocHTMLHelpDatabase to create the fpdoc xml path. I'll start with 3, 1 & 2 would be meaningless without 3. I'll create a class to store the properties of the found element. Below is a prototype, do add in if i missed something. //*** ** TCompletionItemDesc = class sPackage: string; sModule: string; sShort: string; sDescription: string; sSeeAlso: string; end; What's package and what's module? Can you add some comments? I was extracting whatever tags i could find in the xml documents. sPackage represents the tag e.g. at beginning of every xml doc. sModule represents the tag e.g. also at begin of every xml doc. If there are any irrelevent tags included, do not hesitate to remove it. TCompletionItemInfo = class(TComponent) private //Stores info of currently selected FCurrentElement: TCompletionItemDesc; //XML FileName (absolute path). //If filename different, load slLazDocXML again. //If file not found, clear slLazDocXML. FXMLFileName: string; procedure SetXMLFileName(sFileName: string); protected //Stores Doc XML slLazDocXML: TStrings; public constructor Create(AOwner: TComponent): override; destructor Destroy; override; //Locates and store info into CurrentElement returns true if found function Fill_CurrentElement(sElementName: string): Boolean; //Locate and fill CurrentElement by specifying a path //e.g. /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint //Function will parse sPath, //load XML file if necessary, file not found -- Exit, //locate Element specified at end of path, //finally fill up CurrentElement by parsing up to next '' tag. //Returns true if successful, clear CurrentElement members if false. function Get_Element_from_Path(sPath: string): Boolean; property CurrentElement: TCompletionItemDesc read FCurrentElement write FCurrentElement; property XMLFileName: string read FXMLFileName write SetXMLFileName; end; //*** ** So basically the usage is to invoke function Get_Element_from_Path, if it succeeds, get the values from members of CurrentElement property. If above prototype is correct, i'll start working on the body. Should the above be placed in the SourceEditProcs.pas? No. Start a new unit, say 'CodeHelp' (ide/codehelp.pas). Roger that. Any content populated 'controls.xml' files i can test with? Maybe stdctrls.xml TEdit entries. Initially i was planning to have a quick hint of the whole view of the item when the mouse moves over an item in the completion box. This can be achieved by a MouseMove method which calculates the Y value to know which item the mouse is pointing at. Then extracting the hint from a 'hint list' which is maintained by modifying PaintCompletionItem method to return the formated string to the hint list base on the index value. So the 'hint list' only needs to maintain a few number of strings=NBLinesInWindow (i.e. the displayed items). The PaintCompletionItem does not need the list, so you don't need them neither. Just retrieve the item on the fly as PaintCompletionItem. Although I think, when the completion help box is already there, you can easier use the up/down keys than move your hand to the mouse. Agreed, that was my initial thoughts when i couldn't identify my projects' functions which have names that are too long to display entirely in the completion box (had to do trial and error). A tiny question, what about identifiers in user's projects which might not have an xml document to refer to? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchive
[lazarus] Re: TrayIcon preview
Hello, New version attached. Please apply that. Adds copyright notices + many corrections + more coments + various improvements. Works as I would like on Win32 and Gtk1 and gnome. The only thing that does not work is the gtk2 interface. It would be very nice if someone can get the Gtk2 version to compile and work. Just open the test program and compile for Gtk2. Currently it is a copy of the Gtk1 code. I don't know much about Gtk and I am having a hard time with those Gtk1 / Gtk2 differences. thanks, Felipe TrayIcon.winzip Description: Binary data
Re: [lazarus] Re: TrayIcon preview
On Tue, 17 Jan 2006 10:22:04 -0200 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > I don't see, what registering a class has to do with. Maybe your > > initialization section is too automatic? > > Systray Icons don't really exist on Mac OS X. What exists is a Taskbar > Icon witch behaves somewhat like a System Tray Icon. i.e. he can be > drawn at will, and respond to mouse messages, etc. > > There can be only 1 of those taskbar icons on Mac OS X, and I think it > is always visible. So, to ensure that the Icon is correctly initialized > with the Application, I set it to be created on the initialization > section. This way people can use the SystrayIcon object instead of the > class. It is the exact same idea behind Application, Mouse and Screen > objects. > > This may be wrong, because I am not a Mac programmer, but it my best > guess of how I should go to support Mac OS X. > > The object will include support for multiple icons (not very > multiplatform) on itself, so multiple instances are not necessary. > Making the visual component a wrapper around the SystrayIcon object will > make sure that if someone drops 3 components on his form, they will work > as one instead of raising errors. Ok. I still don't see, why registering TTrayIcon can't be solved, but the registration is a minor issue at the moment. Note: Instead of IFDEF Linux for gtk, please use IFDEF LCLGtk. (LCLGtk2, LCLGnome, LCLCarbon, ...) Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch splash dialog
On Tue, 17 Jan 2006, Vincent Snijders wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hi there, After toying a bit with the splash in Lazarus because I wanted to make the same for an app of mine, I came across a bit strange error. It seems that startlazarus and lazarus both call their own instance of te splash. So if you would like to send some info the the splash this would only be possible starting from lazarus. Startlazarus does not seem to share the splash. I fixed it for my own app and figured it would not harm doing the same for lazarus. At the same time the amount of code is a bit reduced (more consistent with other dialogs) and I added also startup info to the splash. For now it's just very limited, but can easily be expanded. Fairly trivial, but nice to have. Hope it gets comitted. Nice feature, giving feedback in which phase of the startup lazarus is. I wonder how this can work if you are using startlazarus. I think you are showing two splashscreens then, first one of startlazarus (which will remain there for a couple of seconds, because startlazarus doesn't know when lazarus has started completely) and then lazarus shows another splashscreen (just on the same place). Startlazarus starts lazarus with the -nsc option. I don't think this is a nice aspect of this patch. You're right, something fishy is going on. I did not notice it yesterday late, but when I recompile lazarus the splash actually dissapears and then shows again. But if I start startlazarus from terminal lazarus seems to fire up that quick that I don't notice the dissapearing of the first splash. So that's back to the drawingboard for me. I will try to fix it and resubmit, unless someone say's it's a waste of time. As said I figured it out for an app of mine that's why I made this trivial enhancement. No, not a waste of time. If you go back to the drawing board, maybe you can take a look at a way to implement some Interprocess communication (IPC) between startlazarus and lazarus. If you can find a way to let lazarus communicate to startlazarus in what phase it is and when it has finished starting up, then the splash screen can be hidden in startlazarus at the correct time and not when some arbitrary delay has finished. IIRC, fpc has an IPC unit, but maybe it is not suitable. Andrew Haines used it for the CHMHelpViewer. It is suitable. The startlazarus process should be an IPC server. The Lazarus program is an IPC client which sends status information to the IPC server. Lazarus can detect whether the IPC server is started to decide whether it should a. Display splash by itself b. Send status info. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Re: TrayIcon preview
Mattias Gaertner wrote: I don't see, what registering a class has to do with. Maybe your initialization section is too automatic? Systray Icons don't really exist on Mac OS X. What exists is a Taskbar Icon witch behaves somewhat like a System Tray Icon. i.e. he can be drawn at will, and respond to mouse messages, etc. There can be only 1 of those taskbar icons on Mac OS X, and I think it is always visible. So, to ensure that the Icon is correctly initialized with the Application, I set it to be created on the initialization section. This way people can use the SystrayIcon object instead of the class. It is the exact same idea behind Application, Mouse and Screen objects. This may be wrong, because I am not a Mac programmer, but it my best guess of how I should go to support Mac OS X. The object will include support for multiple icons (not very multiplatform) on itself, so multiple instances are not necessary. Making the visual component a wrapper around the SystrayIcon object will make sure that if someone drops 3 components on his form, they will work as one instead of raising errors. Felipe _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: TrayIcon preview
On Tue, 17 Jan 2006 09:55:12 -0200 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > A.J. Venter wrote: > > Hi Felipe, > > Thank you for this, something I've been VERY much wanting in lazarus was > > > > trayicon support. > > You are Welcome =) > > Acctually, this was a preview witch should have only being sent to > Andrew. I took the address from an old talk we had, but that talk was on > the mailling list, so I end up sending the component to everyone! > > You guys should wait a official stable release in about 1 or 2 days =) > > It works well with Windows and Gtk1. Now I am working on Gtk2 support. > > I won't create carbon support at this time, but it is built expecting a > Mac OS X. > > > A few quick questions though > > 1) Is it a component ? Visual ? Nonvisual ? I admit I've only had a > > cursory glance at your sources, not a sufficient study yet. > > You realle should not derive or instantiate the non-visual component, > use the SystrayIcon object instead. It is automatically created on > program startup, and this approach is required for future Mac OS X > support. The object is also Delphi-Compatible. > > I visual wrapper around the object can be easely built. > > > 2) Is there a README or a short howto available ? > > I am working on a wiki page now. > > > Thanks. I created a package TrayIconLaz.lpk and added it to svn. > > ummm . I really would have prefered to wait a little =) > > I have much newer code on my PC, and the Licensing stuff is also > missing. The component is Modifyed-LGPL. I guessed so. See the lazarus svn. > I also want to ship it with > Gtk2 support. > > There are some things witch must be taken care of. You can't just > register TTrayIcon because of Mac OS X future support. The visual > component must be a wrapper around the SystrayIcon object. I don't see, what registering a class has to do with. Maybe your initialization section is too automatic? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Re: TrayIcon preview
A.J. Venter wrote: Hi Felipe, Thank you for this, something I've been VERY much wanting in lazarus was trayicon support. You are Welcome =) Acctually, this was a preview witch should have only being sent to Andrew. I took the address from an old talk we had, but that talk was on the mailling list, so I end up sending the component to everyone! You guys should wait a official stable release in about 1 or 2 days =) It works well with Windows and Gtk1. Now I am working on Gtk2 support. I won't create carbon support at this time, but it is built expecting a Mac OS X. A few quick questions though 1) Is it a component ? Visual ? Nonvisual ? I admit I've only had a cursory glance at your sources, not a sufficient study yet. You realle should not derive or instantiate the non-visual component, use the SystrayIcon object instead. It is automatically created on program startup, and this approach is required for future Mac OS X support. The object is also Delphi-Compatible. I visual wrapper around the object can be easely built. > 2) Is there a README or a short howto available ? I am working on a wiki page now. Thanks. I created a package TrayIconLaz.lpk and added it to svn. ummm . I really would have prefered to wait a little =) I have much newer code on my PC, and the Licensing stuff is also missing. The component is Modifyed-LGPL. I also want to ship it with Gtk2 support. There are some things witch must be taken care of. You can't just register TTrayIcon because of Mac OS X future support. The visual component must be a wrapper around the SystrayIcon object. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TrayIcon preview
On Tue, 17 Jan 2006 13:02:06 +0200 "A.J. Venter" <[EMAIL PROTECTED]> wrote: > Hi Felipe, > Thank you for this, something I've been VERY much wanting in lazarus was > trayicon support. > > A few quick questions though > 1) Is it a component ? Visual ? Nonvisual ? I admit I've only had a > cursory glance at your sources, not a sufficient study yet. Nonvisual. But you can put it onto a form, like TOpenDialog. > 2) Is there a README or a short howto available ? There is an example. > And one for Mattias et all - this is SUCH a widely useable thing and since > > Felipe made it nicely multiplatform for ALL the currently active Lazarus > platforms, shouldn't it go into Lazarus itself ? It's in Lazarus now. To add it to the LCL we must reorder/rename a few things. Mattias > > Ciao > A.J. > On Monday 16 January 2006 23:49, Felipe Monteiro de Carvalho wrote: > > The test program works on Linux (tested on Gnome, KDE, IceWM) and > > Windows (tested on XP). > > -- > > Felipe Monteiro de Carvalho > _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TrayIcon preview
On Mon, 16 Jan 2006 19:49:04 -0200 Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > The test program works on Linux (tested on Gnome, KDE, IceWM) and > Windows (tested on XP). Thanks. I created a package TrayIconLaz.lpk and added it to svn. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch splash dialog
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hi there, After toying a bit with the splash in Lazarus because I wanted to make the same for an app of mine, I came across a bit strange error. It seems that startlazarus and lazarus both call their own instance of te splash. So if you would like to send some info the the splash this would only be possible starting from lazarus. Startlazarus does not seem to share the splash. I fixed it for my own app and figured it would not harm doing the same for lazarus. At the same time the amount of code is a bit reduced (more consistent with other dialogs) and I added also startup info to the splash. For now it's just very limited, but can easily be expanded. Fairly trivial, but nice to have. Hope it gets comitted. Nice feature, giving feedback in which phase of the startup lazarus is. I wonder how this can work if you are using startlazarus. I think you are showing two splashscreens then, first one of startlazarus (which will remain there for a couple of seconds, because startlazarus doesn't know when lazarus has started completely) and then lazarus shows another splashscreen (just on the same place). Startlazarus starts lazarus with the -nsc option. I don't think this is a nice aspect of this patch. You're right, something fishy is going on. I did not notice it yesterday late, but when I recompile lazarus the splash actually dissapears and then shows again. But if I start startlazarus from terminal lazarus seems to fire up that quick that I don't notice the dissapearing of the first splash. So that's back to the drawingboard for me. I will try to fix it and resubmit, unless someone say's it's a waste of time. As said I figured it out for an app of mine that's why I made this trivial enhancement. No, not a waste of time. If you go back to the drawing board, maybe you can take a look at a way to implement some Interprocess communication (IPC) between startlazarus and lazarus. If you can find a way to let lazarus communicate to startlazarus in what phase it is and when it has finished starting up, then the splash screen can be hidden in startlazarus at the correct time and not when some arbitrary delay has finished. IIRC, fpc has an IPC unit, but maybe it is not suitable. Andrew Haines used it for the CHMHelpViewer. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TrayIcon preview
Hi Felipe, Thank you for this, something I've been VERY much wanting in lazarus was trayicon support. A few quick questions though 1) Is it a component ? Visual ? Nonvisual ? I admit I've only had a cursory glance at your sources, not a sufficient study yet. 2) Is there a README or a short howto available ? And one for Mattias et all - this is SUCH a widely useable thing and since Felipe made it nicely multiplatform for ALL the currently active Lazarus platforms, shouldn't it go into Lazarus itself ? Ciao A.J. On Monday 16 January 2006 23:49, Felipe Monteiro de Carvalho wrote: > The test program works on Linux (tested on Gnome, KDE, IceWM) and > Windows (tested on XP). > -- > Felipe Monteiro de Carvalho -- "80% Of a hardware engineer's job is application of the uncertainty principle. 80% of a software engineer's job is pretending this isn't so." A.J. Venter Chief Software Architect OpenLab International http://www.getopenlab.com | +27 82 726 5103 (South Africa) http://www.silentcoder.co.za| +55 118 162 2079 (Brazil) _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bugfix 1611
On Mon, 16 Jan 2006 18:56:58 +0100 (CET) [EMAIL PROTECTED] wrote: > Here's the bugfix Thanks. Applied. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch splash dialog
> [EMAIL PROTECTED] wrote: >> Hi there, >> >> After toying a bit with the splash in Lazarus because I wanted to make >> the >> same for an app of mine, I came across a bit strange error. It seems >> that >> startlazarus and lazarus both call their own instance of te splash. So >> if >> you would like to send some info the the splash this would only be >> possible starting from lazarus. Startlazarus does not seem to share the >> splash. I fixed it for my own app and figured it would not harm doing >> the >> same for lazarus. At the same time the amount of code is a bit reduced >> (more consistent with other dialogs) and I added also startup info to >> the >> splash. For now it's just very limited, but can easily be expanded. >> Fairly trivial, but nice to have. Hope it gets comitted. >> > > Nice feature, giving feedback in which phase of the startup lazarus is. > > I wonder how this can work if you are using startlazarus. I think you are > showing > two splashscreens then, first one of startlazarus (which will remain there > for a > couple of seconds, because startlazarus doesn't know when lazarus has > started > completely) and then lazarus shows another splashscreen (just on the same > place). > Startlazarus starts lazarus with the -nsc option. > > I don't think this is a nice aspect of this patch. You're right, something fishy is going on. I did not notice it yesterday late, but when I recompile lazarus the splash actually dissapears and then shows again. But if I start startlazarus from terminal lazarus seems to fire up that quick that I don't notice the dissapearing of the first splash. So that's back to the drawingboard for me. I will try to fix it and resubmit, unless someone say's it's a waste of time. As said I figured it out for an app of mine that's why I made this trivial enhancement. Darius _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] bugfix 1611
[EMAIL PROTECTED] wrote: Here's the bugfix Thanks. Applied in revision 8535. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] GraphPropEdits converted to lfm + small patch for TreeViewPropEdit
On Sun, 15 Jan 2006 16:41:52 +0100 Tomas Gregorovic <[EMAIL PROTECTED]> wrote: > Hi, > I have converted Load Image Dialog from GraphPropEdits unit to lfm. > > In addition, I have fixed few things in TreeViewPropEdit: > - The change of image index (and other indexes) in TreeView items editor > is really stored in TreeView. > - You can't edit node attrs when items are empty. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] setColor patch
On Tue, 10 Jan 2006 19:22:17 +0100 darekm <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > >On Thu, 15 Dec 2005 18:25:47 +0100 > >darekM <[EMAIL PROTECTED]> wrote: > > > > > > > >>>I'm sorry but what exactly does it do? And what did it do without? > >>> > >>> > >>> > >>> > >>Set color background and front don't work for tForms, tEdit and tLabel > >>(I'm not test else), I've attached example. > >>Before all text were black, with patch red. > >> > >> > >> > >>>btw: I suggest _not_ commenting out stuff using block comments, because > >>>that makes the patch hard to read (because diff doesn't understand > >block >>comments and thus doesn't list all the contents). Best just > >delete the >>lines you do not need anymore... > >>> > >>> > >>> > >>> > >>correction in attached file > >> > >> > > > >How did you create this patch? It looks invalid and 'patch' says: > > > >patch: malformed patch at line 43: @@ -7540,10 +7584,23 @@ > > > >Mattias > > > > > I've prepare patch once more, maybe now will be better. > Sorry for delay, but now I don`t have enough time. Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
On Tue, 17 Jan 2006 17:04:57 +0800 Funky Beast <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > On 16 Jan 2006 21:36:09 +0100 > > Darius Blaszijk <[EMAIL PROTECTED]> wrote: > > > > > >>On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: > >> > >>>What we need: > >>>1. a hint window to right of the completion box. > >>>2. the search for the fpdoc/xml path > >>>3. the parsing of the fpdoc xml item and showing as formatted text > >>> > >>>If someone implements 1 and 3, I will do 2. > >> > >>The fpdoc/xml path is already known, you set it for LazDoc already, so > >>perhaps you can use that. > > > > > > I meant the full path. Example > > > > docs/xml/lcl/controls.xml#TCustomControl.Paint Every designtime package can register its own help files. Actually the help generates paths of type TPascalHelpContextList defined in ideintf/helpintf.pas For example: pihcFilename: '/path/of/your/package/docs' pihcType: 'TYourComponent' pihcProcedure: 'YourMethod' pihcParameterList: '' which is converted by the TFPDocHTMLHelpDatabase to the fpdoc html path. I will extend TFPDocHTMLHelpDatabase to create the fpdoc xml path. > I'll start with 3, 1 & 2 would be meaningless without 3. > I'll create a class to store the properties of the found element. > Below is a prototype, do add in if i missed something. > > //*** > ** TCompletionItemDesc = class > sPackage: string; > sModule: string; > sShort: string; > sDescription: string; > sSeeAlso: string; > end; What's package and what's module? Can you add some comments? > TCompletionItemInfo = class(TComponent) > private >//Stores info of currently selected >FCurrentElement: TCompletionItemDesc; >//XML FileName (absolute path). >//If filename different, load slLazDocXML again. >//If file not found, clear slLazDocXML. >FXMLFileName: string; > >procedure SetXMLFileName(sFileName: string); > protected >//Stores Doc XML >slLazDocXML: TStrings; > public >constructor Create(AOwner: TComponent): override; >destructor Destroy; override; > >//Locates and store info into CurrentElement returns true if found >function Fill_CurrentElement(sElementName: string): Boolean; > >//Locate and fill CurrentElement by specifying a path >//e.g. >/usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint >//Function will parse sPath, //load XML file if necessary, file not >found -- Exit, //locate Element specified at end of path, >//finally fill up CurrentElement by parsing up to next '' >tag. //Returns true if successful, clear CurrentElement members if >false. function Get_Element_from_Path(sPath: string): Boolean; > >property CurrentElement: TCompletionItemDesc read FCurrentElement >write FCurrentElement; >property XMLFileName: string read FXMLFileName write SetXMLFileName; > end; > //*** > ** > > So basically the usage is to invoke function Get_Element_from_Path, > if it succeeds, get the values from members of CurrentElement property. > > If above prototype is correct, i'll start working on the body. > > Should the above be placed in the SourceEditProcs.pas? No. Start a new unit, say 'CodeHelp' (ide/codehelp.pas). > Any content populated 'controls.xml' files i can test with? Maybe stdctrls.xml TEdit entries. > Initially i was planning to have a quick hint of the whole view of the > item when the mouse moves over an item in the completion box. This can be > achieved by a MouseMove method which calculates the Y value to know which > item the mouse is pointing at. Then extracting the hint from a 'hint list' > which is maintained by modifying PaintCompletionItem method to return the > formated string to the hint list base on the index value. So the 'hint > list' only needs to maintain a few number of strings=NBLinesInWindow (i.e. > the displayed items). The PaintCompletionItem does not need the list, so you don't need them neither. Just retrieve the item on the fly as PaintCompletionItem. Although I think, when the completion help box is already there, you can easier use the up/down keys than move your hand to the mouse. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
Funky Beast napsal(a): Mattias Gaertner wrote: On 16 Jan 2006 21:36:09 +0100 Darius Blaszijk <[EMAIL PROTECTED]> wrote: On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: What we need: 1. a hint window to right of the completion box. 2. the search for the fpdoc/xml path 3. the parsing of the fpdoc xml item and showing as formatted text If someone implements 1 and 3, I will do 2. The fpdoc/xml path is already known, you set it for LazDoc already, so perhaps you can use that. I meant the full path. Example docs/xml/lcl/controls.xml#TCustomControl.Paint Mattias I'll start with 3, 1 & 2 would be meaningless without 3. I'll create a class to store the properties of the found element. Below is a prototype, do add in if i missed something. //* TCompletionItemDesc = class sPackage: string; sModule: string; sShort: string; sDescription: string; sSeeAlso: string; end; TCompletionItemInfo = class(TComponent) private //Stores info of currently selected FCurrentElement: TCompletionItemDesc; //XML FileName (absolute path). //If filename different, load slLazDocXML again. //If file not found, clear slLazDocXML. FXMLFileName: string; procedure SetXMLFileName(sFileName: string); protected //Stores Doc XML slLazDocXML: TStrings; public constructor Create(AOwner: TComponent): override; destructor Destroy; override; //Locates and store info into CurrentElement returns true if found function Fill_CurrentElement(sElementName: string): Boolean; //Locate and fill CurrentElement by specifying a path //e.g. /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint //Function will parse sPath, //load XML file if necessary, file not found -- Exit, //locate Element specified at end of path, //finally fill up CurrentElement by parsing up to next '' tag. //Returns true if successful, clear CurrentElement members if false. function Get_Element_from_Path(sPath: string): Boolean; property CurrentElement: TCompletionItemDesc read FCurrentElement write FCurrentElement; property XMLFileName: string read FXMLFileName write SetXMLFileName; end; //* So basically the usage is to invoke function Get_Element_from_Path, if it succeeds, get the values from members of CurrentElement property. If above prototype is correct, i'll start working on the body. Should the above be placed in the SourceEditProcs.pas? Any content populated 'controls.xml' files i can test with? Initially i was planning to have a quick hint of the whole view of the item when the mouse moves over an item in the completion box. This can be achieved by a MouseMove method which calculates the Y value to know which item the mouse is pointing at. Then extracting the hint from a 'hint list' which is maintained by modifying PaintCompletionItem method to return the formated string to the hint list base on the index value. So the 'hint list' only needs to maintain a few number of strings=NBLinesInWindow (i.e. the displayed items). Funky Beast _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives Hi, that idea sounds great. I can help you a bit with the second part of 3rd statement. I have been developing a viewer for HTML help files that can also parse and view FPDoc tags (remark, code, link...). The screenshot is attached. Although it is still under construction, I think it evens the IPro HTML viewer and for this purposes is more suitable. So, if you are interested, I can send you the code. tombo
[lazarus] Re: Some questions on Identifier Completion of TSourceNotebook
Mattias Gaertner wrote: On 16 Jan 2006 21:36:09 +0100 Darius Blaszijk <[EMAIL PROTECTED]> wrote: On Mon, 2006-01-16 at 19:59, Mattias Gaertner wrote: What we need: 1. a hint window to right of the completion box. 2. the search for the fpdoc/xml path 3. the parsing of the fpdoc xml item and showing as formatted text If someone implements 1 and 3, I will do 2. The fpdoc/xml path is already known, you set it for LazDoc already, so perhaps you can use that. I meant the full path. Example docs/xml/lcl/controls.xml#TCustomControl.Paint Mattias I'll start with 3, 1 & 2 would be meaningless without 3. I'll create a class to store the properties of the found element. Below is a prototype, do add in if i missed something. //* TCompletionItemDesc = class sPackage: string; sModule: string; sShort: string; sDescription: string; sSeeAlso: string; end; TCompletionItemInfo = class(TComponent) private //Stores info of currently selected FCurrentElement: TCompletionItemDesc; //XML FileName (absolute path). //If filename different, load slLazDocXML again. //If file not found, clear slLazDocXML. FXMLFileName: string; procedure SetXMLFileName(sFileName: string); protected //Stores Doc XML slLazDocXML: TStrings; public constructor Create(AOwner: TComponent): override; destructor Destroy; override; //Locates and store info into CurrentElement returns true if found function Fill_CurrentElement(sElementName: string): Boolean; //Locate and fill CurrentElement by specifying a path //e.g. /usr/local/lazarus/docs/xml/lcl/controls.xml#TCustomControl.Paint //Function will parse sPath, //load XML file if necessary, file not found -- Exit, //locate Element specified at end of path, //finally fill up CurrentElement by parsing up to next '' tag. //Returns true if successful, clear CurrentElement members if false. function Get_Element_from_Path(sPath: string): Boolean; property CurrentElement: TCompletionItemDesc read FCurrentElement write FCurrentElement; property XMLFileName: string read FXMLFileName write SetXMLFileName; end; //* So basically the usage is to invoke function Get_Element_from_Path, if it succeeds, get the values from members of CurrentElement property. If above prototype is correct, i'll start working on the body. Should the above be placed in the SourceEditProcs.pas? Any content populated 'controls.xml' files i can test with? Initially i was planning to have a quick hint of the whole view of the item when the mouse moves over an item in the completion box. This can be achieved by a MouseMove method which calculates the Y value to know which item the mouse is pointing at. Then extracting the hint from a 'hint list' which is maintained by modifying PaintCompletionItem method to return the formated string to the hint list base on the index value. So the 'hint list' only needs to maintain a few number of strings=NBLinesInWindow (i.e. the displayed items). Funky Beast _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Patch splash dialog
[EMAIL PROTECTED] wrote: Hi there, After toying a bit with the splash in Lazarus because I wanted to make the same for an app of mine, I came across a bit strange error. It seems that startlazarus and lazarus both call their own instance of te splash. So if you would like to send some info the the splash this would only be possible starting from lazarus. Startlazarus does not seem to share the splash. I fixed it for my own app and figured it would not harm doing the same for lazarus. At the same time the amount of code is a bit reduced (more consistent with other dialogs) and I added also startup info to the splash. For now it's just very limited, but can easily be expanded. Fairly trivial, but nice to have. Hope it gets comitted. Nice feature, giving feedback in which phase of the startup lazarus is. I wonder how this can work if you are using startlazarus. I think you are showing two splashscreens then, first one of startlazarus (which will remain there for a couple of seconds, because startlazarus doesn't know when lazarus has started completely) and then lazarus shows another splashscreen (just on the same place). Startlazarus starts lazarus with the -nsc option. I don't think this is a nice aspect of this patch. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
