Re: [Lazarus] Live Templates
Lee Jenkins schrieb: Graeme's recent post made me wonder if there is been work or talk of work on implementing Live Templates like Delphi has? My experience with Live Templates: they are nice to use, but so hard to write properly, that no user will ever try to write a template himself. Then it does not make a difference, whether the templates are implemented in code (codetools), or as scripts. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Martin Friebe schrieb: 2) Find in files, Messages and Code observer should be merged together, with interface most resembling Find in files IMHO, this (point 2) would be even more a specialization. Also I can't see how those 3 relate at all. They can use the same Search Results window for their output. That window will know what to do (show related place in source code) when an entry is clicked. Anyway, for that lets wait for docking. Some notes on docking: The Messages and Search Results can be docked to the IDE main window, eventually by default. The docking of forms is unsupported on many platforms, due to the different management of controls (widgetset) and windows (window manager). So all dockable windows should contain one single component for their entire content. (or the forms should float as clients of a floating form). This requirement lead me to another suggestion: When one or more forms are docked into another window, their UI (menus, toolbars...) could be added to the dock host form's UI. Just an idea... what about: - keybard layouts? - Menu layouts? Some visual design for toolbars (and menus) would be nice, as in the Delphi IDE window (configure by dragdrop from the list of available options to a toolbar). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Graeme Geldenhuys schrieb: Yes, documentation is good. But it is well-known fact that users do not read documentation ;-) Exactly why I decided on using animated gifs. User only needs to view them and not read content to get the idea of a feature. :) Users who don't want to waste time with reading, also won't want to waste time with videos - in detail when they found out after the first video that the demonstrated feature does not fit their needs. IMO the wiki should be structured in a strict way, e.g. all search features should be summarized together. Two subsections search what/where and search how. Quick/incremental search obviously should go into the search how category. Sorry, I meant Procedure List. Before merging with code explorer I'd like this to be discussed first! Like I mentioned before, procedure list is an integral part of my coding. I use it 1000's of times per day to navigate code - QUICKLY. :) Could it be extended by a list of favorites? I.e. a configurable list of currently used/related/important procedures - similar to bookmarks, but more expressive with only the names of procedures (or types...). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Alexander Klenin schrieb: All floating windows should be dockable. We have already a docking manager. The missing part is to finish the save/restore of the layout. I started to look at fixing save/restore once, but dropped it since docking is being rewritten by Hans-Peter Diettrich It will be implemented soon. Currently it's abused for an dump of the internal tree structure (debug feature). A redesign of the dockable IDE windows may be required, so that dragdock will work on all platforms. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Graeme Geldenhuys schrieb: The problem with Code Explorer and FPDoc Editor type windows is that they use processing power as you navigate or switch units. Apropos switch units: who made the editor tab shifting almost useless? IMO the scroll buttons should scroll the editor tabs by pages, not activate the next left/right tab. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Mattias Gärtner schrieb: I plan more tools like the code browser - that scans whole source trees and need two or three hundred megabytes. But these tools will not be invoked by default and they share the same memory. The code explorer can be seen as the map in a master-detail view. Then the file list (editor tabs) also could be added to the code explorer. Every (future) editor window should have its own code explorer. BTW, the memory consumption should be a fraction of your estimate, because every node only contains the identifier name and a file reference and position. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Alexander Klenin schrieb: IMO the scroll buttons should scroll the editor tabs by pages, not activate the next left/right tab. I prefer the current way. I guess that depends on the number of units opened a once -- I usually try not to have too many. Unit Controls plus the *.inc files does not fit in one page, not to count further relations down into the widgetset. When I need the current project as well, I often have more than 20 files open at the same time. [this is only one argument against the use of include files, and for multiple editor windows ;-] DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
Leslie Kaye schrieb: Pleas do not have docking in the UI!!! It might look cool bot it is a pain to use and program. Program what? Windows accidentally un-dock and attach to your mouse then end up anywhere so you spend ages trying to get it back to how it was. This happens only with the bad Delphi defaults, where docking starts immediately. The Lazarus IDE can override that behaviour, as does the Delphi IDE. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Invalid component names
Mattias Gaertner schrieb: So the remaining question is: How to assign unique names to dynamically created components? Does there exist an immediately usable method or function? Empty names seem to be harmless, but every attempt to assign an non-empty and already used name to a component results in an exception. What's the scope (list of names...), within which every component must have an unique name? Have you looked at TComponent.SetName? Thanks, that answers the latter question. Nonetheless there should exist a method, at least in the form designer, for creating unique names. Where is it? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Invalid component names
Gabor Boros schrieb: I always use the variable's name to component name. var MyLabel15:TLabel; begin MyLabel15:=TLabel.Create(Self); MyLabel15.Name:='MyLabel15'; end; Exactly this code will cause an exception, when the procedure is called more than once - as I need it to create multiple floating controls. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Invalid component names
Vincent Snijders schrieb: Exactly this code will cause an exception, when the procedure is called more than once - as I need it to create multiple floating controls. Why do you want to give the controls names? Names are convenient to identify floating windows (label title bars) or docked controls (dock header label), and are required for the de/serialization of docking layouts. But you are right in so far, as dynamically created controls are of little use in the recreation of a docking layout. In this case the names should be hardwired somehow, so that the appropriate controls can be created from the stored layout. I'll have to re-think this issue in the implementation of multiple editor windows and the related forms. Then e.g. the code explorer windows etc. must be linked to the edit control in their dock site, regardless of their name in creation order. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Invalid component names
Gerard N/A schrieb: Nonetheless there should exist a method, at least in the form designer, for creating unique names. Where is it? Have a look at function TCustomFormEditor.CreateUniqueComponentName in ide\customformeditor.pp Thanks :-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] EXC_BAD_ACCESS, Could not access memory
Bart schrieb: I'm not even sure that Extended has the same size on all platforms. What size might it have, other than the FPU defined size? If you need to read those records, created with Delphi/Kylix now on MacOS and you cannot solve how to declare your record, you could as a last resort read x bytes (where x is the size of the delphi record on disk) and translate theis sequence of bytes to the values you want. If nothing else helps, it should be sufficient to use packed records with inserted dummy fields for the original record layout. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Invalid component names
On Win32 every component (at least control) gets an unique Name on creation. On Linux a dynamically created control has an empty name. Is this a Lazarus or FPC problem? I could not trace down to the point where the name is assigned in win32, because Lazarus denies setting an breakpoint on TComponent.SetName :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Missing keyboard input
The TWinControl.DoKeyDownBeforeInterface method seems never to be called? At least on on Linux/gtk2... DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Making a auto-complete dropdown list
闫程远 schrieb: nonono,i didn't mean that. i was considering why the inputbox TEdit losts its focus,even if i setfocus. the lost of focus make me mad because when the dropdownform is shown,i have to click the TEdit and begin typing again and again. Untested: Try to make the old *form* Active, because only the active form (or a component on it) can receive the focus. If this helps, it's worth further investigations WRT platform compatibility. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Invalid component names
Gabor Boros schrieb: Dynamically created components have empty name after creation on Win32 too. This thing is true for Delphi too. This is normal I think. Right, I was misleaded by different settings in my various test projects. Only forms get an unique name, and this works in Lazarus as well as in Delphi. So the remaining question is: How to assign unique names to dynamically created components? Does there exist an immediately usable method or function? Empty names seem to be harmless, but every attempt to assign an non-empty and already used name to a component results in an exception. What's the scope (list of names...), within which every component must have an unique name? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] EXC_BAD_ACCESS, Could not access memory
Roland Turcan schrieb: BB How is HeaderLen declared ? Stream.Read (HeaderLen, SIZEOF (HeaderLen)); where information header's length is stored into binary. The you should verify that HeaderLen = SizeOf(FHeader), before Stream.Read (FHeader, HeaderLen); Otherwise this statement will overwrite the following FItem data, with the fatal consequences you already experienced. When a header will ever change in size (or structure), it's wise to store a version number in the data files. Then you can read the stored header data into the exactly applicable header type (record), and convert that record into the current THeader definition, field by field. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] EXC_BAD_ACCESS, Could not access memory
Roland Turcan schrieb: TYPE TMyObject =class private FHeader:TSomeHeader; FItems :TSomethingArr; ... FUNCTION TMyObject.LoadFromStream (Stream:TStream):BOOLEAN; ... SetLength (FItems, 0); //!! for testing only -- this line works fine Stream.Read (FHeader, HeaderLen); SetLength (FItems, 0); //!! for testing only -- this line raises an exception END; IMO the problem is HeaderLen. What if you use SizeOf(FHeader) instead? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TDateEdit.Date is not published...why?
Graeme Geldenhuys schrieb: You would need to know at least what is the exchange rate for a given conversion. And the currency type and the rounding method use (maybe even per currency) and the preferred decimal numbers used (again maybe per currency) etc... Monetary calculations often are prescribed precisely, e.g. for taxes. These prescriptions as well as the preferred scaling are country specific. We just had a discussion about currencies where the base unit equals e.g. 1E-6 USD, where 64 bit and 4 decimal places are no more applicable, even for calculations in one currency. Something that seemed so simple in the beginning can become quite a complex task. ;-) Now similar issue can be applied to TDateTime and String types. Unlike other measure types (including date, temparature, length...), currencies have variable conversion rules or factors. In former days (some) currencies were based on gold or silver (Pound Sterling, Silverdollar, Goldmark...), usable as a common base for exchange calculations, but nowadays IMO all currencies are floating. Any fixed conversion methods will result in kind of weather forecast ;-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Dragging documented
Felipe Monteiro de Carvalho schrieb: So I couldn't resist to add some criticism about the current LCL implementation. Any comments are welcome :-) I think you should be more specific if you want to do a criticism. In the way you put it one can have no idea what exactly you are taking about. [ ] You have read section 3: LCL Implementation DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Dragging documented
I've started documentation about dragging, with the first part (drag-drop) here: http://wiki.lazarus.freepascal.org/LCL_Drag_Drop This page shall explain general principles behind dragging, one or more pages about docking will follow. My research started in Delphi 2.0, where only drag-drop is supported. So far the Delphi model is fine, but the extensions for drag-dock support are both poorly designed *and* implemented. Obviously nobody at Borland or CodeGear ever dared to touch that crap, the same bugs persist in the RAD Studio versions - and also in the LCL, of course :-( So I couldn't resist to add some criticism about the current LCL implementation. Any comments are welcome :-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Why we chose Object Pascal instead
Graeme Geldenhuys schrieb: I can't agree more... We have had this exact same issue in our company (before I arrived). They hired cheap (inexperienced) developers that caused havoc in the code. They make the GUI seem fine for a while, but underneath the design (if there actually was a design) is totally rubbish and unable to cope with new requirements. Hence the reason I was commissioned to do a total rewrite. That's why neither Cobol nor VB will ever die: they make secure long-term jobs DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] revision numbers of each SVN tag?
Graeme Geldenhuys schrieb: Yes, but beware the some of them got merges from trunk afterwards. For instance, lazarus_0_9_26_2 is based on 18716, and r18269 got merged resulting in r18898. So you cannot simpy use r18898 for the tag. I noticed that... Doesn't that defeat the point of tags??? Branches are used for merging things. Tags should be set in stone - a snapshot at a specific point in time. I'll second that. Later fixes should be supplied as patches (AKA service packs), IMO. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Docking again (ATN: Mattias)
Now an extended docking model and a new docking manager has been tested and partially integrated into the LCL. The new model extends the flawed Delphi model, without breaking compatibility. Full integration and fixing of related issues (widgetset?) deserve some discussion. See uploads for Patches #13427. Most important issues: What's the purpose of the TDragManager class? Is it designed for support of user-defined drag managers, or can it be removed? Same question about TDrag/DockPerformers. Delphi also allows for some customization of the visualization etc. in the drag/dock objects, but the current LCL implementation bypasses such extensions. What's the reason for *not* using the customizable methods in these objects? If nobody can answer the above questions, Paul will update the LCL as appropriate. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] revision numbers of each SVN tag?
Graeme Geldenhuys schrieb: The difference between tags and branches does only exist in the naming convention, nothing more. Now I'm starting to appreciate Linus's talk about Git at Google Talk. SubVersion really has a brain-dead design. ;-) SubVersion had to be compatible with the old SVN, so that existing repositories could be moved easily. In future I would recommend using branches and when a release is announced, then only create a tag. Cumbersome. Funny how the SubVersion documentation says that is exactly how you are supposed to use tags. If you start committing to a tag, it is NOT a snapshot in time any more and is now considered a branch. I have been working on many SubVersion repositories from various projects. Everybody gets that concept, but the Lazarus developers don't. We should distinguish between implementation and use of tags. Using tags for anything but immutable milestones is an abuse of the SVN features, and it's a weak excuse that it's possible, so we do it :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
Graeme Geldenhuys schrieb: I thought this was known: http://wiki.lazarus.freepascal.org/DesignGuidelines This is the first I here of this. Me 2. I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size. Smartlinking is not directly affected by Uses. Instead it's most often the code in used unit Initzialization sections, that makes all related code part of the executable. E.g. when initialization code creates objects or references subroutines, that are not otherwise used by the application code, a smart linker cannot exclude that definitely referenced code. Similarly virtual methods: they are referenced in the VMT, which again is referenced in every instance of the class. Consequently virtual methods must become part of the executable, as soon as a class typename is used in any way in an application. Static methods, in contrast, can be safely omitted when not referenced anywhere else. IMO. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
Reenen Laurie schrieb: Just a note: some people think that units can be compiled in one pass - this is not true. The compiler must stop on every Uses clause, and So .exe's should be (much) smaller if your uses units are put mostly in implementation No, that's not related at all. If we have to do multipass why is it necessary to have a distinction at all? The compiler must know where to stop pass 1 - and that place is the begin of the implementation section. When the interface section uses definitions from other units, all these units must become part of the interface uses clause, so that the compiler can compile these units before. The distinction between interface and implementation also allows to recompile only selected units. When only the implementation section of a unit changes, it's sufficient to recompile only that unit. When the interface part changes, also all those units must be recompiled, which use that unit. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
Mattias Gaertner schrieb:
Now we can go on-topic: While FPC already supports true unit alias,
Lazarus (code completion...) cannot handle unit1B in your example :-(
Have you updated to svn 19249?
I've just updated to svn 19273, and the problem persists.
Though, Lazarus says SVN 19172 in the About dialog, after a full rebuild?
If yes: please provide an example.
unit Unit2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Forms;
function MyText: string;
implementation
uses
myform in 'unit1.pas';
function MyText: string;
begin
Result := myform.Form1.Edit1.Text + '+';
end;
end.
Unit1 is a simple form with an edit control.
In the above line, starting from myform none of the identifiers is
recognized. No jump to declaration, no code completion, nada :-(
DoDi
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
dmitry boyarintsev schrieb: why aliases units names are required? E.g. when you have multiple third-party units of the same name. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] OT: Namespaces?
From a discussion I want to present this idea: FPC (and Delphi) could extend the Uses syntax to USES unitname [IN filename] [AS identifier] The optional AS part would allow to create an alias (shortcut...) for units of possibly conflicting (same) name. IMO a simple implementation of the most important benefits of namespaces, that does not require the introduction of orthogonal namespaces in addition to units. While this suggestion is not related to Lazarus, I still would appreciate comments from the community. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Clipboard.HasFormat issue
Michael Van Canneyt schrieb: Is there a reason why ClipBoard.HasFormat() is so slow ? Putting a call to ClipBoard.HasFormat() in an OnUpdate handler of an action coupled to a toolbutton, seriously slows down an application, to the point of being unusable. If I comment out the call, the application responds normally. The request may go to the clipboard owner, which is responsible for providing the clipboard contents in the various formats. The system also may search for conversion tools, capable to render the desired format from one of the supplied formats. This is on Linux (GTK1). I looked at the clipboard calls, but on the first look of things I see no reason why it should be so slow, except maybe the ClipboardGetFormats() call. I only know about the Windows clipboard, not on other systems. The graphics system should not be involved on any platform. The strange thing is that if something suitable is on the clipboard, the application responds normally. Isn't there a method EnumClipboardFormats, which should return only the currently available formats? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Controlling DPI
David W Noon schrieb: Windows allows to change the font size (DPI) at any time, and most other systems have similar capabilities. Since Delphi has its roots in Windows, this definition also should apply to FPC/Lazarus. The *point size* of the font has nothing whatsoever to do with the DPI of the screen or printer, other than the rendering engine querying the DPI of the device in order to render the text to the appropriate size in pica points. Right. The application provides a font size, and the system translates it into pixels, based on the Screen.DPI value. Pixel based sizes, as used in the LCL for the origin and extent of the forms and controls, are not affected by the DPI settings. If you want to change that DPI factor, your application can scale the size of every used font accordingly. Please specify if you have something else in mind, like an zoom factor for *all* elements of your application. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Flávio Etrusco schrieb: What is the function of being able to add methods to records? Not much, I agree, given the existence of objects. It would be better to do that instead of introducing 'object' keyword, but that decision was made back in the days of Borland Pascal. Indeed, not much, but the memory savings can be really interesting in some situations. The storage of class instances can be modified by overriding the according methods. I did so for arrays of instances, and it worked fine in Delphi. With some tricks it should be possible to have both static and dynamic allocation, for the same class type. I also found at least one use for records with methods, in the emulation of C structs with bitfields or unions. For that matter 'object' and properties came in handy. IMO one difference between class and record will stay that records cannot have virtual methods (in Delphi), due to the inlined VMT pointers. Another difference will be heritage - records are not extensible. BTW, 'object' became deprecated (in Delphi) only when the reference-counted data types have been introduced. Delphi (willingly) doesn't support properly objects inheriting from another object type, in which case only the top level type is initialized and finalized properly. I wonder why the same construct with records (nested in records) has been made work, then. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Graeme Geldenhuys schrieb: HasNext() Returns true if the collection has more items when traversing the collection in the forward direction. This (and the Peek methods) require that the collection is organized strictly sequential, for Previous in both directions. The implementation for an DataSet can consume an considerable amount of time for such operations. It looks to me as if such an iterator interface has very limited practical use. Remove() Removes from the collection the last item that was returned by the Next() or Previous() calls. (optional modifier operation) SetItem(item) Replaces the last item returned by the Next() or Previous() calls with the specified item. (optional modifier operation) Which element will the iterator represent, after such an operation? After Remove it has to represent the next or previous item, depending on the direction of traversion. A *huge* benefit of using iterators, is that the developers doesn't need to worry about if the list/container is 0-based or 1-based, how to get the next or previous item etc... It now gives the developer a consistent interface API to work with, no matter what is being iterated. Nice try, but I prefer the slimmer Count and Item[] interface, with a chance to remember the index of a found item, and with immediate use of an item without an type cast. I.e. I never used collections at all, but that's not an argument against using collections and iterators at all, only my personal preference ;-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Alexander Klenin schrieb: Since string was introduced as built-in scalar type with defined equality, lack of 'case' support can be viewed as a design bug. IMO strings are similarly scalar as are floating point numbers, with regards to 'case'. Note that I said with defined equality. The reason 'case' should not include floating point numbers is that equality if not usefully defined for them. The same for strings, where mere binary (case sensitive) equality often is useless. Furthermore Pascal 'case' supports ranges, which deserve a stricter order than only equality. Then the sort order of strings also depends on the encoding (codepage, MBCS, UTF...). And last not least strings IMO are complex types (array of char), as they have been in Wirth Pascal. The order of a comparison of ordinals is O(1), whereas string comparison is O(n). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Alexander Klenin schrieb: Many Delphi extensions to the Pascal language break fundamental design rules. It's bad enough that FPC (and Lazarus) has to support such aberrations for compatibility reasons, I agree that some extensions were suboptimally designed, in particular dynamic arrays, but aberrations? Can you give an example? Delphi 2 (or 3?) was the last version with a grammar for the language. After that version the supplied OPL grammar is neither correct nor complete, the language is no more LL(1). While I deeply respect Wirth's contributions to programming language design, I think Modula and especially Oberon are not the best sources for inspiration. I dare to disagree. Object Pascal has log ago taken different direction -- for example, if we take into account Oberon, then we should, as a first step, remove strings, classes, virtual functions and for loop. I do not think this is a good way to evolve FPC ;-) Please note that I don't ask for Modula or Oberon compatibility, even if it were fine to have such modes. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Alexander Klenin schrieb: Delphi 2 (or 3?) was the last version with a grammar for the language. After that version the supplied OPL grammar is neither correct nor complete, the language is no more LL(1). It is historically interesting, but does it really matter? I'd call it serious, when a single semicolon can change the meaning of the source code (before a case else). The important characteristic of the syntax is its convenience to humans, and if that requires slightly more work from the compiler, then so be it. AFAIK, most modern compilers moved to recursive descent parsers due to similar reasons. Just hand written recursive descent parsers leave room for any kind of irregular behaviour :-( While I deeply respect Wirth's contributions to programming language design, I think Modula and especially Oberon are not the best sources for inspiration. I dare to disagree. Present your examples then ;-) I don't want to go into details here. The design of a language is so complex, most decisions depend on others, and they must fit all together. Besides that, what useful features do you think Object Pascal / FPC might take from Oberon? More important is what *not* should be taken from other languages. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
Alexander Klenin schrieb: Generally, I feel that FPC is a bit too conservative. I understand that a healthy dose if skepticism is a good thing for language design, but IMHO it was taken too far lately. Many Delphi extensions to the Pascal language break fundamental design rules. It's bad enough that FPC (and Lazarus) has to support such aberrations for compatibility reasons, but further extensions should be added very carefully, taking into account the design and experiences with the successor languages (Modula, Oberon...). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Michael Van Canneyt schrieb: An unhandled exception IMO is due to some software bug, which the user cannot cure in any way. That's a very restrictive definition of exception. An exception is a way to stop the normal logic and flow of the program. ACK. And try-except clauses are the way to catch exceptions. In a GUI application, you rely on the program's event loop to catch the exception I never did so, for my own or otherwise expected exceptions. (so it is definitely handled) and to show it to the user. If you don't want it to be shown, use the Abort exception. Please don't confuse exception catching and handling. Only catching exceptions can (mostly will) leave the application in an invalid state, so that an abort is the only reasonable handling. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Where are the manuals?
YanChengyuan schrieb: lazarus is free and useful,and i'm glad with that. but where are the manuals? i do have read some books on Delphi Programming ,but they are for newbies,and talked about things like TEdit,TLabel only.how come that i know how to use things like TIPHtmlPanel,THtmlBrowserHelpViewerand things like that without a manual ? the lazarus wiki isn't useful on this matter at all! There should exist sample applications, used in testing the implementation, with some notes about the intended use of every sophisticated component. i scanned millions of pages from google to know a little about a component,and most of the infomation i got was far outdated.why can not our developers write some mannuals while making some components? Unfortunately most Lazarus developers prefer to add new features, instead of writing documentation :-( It's fun to make kids, but no fun to have them afterwards ;-] DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Where are the manuals?
Felipe Monteiro de Carvalho schrieb: We are writting a book about it, but it's not yet ready ... How can I contribute? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
Michael Van Canneyt schrieb: Is there a reason why the default exception dialog has a cancel button to kill the application ? An unhandled exception IMO is due to some software bug, which the user cannot cure in any way. We often use an exception to signal wrong entry of data or so, because it stops all further processing. That's okay, if you also implement appropriate exception handling. Exceptions are fine in error situations, that cannot be cured at the place of their occurence. It's up to the program designer to find the best place for handling every intentional exception. If the user then uses the cancel button, the program is simply ended, which is not what we (or better: the users) want. And I imagine many others use this technique. No, hopefully not :-( I have overridden the OnException handler of TApplication, so it's no longer a problem, but I was curious as to why this is done like this by default ? Insert your exception handler in an more appropriate place, depending on the concrete application. The user can expect a diagnosis of what went wrong, and a chance for correcting his preceding input. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Martin Friebe schrieb: Are all 3 files units? with unit keyword at the start, and implementation/interface sections if you have an include file, with no unit, no interface / implementation = then procedure is the top level fold (divider level = 1) The next logical step is unfolding include directives, so that the included files can be inlined in the editor. This is what Delphi users will need urgently, and every user will appreciate the capability of searching and find-and-replace in the entire resulting text. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Graeme Geldenhuys schrieb: - Folding at procedure in addition to the begin = arguable, if it should be instead of the begin? I'm not sure about this one either. I would have thought the first 'begin' after a procedure or function should be ok. Procedures can have large parameter lists, type, var and const sections, in addition to the code body. When a procedure is of no (visual) interest, all that should go out of the way at once. Folding should recognize two tree structures: 1) sequential sections, like case labels or above type/var sections 2) nested blocks, like arbitrary begin/end pairs Type 1 sections only have an label, and extend until the next sibling. Type 2 blocks have both head and tail delimiters. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
Graeme Geldenhuys schrieb: I was thinking about 'find' and 'find-and-replace' to work for include files as well, but I could get my head around a solution. Think about FPC code where includes are based on platforms. Yes, I know that. This practice is almost the only argument for using include files at all. You have the same include name, but different implementations depending on the platform. How do you inline something like that, or search across such includes? Exactly as the IDE does it, in the navigation between a class definition and method implementation. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Bugs in Delphi DragTo?
I suspect at least one error in the Controls.DragTo procedure: if DragImageList nil then begin if (Target = nil) or (csDisplayDragImage in Target.ControlStyle) or DragObject.AlwaysShowDragImages then begin DragImageList.DragCursor := DragCursor; if not DragImageList.Dragging then DragImageList.BeginDrag(GetDeskTopWindow, Pos.X, Pos.Y) else DragImageList.DragMove(Pos.X, Pos.Y); end else begin DragImageList.EndDrag; 1 Windows.SetCursor(Screen.Cursors[DragCursor]); end; end; -- 2 Windows.SetCursor(Screen.Cursors[DragCursor]); if ActiveDrag = dopDock then [...] 1) EndDrag is called whenever the mouse moves over no valid target (Target=nil). IMO EndDrag should be called only once, when dragging is finished. EndDrag is not appropriate for hiding the drag image temporarily. 2) The duplicate call to SetCursor (and more) suggests to me that the second SetCursor should reside in the Else branch of the outer If, so that it is *not* called after DragImageList.DragMove, just as implemented in the inner If. Opinions? Lazarus uses almost the same implementation in TDragPerformer, what IMO should be fixed. Furthermore I wonder whether it makes sense to show both a drag image *and* an docking frame (in the code below the above snippet, when ActiveDrag=dopDock). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Unable to find the unit if the component class TNoBackPage
Roland Turcan schrieb: I have my own component, which successfully installed into Lazarus. When I use this component on any form after reopening/reloading form it reports an error. That is a simple notebook implementation with no background to get pages transparent. What's this? constructor TNoBackNotebook.Create(AOwner: TComponent); [...] if not Registered then begin Classes.RegisterClasses([TNoBackPage]); Registered := True; end; end; IMO the registration should occur in a Register procedure in the unit, at least *before* any instance is created. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot change keyboard layout
Hans-Peter Diettrich schrieb: The editor options dialog seems not to honor an change in the keyboard layout, e.g. to TP. It always comes up with the default selected. Even worse: now I can only add text, but cannot delete anything! Neither Delete, Backspace, ^Y, ^X etc. seem to work any more :-( How to repair? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cannot change keyboard layout
Hans-Peter Diettrich schrieb: The editor options dialog seems not to honor an change in the keyboard layout, e.g. to TP. It always comes up with the default selected. An inspection of the commands in the keymap reveals bad character codes in the entire table, like word(68475), after the above change. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] About 0013268: SynEdit parses every li ne twice on load or paste (Attn: Flávio)
Flávio Etrusco schrieb: Calling BeginUpdate is not enough, they must disable/unset the highlighter to avoid the double parse. I found it sufficient when the highlighter only parses the current line(s) while painting the text. When the highlighter information is reduced to a flag, indicating continuation lines in multi-line comments, this flag can be stored together with the informaton about the line begin in the text (line number table). Then the determination of the line positions can be done by the highlighter/parser base class. Later, when text is displayed, the continuation flag of the current line is passed to the highlighter, so that only the requested line has to be parsed. Things can become more complicated, of course, when e.g. matching pairs (begin-end, parentheses...) shall be highlighted dynamically. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GPL'ed projects and closed-sourced tools
svaa schrieb: In Ada language forum they have had many times this discussion. The following are the constant conclusions: Dynamic linking has nothing to do with GPL. If DLLs are GPL and you use them, you must grant access to the source of DLL, not to the full project. Static linking of GPL tools require you to publish the final product as GPL, and grant access to the sources of the full project. IMO the kind of linking is irrelevant. When a project makes use of GPL'ed modules, it has to be GPL'ed itself. For libraries the LGPL has been released, which does not infect the users. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] implicit undo (attn Flávio) [Re : Code Structure / SourceEdit and SyneEdit]
Martin Friebe schrieb: My vision deviates a bit from this in the sense that TAbstractSynEdit would just be an abstraction (or dedicated implementation) of a cleaner text manipulation interface (as TStrings won't cut it), which would also implement transparent/automatic/implicit 'undo' handling. Then each command would be a class, probably inheriting from TAction. Just read this, I had the same idea, and am in progress with something like this. I needed it to abstract layers of functionality. for example trimming trailing spaces. If it should work as a transparent plugin it needs access to undo/redo. IMO an abstract base class better should be a viewer, without text manipulation commands. This would allow to sort out problems related to undo/redo for debugging. My current approach is: - I separated SynEdit.Lines from the internal textbuffer (so textbuffer has no longer a need to be TStrings based (it still is, because i didn't take the time to change it)) The TStrings approach isn't really bad. The virtual Get method can access any kind of buffer, and we don't have to introduce new names for the basic methods and properties, reducing possible confusion of the users of the component. - I add a few basic methods such as InsertText(x,y, substring); DeleteText,(x,y, len) ; BreakLine, JoinLine (maybe InsertNewLine, DeleteEntireLine) [*] In my CharGrid I use a single basic function for insertion and deletion, with the Len indicating insertion ( 0) or deletion ( 0). This delta can be used to adjust the text size, also with undo/redo operations. It might be necessary to distinguish clearly between display and text positions, where display positions take into account folded blocks, tab expansion etc., which only affect the display. While display coordinates may be separated into row and column, other positions (bookmarks...) better should be given as single text/file offsets. [Where IMO 32 bits are sufficient for *text* file size/positions - a dedicated data type will allow for eventual customization] - they can deal with undo and redo - In SynEdit all operations can be reduced to the above (and don't care about undo/redo) The undo/redo capabilities can be encapsulated in the text buffer object implementation, only the related methods have to be added to the TStrings interface. Since TrailingSpaces is already a wrapper around the TextBuffer, it can simply intercept those methods, and deal with them. Such a wrapper IMO disallows to change the trim option at runtime. I'd implement it only in the display code. The only flaw I still have with this is, that currently all the SynEditText* (wrappers around the actual textbuffer, doing, spaces, tabs, folding) are combining Display and Edit functionality. It would be nice to be able to write a TSynDisplay class first, and inherit the editor from it FACK [*] of course insertText could detect newlines, but it adds complexity. It will be simpler if SynEdit keeps control of this level, and InsertText, only operates on the current line As mentioned above, a single text offset value is sufficient for all text (buffer) operations. The text buffer must not necessarily be organized by lines, the object *only* has to map between line numbers and text positions for display references. Two such mapping functions are required, one for absolute lines in the entire text (in the text buffer object), and another one for virtual (folded) display row numbers (in the block folding object). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GPL'ed projects and closed-sourced tools
Graeme Geldenhuys schrieb: I got told in the CodeGear newsgroups that if you create a GPL'ed project, the tools used to create that project must also be GPL'ed otherwise somebody might require a commercial compiler to compile the GPL'ed project. AFAIR there exists a requirement (how strong?), that a user shall be able to build the project from the source code, so that everybody can trust his selfmade binaries, and is not bound to binaries supplied by third parties. For this reason all modified source code must be made available to the users. I have never heard anything like this before. As far as I understand, if a project is GPL'ed, it relates only to that project or projects based on the original project. It has nothing to do with what tools (compiler, editor, IDE, OS, etc) you used to create that source code. Is my assumption correct? ACK DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GPL'ed projects and closed-sourced tools
Marco van de Voort schrieb: AFAIR there exists a requirement (how strong?), that a user shall be able to build the project from the source code, so that everybody can trust his selfmade binaries, and is not bound to binaries supplied by third parties. For this reason all modified source code must be made available to the users. No. The GPL hits the person who is distributing binaries. If the user does the final link of open source code to binary proprietary code, and doesn't distribute the result, this is not a GPL violation. The GPL hits *every* distributor of GPL'ed material, be binary or in source code. The distributor has the duties, and the user has the rights, specified in such licenses (not only GPL). Interestingly modifications must be made available only to the users of that modified code, not to everybody. This leaves a grey zone in software contracts, where the provider can e.g. bind his client(s) by an NDA. While the user has the right to redistribute the modified GPL'ed source code, doing so will violate his contract with his immediate provider. [from d.s.r.m+u] Since FSF afaik considers dynlinking linking in the GPL sense, distributing a GPLed binary that links to a proprietary DLL that doesn't come with the OS is a violation in principle. This again is a result of the trusting principle, mentioned above. The use of closed source code is not allowed in (modified) GPL'ed projects. Otherwise everybody could turn any third-party closed source project into a GPL'ed (open source) project, by linking it to some GPL'ed material. The exclusion of OS modules was required for the same reason, since otherwise it were impossible to provide and use non-GPL'ed programs or libraries on a GPL'ed platform. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fw: New Features for source editor
Lee Jenkins schrieb: I like being able to type tobj and hit enter to end up with TObjectList and a space after it to continue typing. Just my personal preference. :) It's okay when I can tell the IDE when I want some assistance. It's not okay when the IDE *means* that it should become active, and I have to inspect and correct what it did to me and my code :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Component palette issues
Kostas Michalopoulos schrieb: Also the components need to be reorganizable. In other words you must be able to swap components around. The palette entry is determined by the component package(s), you'll have to rearrange everything after every rebuild of the IDE. It might help to have some alias definitions for palette entries, just like for units, which allow to replace given entry names by user specified ones. PS. Don't tell me Delphi does it this way or something similar. I'm using Lazarus not Delphi. RAD Studio has a new palette, that wastes even more screen space :-( But at least it allows to sort components e.g. by name, ignoring categories, and to select components by kind of auto completion. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fw: New Features for source editor
Alexander Klenin schrieb: -Autocompletion in real-time (no type Ctrl+Space) While I am not against adding this to Lazarus, ACK I would like to note that this is one Delphi 2007 feature I actively do not like, and always turn off. Most of the input features are helpful only to beginners, who never learned to type. People used to key-in with 10 fingers are only blocked by such features, and have to turn them all off. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fw: New Features for source editor
Reenen Laurie schrieb: I just think that 10 finger typists with these tools could be equal to a 15 finger typists... :-) What's the benefit of using 15 fingers, at the speed of one? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: At the moment the fpdoc editor is updated on idle in several steps. Maybe the update should be started after a short delay. Maybe. I'd suggest an thread, but I dunno about platform issues with threads. I also had an crash of lazde, caused by an formatting error in the text. Bugreport submitted. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gärtner schrieb: The problem is that many tools access the codetools (almost every file access and search). Then a request manager might help, with a busy indication so that a client can skip and retry later. A threaded server will allow for higher throughput on multi-core machines. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GUI frontend to a console application
Graeme Geldenhuys schrieb: I didn't mean writing a GUI in the console. I meant a true GUI app (LCL or fpGUI based), which uses a console application as the backend. What then is your technical problem? For example, Linux has many GUI frontends for programs like makeiso, burncd, cdrecord, cvs, mpg123 etc... These frontends most probably collect the options and then call the backends with the appropriate command line. Or they use the application libraries directly, without starting the console programs. In this case the command line argument evaluation has to be moved to the GUI frontend, which finally calls the same procedures as the main procedure of the console application does. For easy maintenance the console programs can be changed to use a shared library, which then can be used by every frontend. The shared libraries then should not do any console output, eventually output to stdout or stderr must be caught by the frontend, or the handles must be redirected/piped to the frontend. I never separated existing applications into shared libraries, so I don't know about the best solution for console output. When every output ends up in a few unique procedures, these procedures can be replaced by callback functions, provided by the frontend and installed during initialization of the shared library. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: What exactly is slow in fpdoc? I guess he meant the fpdoc editor in the IDE, not the fpdoc program. Right. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Marco van de Voort schrieb: Now I could spot the trouble source: it's fpdoc! Interesting, I'm just optimizing a part of that. http://bugs.freepascal.org/view.php?id=12953 What exactly is slow in fpdoc? IMO it's the search for documentation information about the current identifier in the edit window, started for almost every move of the caret. If that's the reason for the excessive slowdown of the editor, the search should be performed by a background thread, so that the editor is not blocked. The search should be terminated immediately, when the caret moves to an different identifier. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Mattias Gaertner schrieb: Now I could spot the trouble source: it's fpdoc! Why do you think so? When the fpdoc window is open, the task manager shows a CPU usage of up to 100%, and every caret move can take several seconds. You can check this behaviour yourself, my test case is the Controls unit with the related include files. When I close the fpdoc window, navigation through the text is not delayed, CPU usage stays at a few percents. Memory usage is constant in either case, swapping seems not to occur. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: The effect is boring, even if I only navigate through the source code with the cursor keys :-( This bit sounds like a problem with painting the window. Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. You remember my suggestion, to use an line-cache in the SynEdit component? Such a cache allows to bypass the block folding and other possibly time consuming actions, while only navigating through an file without editing. Which OS / Widgetset are you using? Windows 32 bit. My repaired machine just has arrived, I'll retry under Linux when I've reinstalled the system and Lazarus. You have not mentioned anything, so I just verify, it is nothing that has become worse since 0.9.26 (or within 2009) ? I've not really used Lazarus 0.9.26 or older, now I'm just following the SVN trunk. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: Moving the cursor should not require much repaint. And after startup it works fine, so that I suspect a problem with the information collected over time. yes and no: - vertical moves do repaint the gutter always, in case that the every nth line number is used. Okay, but it would be sufficient to repaint only the old and new line's numbers. - Any caret move that goes across a word boundary triggers the highlight-current-word (but it only set the timer, and only if you wait it does a search in the source), unless you checked disable timer (but this feature has only been added in 2009, hence my question) - If you hit a bracket, there is a quick search for the matching one. and if you are on a begin or end there is a search for the matching word (but if you are not on a begin or similar, this should not affect you). I think that I should disable all that eye-candy. I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Maybe, yes. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Waldenburg schrieb: - Memory management. SynEdit uses a TStrings attempt (IMHO a gaped-buffer would be more efficient). that's some kind of an urban legend. But anyway I could cry aloud looking at what mwEdit became. Nobody seems to know anymore how to write efficient code. Martin Hi Martin, you're still around? :-) You're right, the LCL became utterly bloated, without a good (discussed and documented) concept. But fortunately it doesn't contain assembler code :-) Efficiency is not normally required in a GUI, the current machines have enough power for themes, transparent windows, and more. But the behaviour of LazSynEdit actually feels a bit like the initial RAD-Studio editor, which also tended to slow down, until a freeze. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: I think the problem that is bigger than such a cache is mem management. SynEdit keeps allocating/deallocating a lot = that leads to fragments in the fpc mem-mgmt = and that could cause a slow down.. Now I could spot the trouble source: it's fpdoc! DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] some workarounds [Re: Debugger problems]
ik schrieb: I usually print to log/screen the output of things rather then working with a debugger. That's okay for command line programs. There are rare cases where I actually find the need to use a debugger, when you learn how to work with log files. In an event driven application a log file is of little use. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] speed of SynEdit [Re: Wiki pages suggestion - feature comparison]
Martin Friebe schrieb: I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows. Where exactly do you experience those speed issues? In editing Controls.pp and the related include files. If you use GTK1 or 2 you should use a font that is monospaces, and exists in this size for bold and italic too. (And you must not use ExtraCharSpacing). Otherwise there may be a slow down in painting. Yet this can not be compared to other Editors, unless they allow the usage of proportional fonts too, and they too force those into a grid. The effect is not related to any settings, after startup the editor works fast. It may depend on the number of applied changes or jumps across files or bookmarks, or on the number of symbols in the units, i.e. size of the according (history) lists. However there is one known problem in SynEdit. The highlighter (turn it off, and see if thinks get faster). Okay. I'll also try to close the fpdoc window, it may be related as well. The good part is, it does have potential to be improved. Also it should rarely matter. It only happens, if you enter a word that opens, or closes a new fold block (like begin) The effect is independent of keywords, perhaps it may be related to identifiers and the popup-hints. For me it is not noticeable on 1 Lines file like SynEdit.pp. I can notice it on a 300k Lines file, if I go all to the top, and type begin. There is a delay of a bit over a second, if I press the n. The rest of the typing is not slowed down. The effect is boring, even if I only navigate through the source code with the cursor keys :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Wiki pages suggestion - feature comparison
Graeme Geldenhuys schrieb: Hint: Lazarus also is a Delphi IDE clone. As far as I know (from prior conversations on this mailing list), it was never the intention or goal to clone the Delphi IDE. The only goal was to clone the VCL. Well, the look-and-feel has to be Delphi-like, so that newcomers don't have a too steep learning curve. I personally don't consider Lazarus IDE a clone of Delphi IDE. They might look similar from a distance, but when you start working with them, they are quite different. I prefer Lazarus IDE a lot more - mostly because I can modify it to suit my needs. I can not work efficiently with Lazarus, due to two problems with the editor (LazSynEdit): it can become dead slow, needing seconds of computation for a single key stroke, and it doesn't support multiple edit windows. This is why I want to contribute to these issues, starting with a working docking manager for multiple edit and explorer windows. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Wiki pages suggestion - feature comparison
Graeme Geldenhuys schrieb: Why are you constantly trying to convince Delphi people to switch to Lazarus, even in the Embarcadero Forums? I'm not telling them to dump Delphi. As I stated over and over - a bit of competition is great! In the newsgroup, I was simply stating that other developers could target a whole new market for there products. That's okay in so far, as FPC and Lazarus are designed as platform extenders for Delphi. It's important for the Pascal Language that CodeGear is selling products. Don't blame me for Borland and now CoadGear doing badly with Delphi. If they stopped kissing Microsoft's ass and concentrated on there own ideas, they would still have had a brilliant product. Trying to create a Visual Studio clone is not going to get them far - as they noticed!! The VS clone was an attempt to make people move from VS (and VB, VC...) to Delphi and Pascal. IMO Borland/Inprise/CodeGear better had provided a Visual Pascal plugin for VS. Borland has been the leading IDE provider for Windows long ago, but nowadays MS has the better IDE, supporting more languages. Hint: Lazarus also is a Delphi IDE clone. Consequently Lazarus should not try to replace Delphi, IMO. The primary goal of Lazarus should be a Delphi (OPL/VCL) compatible back-end, with a platform independent component library. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugger problems
Graeme Geldenhuys schrieb: Currently a debugger in Lazarus is barely usable. Yeah, that is one thing I seriously miss about Delphi and Kylix (thought not nearly enough to make me switch back). Is there no way we can hook (tie in) the Kylix or Delphi debugger into Lazarus? Which debugger for what platform? IMO the integration of the GNU/FPC debugger is the only way to cover all platforms at once. I cannot sort out what's FreePascal and what's Lazarus specific with debugger problems. But I wonder about random popups from the debugger at start of my applications - it looks like uninitialized variables to me, somewhere in the LCL/RTL? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugger problems
Marc Weustink schrieb: tooltip on identifiers don't work, Always, unless used on properties. In that case I use the Evaluation dialog to inspect the membervar. Sorry, Graeme is right :-( In most cases I cannot inspect local variables, due to no such symbol in context errors, even with fully disabled optimizations. Is this a platform issue? (I'm primarily using Windows) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Problem using the SVN program: source files mutilated
Bart schrieb: So I should now do svn revert this will undo all changes I made. and after that svn update and I get my own patch back in the proper way? Or you fix the marked conflicts in the source code. This is what the markers are good for - prevent compilation of code, where SVN merge couldn't find a unique solution. On Windows you can use TortoiseSVN, with many GUI and explorer extensions, to locate, compare and fix conflicts. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] StringGrid.Options: goSmoothScroll vs goThumbTracking
Graeme Geldenhuys schrieb: goSmoothScrolling - scrolls pixels at a time, not columns/rows. goThumbTracking - gives you a like preview of the contents as you move the scrollbar. Right. I would think the more logical default would be to have both there options enabled by default. I'm using 0.9.26 and they are not both enabled by default. AFAIR that's the Delphi default, suitable for slow systems. Thumb tracking was available for the original Windows controls. Smooth scrolling came later, when the typical systems had more processing power. Smooth scrolling IMO should be disregarded when the scroll distance becomes larger than one page, or when it's known that the user dragged the slider. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi5 - Lazarus issues
Aleksa Todorovic schrieb: c) static array inside the function as a const (with Writable consts turned on) I'd *not* suggest to make *all* constants writeable, for only saving a few keystrokes in source code. Doesn't FPC support kind of static variables in subroutines? (Delphi doesn't, but it would be a nice extension of the language...) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi5 - Lazarus issues
jokraut...@bluemail.ch schrieb: 1. After finalisation of For I:=B To E Do... in Delphi is I=E+1, in Lazarus it is I=E. (I remember, that using a For loop counter after finalisation is not recommended, but...) The for loop counter is undefined after exit from the loop. Depending on optimizations, it may be near the begin or end value, or the variable is unchanged. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Zipfiles using Paszlib...
Felipe Monteiro de Carvalho schrieb: I'm confused. Does TZipper produce pkZIP compatible files or is it zlib based and only called TZipper? I don't understand your question. The files produced work correctly if given the .zip extension. They are recognized by the internal unzipper of OpenOffice.org You assume that OO only looks at the file extension, not at the actual file contents? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus SVN on linux and virtual box WinXP
Reenen Laurie schrieb: A while ago I installed Virtual box and WinXP. I want to know if it's possible for me to keep my Virtual box's Lazarus updated from the SVN updates I do via linux? You can update your working copies from the same repository, but you have to do it separately, for every single copy. I don't know about Virtual box, perhaps you can share one working copy between the host and guest system? VMware at least supports shared folders, this is what I'm using. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gaertner schrieb: There is no question, that such a big change is Delphi incompatible. Not at all. Do you mean: a) There no question at all that it will be Delphi incompatible b) It will not at all be Delphi incompatible, because TWinControl will not change ? Sorry for my bad Denglish :-( [a] The intended changes will not break Delphi compatibility. Maybe you can give more details how the gt protected props/methods of TWinControl should change? gt? Some of the suggested changes are mentioned in my recent bug report and patch, concerning the handling of docking. I'd appreciate if that patch would be applied soon, so that I have that list of ToDo items for my further work on this topic. Unfortunately my physical and virtual machines still suffer from hardware problems, so that I don't have at hand the tracker ID of that patch :-( The layout related changes are only an idea at the moment, inspired by the intended implemenation and integration of e.g. a MiG layout manager. I have no concrete idea yet, about a usable general interface between controls and an separated layout manager. When I'm done with the docking changes, I can e.g. introduce a dummy TContainerControl=TWinControl class, and change all affected TWinControl references accordingly. Then we could identify the places, where the layout related changes changes would have an impact on existing code. I have a couple of questions myself, about e.g. the many different control sizes in TControl (BaseRect...), and other layout related properties. Try to imagine the many new control properties, required for the implementation of the MiG layout manager. IMO it's impractical to add all these parameters explicitly to TControl, over and over again for every new layout (or docking) manager. Instead I'd introduce a somewhat unspecific property TControl.LayoutData, refering to a layout manager specific data object. The TDockZone data structure of the TDockTree manager already is kind of such a data structure, which could be attached to every TControl, so that FUndockedWidth etc. members could be moved into that data structure. Consequently the primary question should be, whether we are *willing* to allow for different layout managers at all. If yes, we'll *have* to design an according interface between controls and layout managers, and we'll *have* to update the control classes accordingly. The questions about Delphi and legacy compatibility only can be answered *after* the implementation of the new interface. When we *then* find layout managers absolutely incompatible with Delphi and legacy code, we have several options. My preferred option is a splitted LCL, similar to the VCL/CLX fork in Delphi, but in a better manageable way. I'd do that by conditional compilation of the LCL, steered by a project wide option. This would allow to have: - a slim LCL version, almost a clone of the VCL, - a compatible version, including support for anchored controls, and - a extensible version, with support for layout managers and more. Only the extensible version might be not 100% compatible with Delphi and legacy code. It might become slim as well, by binding it to dedicated widgetsets (Win32, Qt...), if the users want such an option, or it might become fat when everything is done in the library, as IIRC is the approach of fpGUI. A slim version IMO would be nice for embedded devices, where available RAM (currently) imposes some limits. I understand the value of Delphi compatibility, but I cannot accept that such compatibility should block forever the evolution of new features. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Zipfiles using Paszlib...
Graeme Geldenhuys schrieb: Later in the year I want to extend TZipFile with compression (if it doesn't already have) and use it as our custom help file format for our company applications. I've already been working on a general compression/archive interface, based on the Abbrevia approach. Unfortunately Abbrevia at that time already had become so buggy, that I designed a better interface for the integration of compression modules of any kind. It proved to be usable with most archives, like rpm/cpio, tar/gz and zip. Finally I stopped working on porting more modules to Pascal, when I found that 7zip already has implemented such an interface, and also has solved the integration of existing compressors. I like the idea of integrating existing code for the worker objects, so that the evolution of existing and new modules (almost in C code) is decoupled from the interface itself. I only don't like the 7zip implementation in C++, because it is not portable. My approach consists of both Delphi classes, encapsulating the various kinds of archives, as well as a generalized component for the visual interface. The single-component model was inspired by database components, which also can be connected to various kinds of databases. The interface effectively consists of an set of fixed attributes and methods, common to all archivers, and archive-specific attributes and features, accessible as name/value string pairs. I'm willing to resume my work on this approach, if somebody familiar with C can implement the low level stuff (calls to the worker C code). DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gärtner schrieb: Maybe I misunderstood your proposal. What parts of TWinControl should be moved to TContainerControl? Do you want to move the ControlCount and Controls properties to TContainerControl? Yes, all the child control related stuff. I'd move that into the LayoutManager, and redirect all related methods and properties to that helper object. Then the LayoutManager is as exchangable as the DockManager. What about TControl.Parent? It will be of type TContainerControl, of course. I admit that the tests for TWinControl have to be revised accordingly, but there remains more to do. E.g. it's nonsense when TWinControl redirects docking and other messages to TControl, which then again delegates the job back to its own TWinControl parent. All that docking and child control handling stuff should be entirely removed from TControl, and also from TWinControl, and instead should be moved into the layout and docking helper objects. I'm just about to find all that stuff, and to implement a direct connection between e.g. TDragManager, TDockPerformer, and the DockManager. The legacy interface of all classes can survive that update, the revised methods only will redirect the tasks immediately to the final worker object. These are highly desireable changes, regardless of whether we introduce a new layout layer class or not. We might use conditional compilation, so that in case of trouble the old class tree remains intact, for debugging and as a last resort in case of trouble with legacy code. IMO we should cut some of the old trees, in order to see the wood for trees again. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gärtner schrieb: At least 90% of TWinControl is about its child controls. The rest is mostly key, mouse and focus handling. I guestimate, TContainerControl will have about 1-3kloc code, 500loc will stay in TWinControl and the remaining 4-6kloc will go to the new docking/layout classes. There is no question, that such a big change is Delphi incompatible. Not at all. The question is how much: - A lot of code (outside the LCL) relies on the fact, that AControl.Parent is a TWinControl and has a handle (exact: can have a handle). When a GUI is made of traditional components, then the parents will be TWinControls, of course. A form will continue to inherit from TWinControl... DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gaertner schrieb: I'd suggest a layout layer, between TControl and TWinControl, dealing with child controls (e.g. TContainerControl). As Paul pointed out, a TWinControl uses system resources (handles), which are not required for layout (and docking) managers. TWinControl has childs, TControl has not. This is usually tested with if AControl is TWinControl then If a TContainerControl that is not a TWinControl has childs this test will break. It only won't work if the old checks are used together with the new controls. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Space preference for assignment
Micha Nelissen schrieb: How can I specify I prefer spaces around assignment operators? In the options window I can select several tokens, but not assignment operator, or did I miss it? You can selecet symbols, including the assignment operator. Unfortunately a couple of other tokens (punctuators, parentheses...) are also classified as symbols. I suggest to separate true operators from other symbol tokens, and to add an according option. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Interact with M$ Word
Bart schrieb: Currently I'm working on an app that needs to interact with M$ Word. The intended users are computer noobs, so I expect no knowledge from them whatsoever. Problem. My app calculates/compose tabular data (in the order of 6 cols x 50 rows). These data have to be inserted into a word document as a word table. (Most users will not be able to convert text with tabs to a table in Word, no matter how often explained). Two different approaches come to mind. First approach: Paste the data (all strings) onto the clipboard in Word Table format. (I can get the users to paste this in their document...) Does anyone have a clue as to how to achieve this? Better stay away from creating data structures for external applications - this approach most probably will fail with the next Word version :-( Even if you intend to bind your customers to updates of your program, you'll have to determine the installed Word version at runtime, and provide the code for *every* supported version. Second approach: Use MS Office automation. Create new document from template (how do I know where user's templates (*.dot files) are?). Go to right place in document. Create table Insert data into table. There is a basic wiki document on how to open a word doc in Word with automation, but I never used office automation at all, so all steps I have no clue as to how to achieve them. Ask in a MS Office/Word group. Your problem is not Lazarus or Pascal related, it's a matter of the VBA for Word programming language and libraries. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ptInRect question
Michael Van Canneyt schrieb: Is there a reason why the top/left sides are included (=), and the left/bottom sides are not included ? I would expect them to be included as well. There exist reasons, mostly the definition in the WinAPI. Dunno how to explain the most important reason, but let me try it: Take an arbitrary scale, e.g. for temparatures or dates, and try to map coordinates into differences. Easy? Not really, when you have to work with integral numbers. Do you want to paint points (pixels) *at* given coordinates (tick marks for the scale), or lines (distances) *between* two coordinates? Then you see that you can't do both at once, for a distance of 1 unit (painting: 1 pixel) :-( On a 2D canvas a grid for cells of size=1 (pixel) either would fill the entire area or, when you fill the cells with pixels, there's no room left for grid lines. As a practical compromise a canvas is painted in pixels, i.e. rectangles of size=1, so that a rectangle from (0,0) to (1,1) has a *size* of 1 pixel, and that single pixel is *located* at the coordinates (0,0). Now you see that the end coordinates of a rectangle are *not* part of the area of the rectangle. One should understand that the transformation of rectangles, between origin/extent (XY)-(WH) and TopLeft/BottomRight (TL)-(BR) representation, includes an imaginary shift of half a pixel. I really would appreciate different data types for both representations, instead of the unique TRect record - then it were obvious, that PtInRect works with the (TL)-(BR) representation, and consequently has to exclude the bottom and right values from the area of the rectangle. The same considerations apply to lines, as mentioned above. When the pen is moved to (x0,y0) on a canvas, and then consecutive lines are drawn to (x1,y1) and (x2,y2), the point (x1,y1) is excluded from the first line, and (x2,y2) is excluded from the second line. Nonetheless the pen is *located* at (x2,y2) afterwards. This way one can paint a rectangular border, with a PolyLine(T,L, T,R, B,R, B,L, T,L), without repainting the edges of the rectangle. When the lines are painted in different colors, the end points are painted in the color of the *next* line. Imagine how complicated were the calculation of the real (not excluded) end points of a series of lines, when arbitrary world-coordinates are used, expressed in something different from integral pixel coordinates. HTH DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fsStayOnTop under windows
Benito van der Zander schrieb: Probably the best solution is to create two flags fsStayOnTop(Application) and fsStayOnTopGlobally. The first should be a property of Application, not of the forms, so that only one form can be the topmost one. The second one depends on the capabilities of the OS and widgetset. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fsStayOnTop under windows
JoshyFun schrieb: HV so what happens if the other application wants to be on top of yours? In Windows at least, topmost windows are implemented as a second windows layer, one for normal windows and other for topmost ones. Which Windows version(s)? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Splitter in action
I want to resize a control by using an splitter. As a test case, have a form with Button1 and Splitter1. In the FormCreate event I set Splitter1.AnchorSplitter(akLeft, Button1); Now the splitter is anchored to the right of the button, and a sizing cursor appears when the splitter is dragged. But the button is not affected at all. What's missing? BTW, the splitter's ResizeStyle seems to have no effect? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TFileStream
Dave Coventry schrieb: FS:=TFileStream.Create(fname, fmshareDenyWrite); IMO you should also specify the requested access (fmCreate or fmOpen...), even if zero happens to mean fmOpenRead. Nonetheless it looks strange when the same file cannot be reopened later. Are you sure that fname is unchanged the second time? Why don't you keep the stream open, and move the try/finally to the end of the subroutine? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Open Source Diagram Components for Lazarus?
Mattias Gaertner schrieb: I'm looking for a diagramming components for Lazarus, to draw circles, rectangles, and connectors between them that are resized or moved when the components are moved. This would be used to create graph editors, for example for designing dynamic models. Do you have ideas about a mature component I could use for this purpose? I've been thinking about using GLScene as a 2D layer, but it seems to be overkill for my purpose (although 3D diagrams... hum.) I'm interested in that too. I've got SmartDraw http://www.smartdraw.com for drawing such diagrams, years ago. But I'm not sure about programmatical access to the drawings. Should we start a new project? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Colors and Themes
When I wanted to add dock headers to the docking manager, I stumbled across several problems with colors. For Windows e.g. clActiveCaption or clBtnFace can be used for the header and button background, but these color constants are marked deprecated. How should I select the most appropriate colors, for different platforms and themes? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking manager implementation
Graeme Geldenhuys schrieb: Here is a direct link to the .jar file. http://www.miglayout.com/swingdemoapp.jar Thanks, this one worked off the shelf :-) DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking manager implementation
Michael Van Canneyt schrieb: The same things you see there can be easily done in Lazarus ? Maybe somehow, dunno how easily ;-) Whether I write - rather obscure - layouting code for the start as displayed there, or I write a 'OnResize' event handler and do some minor adjustments myself (the improved anchoring of lazarus gets you a long way), the fact remains that I must take care of the layouting by writing code manually ? Most widgetsets have no concept of persistence, so everything must be set up in code. If you had a nice property editor, maybe then it would be better. Even so, creating a usable property editor for such a complicated matter is not going to be easy, I think. You address an sensitive topic. Now I realize what I don't like with the Lazarus anchor editor - it lacks a visualization of the designed dependencies, for a quick design, overview and verification of the overall layout. It violates my primary design rule: keep it simple! Of course people have very different meanings about useful layout managers, in so far the most powerful layout manager may address the needs of everybody, even if every single developer only uses his favorite subset of the offered features. Nonetheless I fear that the outcome will be write only, with little chances that somebody will be able to update any existing complex layout, perhaps except for it's inventor :-( I for my part would prefer a strictly structured (layered, nested) layout, where frames can be used to visualize the nesting in design mode. Just as is demonstrated in the last item of the MiG layout manager. When structured code is the accepted best coding style nowadays, because it's clear, understandable, extensible, and can be verified easily - why should spaghetti style be better suited for the design of a GUI? BTW, the layout demo doesn't include any graphics. I wonder what will be required to include graphics, in a way that produces a predictable look and behaviour in environments with different screen resolutions and text sizes. It's hard enough, with only text, to test a layout on such different environments, so that it's not acceptable to me when a GUI looks fine at the designer's site only, with an unknown appearance on other machines. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking manager implementation
Reenen Laurie schrieb: For me, all I really want that's not supported via Lazarus at the moment is the % of parent statement... Are you talking about the form designer or docking manager? A percentage based scaling is unsafe, because the sum may exceed 100%. It also will be hard to add any new element, requiring a recalculation of the previous percentages. What about the required adjustment of percentages in other rows or columns of the same layout? Also required is kind of an alClient value, for an element that should fill the remaining space. That's why I'd favor a proportional scaling, as used in the dock site resize procedure. When the undocked sizes are used for scaling, nothing new has to be added to the existing design tools and data structures. It might be possible to take into account the control alignment (including alClient, see above), but this may require a distinct DockAlign property with every control. For general layout managers it may be necessary to add a reference size for proportional scaling, dunno whether this is related to the newer Delphi ExplicitWidth etc. properties. It may be possible to mix absolute and relative sizes, when relative sizes are given as negative values. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking manager implementation
Reenen Laurie schrieb: I am liking what you're doing with the dock manager by the way. It looks exciting. Thanks for the feedback :-) proportional scaling - could you point me to examples etc? The docking manager example demonstrates this. When you set the alignment of the dock site to alClient, it will follow all resizes of the form. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking manager implementation
Graeme Geldenhuys schrieb: Looks as I'm too stupid to make the demo work :-( I'm not experienced with installing Java... I have the Java SE Runtime Environment (build 1.6.0_03-b05) installed. Using Ubuntu Linux, I installed it via apt-get. I've had build 1.5.0_17-b04 first, now 1.6.0_11-b03, but this makes no difference (execpt for a longer error log). I then downloaded the swingdemoapp.jar file and ran it via the command line. I got a swingdemoapp.jnlp, and a swtdemoappbase.jar. The .jnlp is a invalid or corrup jarfile, the .jar throws an exception NoClassDefFoundError :-( DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
