Re: [lazarus] Issue ID: 2061
Borut Maricic wrote: http://www.freepascal.org/mantis/view.php?id=2061 Summary: Uses is case-sensitive under win32 -- Mattias - 2006-07-15 01:12 -- Next try. I found a bug, that could be responsible. Again: Only a windows user can find out. Tried it out under WinXP with SVN 9618 and it indeed seems to be gone. Not case-sensitive any more. Then, please, close the issue. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Issue ID: 2061
http://www.freepascal.org/mantis/view.php?id=2061 Tried it out under WinXP with SVN 9618 and it indeed seems to be gone. Not case-sensitive any more. Then, please, close the issue. As far as I can see (but I wear glasses ;), one can only add/change notes, upload files and change his/her monitoring status for issues **one reported initially himself/herself**. (If this is true, maybe it should be changed a bit.) One can not close even his/her own issue (and the issue 2061 has even not been initially reported by me). If I did not overlook something, mantis is quite restrictive about access to its various functions, depending on who you are and if you are initial reporter of the issue or not. Borut _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Issue ID: 2061
Borut Maricic wrote: http://www.freepascal.org/mantis/view.php?id=2061 Tried it out under WinXP with SVN 9618 and it indeed seems to be gone. Not case-sensitive any more. Then, please, close the issue. As far as I can see (but I wear glasses ;), one can only add/change notes, upload files and change his/her monitoring status for issues **one reported initially himself/herself**. (If this is true, maybe it should be changed a bit.) One can not close even his/her own issue (and the issue 2061 has even not been initially reported by me). If I did not overlook something, mantis is quite restrictive about access to its various functions, depending on who you are and if you are initial reporter of the issue or not. Sorry, I thought you were the initial reporter. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] LCL-interface boundary
I just want to check something - please help... In the win32-case, in C:\Lazarus\lcl\interfaces\win32\win32wscontrols.pp one finds for example: procedure PrepareCreateWindow(const AWinControl: TWinControl; var Params: TCreateWindowExParams); begin with Params do begin Flags := WS_CHILD or WS_CLIPSIBLINGS or WS_CLIPCHILDREN; FlagsEx := 0; Assert(False, 'Trace:Setting flags'); Window := HWND(Nil); Buddy := HWND(Nil); Assert(False, 'Trace:Setting window'); if AWinControl.Parent nil then begin Parent := AWinControl.Parent.Handle; end else Parent := TWin32WidgetSet(WidgetSet).AppHandle; SubClassWndProc := @WindowProc; WindowTitle := nil; StrCaption := PChar(AWinControl.Caption); WindowTitle := nil; ... ... In there, in the line StrCaption := PChar(AWinControl.Caption); Caption is a property of TControl, declared in C:\Lazarus\lcl\controls.pp TControl.Caption uses read gettext and write settext, which are implemented for instance in C:\Lazarus\lcl\include\control.inc Now, I must admit that I am getting lost there a bit. My actual question: when Params.StrCaption is being assigned a value (above, in procedure PrepareCreateWindow) - is this value guaranteed to already be encoded in UTF8 (i.e. a transformation from the possible Codepage into UTF8 happens somewhere (where?) before) or it is still encoded in a Codepage, in cases where the application does not use UTF8 as Codepage? A second question: do I understand it correctly, that if I am changing/experimenting with the interface part, there is no way whatsoever to avoid the necessity to always rebuild Lazarus, in order to test the changes (and so these changes are immediately active in the recompiled IDE)? What is the preferred/suggested way of debugging such things? Many thanks to any core member for the patience in answering! Borut _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TGraphicControl and Canvas.Width
On 7/15/06, Mattias Gaertner [EMAIL PROTECTED] wrote: So the TGraphicsControl.Canvas is a clipping window to the parent canvas. Yes. I will update the LCL documentation with my new found knowledge! :-) Thanks to everybody that replied. Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] LCL-interface boundary
On Sat, 15 Jul 2006 10:17:54 +0200 Borut Maricic [EMAIL PROTECTED] wrote: I just want to check something - please help... In the win32-case, in C:\Lazarus\lcl\interfaces\win32\win32wscontrols.pp one finds for example: procedure PrepareCreateWindow(const AWinControl: TWinControl; var Params: TCreateWindowExParams); begin with Params do begin Flags := WS_CHILD or WS_CLIPSIBLINGS or WS_CLIPCHILDREN; FlagsEx := 0; Assert(False, 'Trace:Setting flags'); Window := HWND(Nil); Buddy := HWND(Nil); Assert(False, 'Trace:Setting window'); if AWinControl.Parent nil then begin Parent := AWinControl.Parent.Handle; end else Parent := TWin32WidgetSet(WidgetSet).AppHandle; SubClassWndProc := @WindowProc; WindowTitle := nil; StrCaption := PChar(AWinControl.Caption); WindowTitle := nil; ... ... In there, in the line StrCaption := PChar(AWinControl.Caption); Caption is a property of TControl, declared in C:\Lazarus\lcl\controls.pp TControl.Caption uses read gettext and write settext, which are implemented for instance in C:\Lazarus\lcl\include\control.inc Now, I must admit that I am getting lost there a bit. My actual question: when Params.StrCaption is being assigned a value (above, in procedure PrepareCreateWindow) - is this value guaranteed to already be encoded in UTF8 (i.e. a transformation from the possible Codepage into UTF8 happens somewhere (where?) before) or it is still encoded in a Codepage, in cases where the application does not use UTF8 as Codepage? Caption holds the value of the .lfm file, which will eventually be only UTF-8. But at the moment it is not guaranteed and will hold the value in the 'codepage' the creator of the .lfm used. It is planned that the interfaces translate strings on the fly and Caption will be UTF-8. So the above will probably replaced with StrCaption := PChar(UTF8StringToWindowsString(AWinControl.Caption)); or something like that. A second question: do I understand it correctly, that if I am changing/experimenting with the interface part, there is no way whatsoever to avoid the necessity to always rebuild Lazarus, in order to test the changes (and so these changes are immediately active in the recompiled IDE)? Wrong. To play with the interface you only need to rebuild the interface. See below. Of course if you want to create a patch for us, then you should at least rebuild the IDE once and check, that your changes didn't broke anything. What is the preferred/suggested way of debugging such things? 1. Create a project (small test application). 2. Setup shortcuts for 'build lazarus' and 'configure build lazarus'. 3. 'configure build lazarus' to only build the LCL. 4. Change some things 5. compile lazarus (this only rebuilds the LCL, which automatically rebuilds the selected interface). 6. compile your project 7. run and debug program 8. On error, go back to 4. Otherwise to 9. 9. 'configure build lazarus' to build all. 10. test the IDE, on error go to 3. otherwise 11. 11. create a patch and send it. Many thanks to any core member for the patience in answering! Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Debugger problems without debugger
On Wed, 05 Jul 2006 10:00:12 +0200 Micha Nelissen [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: Then maybe it is another 'feature' of the TAyncProcess. I don't use TAsyncProcess (or somebody changed the code) As soon as some other place in the IDE uses a TAsyncProcess, the other TProcess get problems. For example, using TAsyncProcess to compile a project and then run the project with a TProcess, then exit the program normally, then quit IDE and it hangs. Can you make a small example program that reproduces the problem, and send it to me ? Any program. For example: Create a new project (program), press F9 to compile and start the debugger. Close IDE - hangs up in gtk message loop. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] LCL-interface boundary
Thank you Mattias! I will explore it further probably on Sunday and would like to place a few additional questions right now, so that I will maybe find the answers when I come back today late at night: Caption holds the value of the .lfm file, which will eventually be only UTF-8. But at the moment it is not guaranteed and will hold the value in the 'codepage' the creator of the .lfm used. It is planned that the interfaces translate strings on the fly and Caption will be UTF-8. So the above will probably replaced with StrCaption := PChar(UTF8StringToWindowsString(AWinControl.Caption)); or something like that. a1) Since it is also possible that application programmer assigns some value to the Caption property programmatically (i.e. not only at design time in .lfm, which is then used in PrepareCreateWindow): procedure TForm1.Button1Click(Sender: TObject); begin Self.Caption:='123'; end; I guess that the reader method of the LCL-control Caption property should take care of possible necessity to convert from some code page to UTF-8, before proceeding the value to the widgetset (interface). In my view, it is only then that we can say that the LCL-widgetset boundary is based on UTF8. I guess this is the area you are saying needs to be done. If so, there might be many places that need that check/conversion added and they are all in the LCL part that is independent of the target platform. Do I get the idea right here? a2) StrCaption := PChar(UTF8StringToWindowsString(AWinControl.Caption)); If you have the Unicode-enabling for Win32 here in mind (which is my aim and therefore all the questions), as far as I see it, the issue is not so easy. If we are not going to have a separate WS win32w for that (I would personally not be fond of separate WS), then there are lots of things to change in WS win32. As an example, since procedure FinishCreateWindow will have to decide which winapi to call (*A or *W), i believe we will for instance need an additional TCreateWindowExParamsW (with PWideChars in it), which would be used with *W-Winapi calls. Moreover, FCL is now mapping (conditioned with $define UNICODE or the lack thereof) to either *W, or to *A winapi-functions (as far as I could see), while we will need both worlds to be available to a WS/interface at the same time. a3) An important and still opened architectural decision is: Win32-Unicode support into WS Win32, or a new WS Win32w, that would support only WinNT+ machines? Vincent proposed a new WS: http://wiki.lazarus.freepascal.org/index.php/Talk:LCL_Unicode_Support Here the application programmers are also asked for their opinion - is it necessary to support all Win* with one exe, or is it ok to have two, if need be? From the LCL point of view, a new WS would be clearer and easier to develop, but new Controls would then have to be supported in both (and in WinCE too - Roozbeh wrote some ideas too). Mattias an others, I know many of you are very *nux oriented but I would really appreciate any thoughts on these issues, because I do not feel to have the necessary insight to make an educated decision (and these decisions will determine the whole further development of Unicode support for win, if it really ever happens :( 1. Create a project (small test application). 2. Setup shortcuts for 'build lazarus' and 'configure build lazarus'. 3. 'configure build lazarus' to only build the LCL. 4. Change some things 5. compile lazarus (this only rebuilds the LCL, which automatically rebuilds the selected interface). 6. compile your project 7. run and debug program 8. On error, go back to 4. Otherwise to 9. 9. 'configure build lazarus' to build all. 10. test the IDE, on error go to 3. otherwise 11. 11. create a patch and send it. These are great cool news for me! Just two small stupid questions: b1) What would be the appropriate wiki-page to copy this there? b2) What is meant by the step 2 - what shortcuts? I can find the menu items: Tools/Build Lazarus and Tools/Configure build Lazarus, but have no clue about shortcuts in this respect. Thanks in advance and have a nice weekend! Borut _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question for a new feature I want to add
2006/7/14, Mattias Gaertner [EMAIL PROTECTED]: On Fri, 14 Jul 2006 17:04:52 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: Hi all, I would like to add a browse history to the unit editor. I saw some functions associated with HistoryJump() and I would like to know what exactly this code is doing... When jumping to an error or by find declaration, the IDE adds the last position to a History of jumps. This way you can jump back with Ctrl+H. See the Search - Jump Forward/Back, add jump point and view jump history menu items. The only missing thing is the dialog or window presenting the history of jumps. Indeed, I see that all is there, only the history display is missing. I wanted to add a toolbar (that could be hidden for those who do not want it) but I can't find and any nice buttons that have a 'drop-down' hability to display a part of the history. (For a back and forward button). And I don't know where to store any bitmap (icons). I'm not the kind of guy who delights in UI design. :S But all the features for history are there and working as I wanted them too. I might check that for a UI later... too... -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Question of feature: code browser
I remember a feature in D6 in the UnitEditor: a vertical code browser
for fast-searching in source code. This was a very nice gadget.
1. Any-one work[ed,ing] on this?
2. Can I use VirtualTreeView as a new component/source dependency to
implement such a feature? (It has everything required to build such a
tool.) If no, what should be used?
3. I was planning to develop this in another form, then dock that form
in the UnitEditor if desired. I know this mechanism is not working
well right now, but some patches are working... Should this avenue be
kept?
4. I'm sure there are already functions and tools to get information
about a source file's structure (interface, implementation,
initialization, finalization) but where is it?
5. I'm sure there are already functions and tools to get all the type
/ classes / procedures / functions in the interface section of a
source file... but where is it? (I assume that because of
code-completion Ctrl+c that works well.)
6. I'm sure there are already functions and tools to get all the types
/ var / procedures / functions present in the implementation part of a
source file... but where can I find these?
7. Any function to detect {$i include.inc} in a source file? (I
personally hate these, but I know someone talked about code-folding
such include files: that would be awesome, especially if a search in a
document would extend into the .inc files too... this is another
feature I want to work on, because searching is a pain... and also
working on another feature: there is 'find declaration' but 'find
implementation' is missing...)
Best regards.
--
Alexandre Leclerc
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] LCL-interface boundary
On Sat, 15 Jul 2006 13:54:21 +0200 Borut Maricic [EMAIL PROTECTED] wrote: Thank you Mattias! I will explore it further probably on Sunday and would like to place a few additional questions right now, so that I will maybe find the answers when I come back today late at night: Caption holds the value of the .lfm file, which will eventually be only UTF-8. But at the moment it is not guaranteed and will hold the value in the 'codepage' the creator of the .lfm used. It is planned that the interfaces translate strings on the fly and Caption will be UTF-8. So the above will probably replaced with StrCaption := PChar(UTF8StringToWindowsString(AWinControl.Caption)); or something like that. a1) Since it is also possible that application programmer assigns some value to the Caption property programmatically (i.e. not only at design time in .lfm, which is then used in PrepareCreateWindow): procedure TForm1.Button1Click(Sender: TObject); begin Self.Caption:='123'; end; Of course the programmer is free to assign any value, even not UTF-8. But the LCL will eventually assume it is UTF-8. At the moment it assumes to be the local characterset. I guess that the reader method of the LCL-control Caption property should take care of possible necessity to convert from some code page to UTF-8, before proceeding the value to the widgetset (interface). In my view, it is only then that we can say that the LCL-widgetset boundary is based on UTF8. I guess this is the area you are saying needs to be done. If so, there might be many places that need that check/conversion added and they are all in the LCL part that is independent of the target platform. Do I get the idea right here? Ehm. Maybe yes, maybe no. There are two parts: The .lfm files must be UTF-8 (eventually), because they are copied to other platforms (and because TReader/TWriter uses strings and the lfm does not contain characterset information). The widgetsets are platform dependent. Some even use 2-byte strings (UTF-16). Because the LCL use 1-byte strings the LCL interface must convert them anyway. That's why the conversion from/to UTF-8 right can be put into the LCL interfaces (gtk, win32, ...) and the LCL (TButton, TLabel, ...) stays unchanged. Advantage: Write once, run anywhere. So it is easier to write platform independent code. Disadvantage: When the programmer access platform specific functions and uses strings from the LCL, he is responsible for converting them. So it is harder to write platform dependent code. a2) StrCaption := PChar(UTF8StringToWindowsString(AWinControl.Caption)); If you have the Unicode-enabling for Win32 here in mind (which is my aim and therefore all the questions), as far as I see it, the issue is not so easy. If we are not going to have a separate WS win32w for that (I would personally not be fond of separate WS), then there are lots of things to change in WS win32. Yes. As an example, since procedure FinishCreateWindow will have to decide which winapi to call (*A or *W), i believe we will for instance need an additional TCreateWindowExParamsW (with PWideChars in it), which would be used with *W-Winapi calls. Moreover, FCL is now mapping (conditioned with $define UNICODE or the lack thereof) to either *W, or to *A winapi-functions (as far as I could see), while we will need both worlds to be available to a WS/interface at the same time. I'm not a winapi expert. This decision is up to the windows devels. a3) An important and still opened architectural decision is: Win32-Unicode support into WS Win32, or a new WS Win32w, that would support only WinNT+ machines? Vincent proposed a new WS: http://wiki.lazarus.freepascal.org/index.php/Talk:LCL_Unicode_Support Here the application programmers are also asked for their opinion - is it necessary to support all Win* with one exe, or is it ok to have two, if need be? From the LCL point of view, a new WS would be clearer and easier to develop, but new Controls would then have to be supported in both (and in WinCE too - Roozbeh wrote some ideas too). Mattias an others, I know many of you are very *nux oriented but I would really appreciate any thoughts on these issues, because I do not feel to have the necessary insight to make an educated decision (and these decisions will determine the whole further development of Unicode support for win, if it really ever happens :( I don't know the TNT components mentioned on the wiki. 1. cyrillic or chinese will not work on all platforms. Especially on win9x. That's not the problem. The problem is, that the LCL should display cyrillic characters on all cyrillic systems, no matter, what encoding is used. It is up to programmer to provide translations. But he should only provide one translation per language, not one per language and encoding. 2. Win9x does not support the *W functions. Or more generally speaking: What, if the platform does not
Re: [lazarus] LCL-interface boundary
2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: Wrong. To play with the interface you only need to rebuild the interface. See below. Of course if you want to create a patch for us, then you should at least rebuild the IDE once and check, that your changes didn't broke anything. This raise a question to my mind: how can someone test patches without building the IDE? Right now each time I implement a feature/patch I'm rebuilding the IDE to test. This is a very slow process... Is there a workinf environment to develop in lazarus without rebuilding each time? -- This is probably a dump question, but I really don't know how others work. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question of feature: code browser
Hi Alexandre, I wrote a plugin for Lazarus a while back (Got the idea from GExperts) - not sure if this is what you want, but have a look anyway. I use it constantly in my day-to-day work. It searches your code as you type. It registers the Ctrl+Shift+G to launch and immediately you can start typing a phrase (of a procedure name) you are looking for. More details (and screenshot) on the website below. Lazarus - Procedure List http://opensoft.homeip.net/lazarus/procedurelist.html The code is available in my SubVersion repository (and any submissions are welcome). Maybe we can add this as part of the Lazarus IDE? Regards, Graeme. On 7/15/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: I remember a feature in D6 in the UnitEditor: a vertical code browser for fast-searching in source code. This was a very nice gadget. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] NNTP sever component
Hi, Anybody know of a NNTP server component I can use with Lazarus or FreePascal? I would like to write a News Server that uses the Firebird DB as backend. Regards, Graeme. -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] LCL-interface boundary
On Sat, 15 Jul 2006 09:38:10 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: 2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: Wrong. To play with the interface you only need to rebuild the interface. See below. Of course if you want to create a patch for us, then you should at least rebuild the IDE once and check, that your changes didn't broke anything. This raise a question to my mind: how can someone test patches without building the IDE? Right now each time I implement a feature/patch I'm rebuilding the IDE to test. This is a very slow process... Is there a workinf environment to develop in lazarus without rebuilding each time? -- This is probably a dump question, but I really don't know how others work. As written in the former mails: Create a small test project and build only the changed parts of Lazarus. When everything works, then test the IDE once. And maybe: Under non windows linking the IDE only takes a few seconds. I heard the new internal linker under windows does the same. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question of feature: code browser
On Sat, 15 Jul 2006 09:35:29 -0400
Alexandre Leclerc [EMAIL PROTECTED] wrote:
I remember a feature in D6 in the UnitEditor: a vertical code browser
for fast-searching in source code. This was a very nice gadget.
Do you mean the View - Code Explorer?
1. Any-one work[ed,ing] on this?
No.
2. Can I use VirtualTreeView as a new component/source dependency to
implement such a feature? (It has everything required to build such a
tool.) If no, what should be used?
Yes. But then it will be an external plugin.
3. I was planning to develop this in another form, then dock that form
in the UnitEditor if desired. I know this mechanism is not working
well right now, but some patches are working... Should this avenue be
kept?
Yes. I'm currently fixing bugs, but Docking is definitely one of my next
goals.
4. I'm sure there are already functions and tools to get information
about a source file's structure (interface, implementation,
initialization, finalization) but where is it?
codetools
5. I'm sure there are already functions and tools to get all the type
/ classes / procedures / functions in the interface section of a
source file... but where is it? (I assume that because of
code-completion Ctrl+c that works well.)
See the code explorer for an example.
6. I'm sure there are already functions and tools to get all the types
/ var / procedures / functions present in the implementation part of a
source file... but where can I find these?
See the code explorer for an example.
7. Any function to detect {$i include.inc} in a source file?
All codetools support include files.
(I
personally hate these, but I know someone talked about code-folding
such include files: that would be awesome,
Yes, but it would require a lot of changes to synedit.
especially if a search in a
document would extend into the .inc files too...
Use Search - 'Find in files'.
Otherwise: Extend Find/Replace to use functions of 'Find in files'.
this is another
feature I want to work on, because searching is a pain...
Ehm, what and how do you search?
and also
working on another feature: there is 'find declaration' but 'find
implementation' is missing...)
Do you mean Ctrl+Shift+Up ?
Mattias
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] LCL-interface boundary
2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: And maybe: Under non windows linking the IDE only takes a few seconds. I heard the new internal linker under windows does the same. Yes, this is why I use svn FPC version (the moment they are enought stable) because my code compiles very fast! Linking is still slow but this is much better than it was with previous fpc versions. Thanks. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question of feature: code browser
2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: On Sat, 15 Jul 2006 09:35:29 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: I remember a feature in D6 in the UnitEditor: a vertical code browser for fast-searching in source code. This was a very nice gadget. Do you mean the View - Code Explorer? Yes, exactly that. I see a lot of work has already been done. Next step is to dock that in the UnitEditor. I see many features are already in lazarus, but simply not at hand or don't know about it. The work left is almost better UI integration and presentation. I see that the goto stuff is not working on my version. I'll be able to work on this. 4. I'm sure there are already functions and tools to get information about a source file's structure (interface, implementation, initialization, finalization) but where is it? codetools Ok, I also see examples of codetools that you made. I'll take a look at all that. (I personally hate these, but I know someone talked about code-folding such include files: that would be awesome, Yes, but it would require a lot of changes to synedit. Maybe one day! :) Post 1.0 especially if a search in a document would extend into the .inc files too... Use Search - 'Find in files'. Otherwise: Extend Find/Replace to use functions of 'Find in files'. Search in document is too broad sometimes, or you always need to change the directory where you want to search. Some changes could enhance the behaviour... this is another feature I want to work on, because searching is a pain... Ehm, what and how do you search? How Ctrl+F :) Sometimes when diging in the LCL you want to see the implementation of a function. (Ctrl+Shift+Up) But other times parts of a string... but the actual find is not going in the include files. But I think this will be useless now, because most of the time it was for the implementation of a procedure. and also working on another feature: there is 'find declaration' but 'find implementation' is missing...) Do you mean Ctrl+Shift+Up ? Yes! This is what I was looking for. Thank you. Is there a place where all these features are documented? :) I see that many of them I'm missing and was about to code already exist. Thank you very much for your time. My coding life with Lazarus has enhanced a lot now :) -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question of feature: code browser
Alexandre Leclerc wrote: 2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: On Sat, 15 Jul 2006 09:35:29 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: I remember a feature in D6 in the UnitEditor: a vertical code browser for fast-searching in source code. This was a very nice gadget. Do you mean the View - Code Explorer? Yes, exactly that. I see a lot of work has already been done. Next step is to dock that in the UnitEditor. I see many features are already in lazarus, but simply not at hand or don't know about it. The work left is almost better UI integration and presentation. Did you take a look at the TStudio layout? It doesn't use the docking subsystem, because that still needs some work, but it statically docks the complete IDE, with variable splitters, as a stop-gap solution. I even have a new version lined up, that supports docking non-modal dialogs like the Search Window, and the debug windows. There is also a TDockMgr that makes docking a snap, but that is based on the docking subsystem, which still needs some work. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Mousewheel action broken
It seems that 9616 broke the mousewheel operation.This has been confirmed on IRC. Darius
Re: [lazarus] Question of feature: code browser
2006/7/15, Al Boldi [EMAIL PROTECTED]: Alexandre Leclerc wrote: 2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: On Sat, 15 Jul 2006 09:35:29 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: I remember a feature in D6 in the UnitEditor: a vertical code browser for fast-searching in source code. This was a very nice gadget. Do you mean the View - Code Explorer? Yes, exactly that. I see a lot of work has already been done. Next step is to dock that in the UnitEditor. I see many features are already in lazarus, but simply not at hand or don't know about it. The work left is almost better UI integration and presentation. Did you take a look at the TStudio layout? It doesn't use the docking subsystem, because that still needs some work, but it statically docks the complete IDE, with variable splitters, as a stop-gap solution. No I did not see that... I'll take a look in the source code. What has to be done to build the IDE with it? Usually I do not like complete docked IDE's (MDI). I like at least 3 separate windows... as traditionnal delphi. Using F11 F12 is good integration for me :) But evevrything related to units (browsing code, history, tools, etc.) I like to have that all together. I saw the new IDE of D2005... but did not like it. I must say I never worked with it too. It was a demo version from borland. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Mousewheel action broken
On Sat, 15 Jul 2006 18:13:40 +0200 Darius Blaszijk [EMAIL PROTECTED] wrote: It seems that 9616 broke the mousewheel operation. This has been confirmed on IRC. What mousewheel operation? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Question of feature: code browser
Alexandre Leclerc wrote: 2006/7/15, Al Boldi [EMAIL PROTECTED]: Alexandre Leclerc wrote: 2006/7/15, Mattias Gaertner [EMAIL PROTECTED]: On Sat, 15 Jul 2006 09:35:29 -0400 Alexandre Leclerc [EMAIL PROTECTED] wrote: I remember a feature in D6 in the UnitEditor: a vertical code browser for fast-searching in source code. This was a very nice gadget. Do you mean the View - Code Explorer? Yes, exactly that. I see a lot of work has already been done. Next step is to dock that in the UnitEditor. I see many features are already in lazarus, but simply not at hand or don't know about it. The work left is almost better UI integration and presentation. Did you take a look at the TStudio layout? It doesn't use the docking subsystem, because that still needs some work, but it statically docks the complete IDE, with variable splitters, as a stop-gap solution. No I did not see that... I'll take a look in the source code. What has to be done to build the IDE with it? It works by hooking it into main.pp with something like this: IDEloStyle.TStudio.Create(Self).Show; Note, keep the following windows open before calling: ProjectInspector ObjectInspector CodeExplorer Messages Usually I do not like complete docked IDE's (MDI). I like at least 3 separate windows... as traditionnal delphi. Using F11 F12 is good integration for me :) But evevrything related to units (browsing code, history, tools, etc.) I like to have that all together. With opensource you can change it to your liking. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] To the guy that answered my SuSE question
I tried making those links, and they didn't seem to work in fixing lazarus to where it could link. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Mousewheel action broken
Scrolling with the mousewheel in the uniteditor I mean. Darius - Original Message - From: Mattias Gaertner [EMAIL PROTECTED] To: lazarus@miraclec.com Sent: Saturday, July 15, 2006 6:27 PM Subject: Re: [lazarus] Mousewheel action broken On Sat, 15 Jul 2006 18:13:40 +0200 Darius Blaszijk [EMAIL PROTECTED] wrote: It seems that 9616 broke the mousewheel operation. This has been confirmed on IRC. What mousewheel operation? 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] Question of feature: code browser
With opensource you can change it to your liking. I suppose you mean free software, not open source. There is a lot of open soruced softwares out there that doesn't allow you to change their code. -- Lepidosteus http://lepidosteus.com _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
