Re: [lazarus] several patches
On Sun, 8 Jan 2006 23:50:22 +0100 (CET) [EMAIL PROTECTED] wrote: scalecompsdlg - converted to LFM Thanks. Applied. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] several patches
On Sun, 8 Jan 2006 23:50:22 +0100 (CET) [EMAIL PROTECTED] wrote: EnvironmentOpts: - fixed anchoring Applied. Thanks. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
Micha Nelissen wrote: Marc Weustink wrote: The reason I thought of it is the continuos trouble I have with for instance grid.columns or statusbar.panels You only can access them by index. Having them as classfields makes life easier. Like a dataset, those items doesn't have to be persistent by default. We can for instance introduce a property PersistentItems: Boolean default False; This is IDE functionality, not LCL functionality, right ? The creation of the persistent fields... yes The asignment of the fields to items, it has to be something outside the ide. Don't know how dataset fiels are written/read. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
Mattias Gaertner wrote: On Fri, 30 Sep 2005 10:20:31 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Thu, 29 Sep 2005 23:46:14 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: [...] Spacing like http://www.dommelstein.nl/scrap/checkbox_spacing.png If you would like to get the checks at a grid distance, you have to tweak the heigth of the box. Exactly. Do you want a TCheckGroup without auto fill? Yes, or maybe better, with autosize. Some widgetsets have (strict) guides on what distance all elements should have to eachother. With autofilling this is almost impossible. See for instance http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_3.html#//apple_ref/doc/uid/TP3359-TPXREF195 http://msdn.microsoft.com/library/en-us/dnwue/html/ch14e.asp?frame=true We could add an AutoFill property and set default to false. If AutoFill=false the ChildSpacing properties will define the space between the child controls. Would that be sufficient? I think it would. (or have a child spacing -1 ?) Combined with a AutoSize, where the box will perfectly fit around the cheks, would make it complete (I think) Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
[EMAIL PROTECTED] wrote: Here are two patches, which were lying around some time. checkgroup: - added property CheckByName: check box can be changed by only knowing the name (no need to search the index) - added property CheckEnabledByName: check box can be enabled by only knowing the name (no need to search the index) What would be the use of a index by Caption ? (At least I think you mean Caption, since the internal checkboxes don't have a name) And what about internationalizations ? In general I don't see a need for this. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
What would be the use of a index by Caption ? (At least I think you mean Caption, since the internal checkboxes don't have a name) That is one of the problems, see the next code to clarify the use; if EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight] then PreviewEdits[a].Highlighter := PreviewSyn else PreviewEdits[a].Highlighter := Nil; It's full of thes constructs in the code. Now I could first get the index by code and then check the checked poperty by code, but that would require some 40odd more lines and variable declarations. A bunch of redundant code if you ask me, and it obfuscates the true meaning of it. I could ofcourse make a function in the unit that wraps that, but that's what I did in the inc file. And the inc file seems a more appropriate location. And what about internationalizations ? Use the resource string ofcourse as index (see example). But I agree, perhaps I should have called it CheckedByCaption instead. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
[EMAIL PROTECTED] wrote: What would be the use of a index by Caption ? (At least I think you mean Caption, since the internal checkboxes don't have a name) That is one of the problems, see the next code to clarify the use; if EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight] then PreviewEdits[a].Highlighter := PreviewSyn else PreviewEdits[a].Highlighter := Nil; It's full of thes constructs in the code. Now I could first get the index by code and then check the checked poperty by code, but that would require some 40odd more lines and variable declarations. A bunch of redundant code if you ask me, and it obfuscates the true meaning of it. Thats why you usually create a func/proc for it. I could ofcourse make a function in the unit that wraps that, but that's what I did in the inc file. And the inc file seems a more appropriate location. IMO it can be perfecly added as local form method and no need to add it in an inc. But back to the basic question, what is the need: Why index by name ? Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
On Thu, 2005-09-29 at 14:56, Marc Weustink wrote: Thats why you usually create a func/proc for it. IMO it can be perfecly added as local form method and no need to add it in an inc. I myself are not in favor of repeatedly occurring functions or procedures in a project (or several projects), that extend functionality of classes. I believe that the power of OOP is that you can inherit this functionality from more basic classes. But back to the basic question, what is the need: Why index by name ? CheckBoxGroup's like RadioGroup's show their components based on a number of items, that come from a resource (trough IDE) or from code. An application that has internationalization typically will add the items from code, namely add all resource strings of the items. So how can you tell if a checkbox is set or not?? Well IMHO you can only do that by checking the position of the items in the stringlist and then check the checked property on that position. Now, like you say, I could add a method to the form and extend the forms functionality, but I believe that it has nothing to do with the form. It's in fact extending the functionality of the groupbox. By definition the resource strings used in the list are know to the code, so searching by name is improving readability and making the code more robust. EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight] will always be more clear than EditorOptionsGroupBox.CheckedByName[13] and inserting an item in the groupbox will not require to renumber all other checkboxes. I could be wrong, but that's just the way I see it... Darius _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
On Thu, 29 Sep 2005 20:40:42 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Darius Blaszijk wrote: [...] But back to the basic question, what is the need: Why index by name ? CheckBoxGroup's like RadioGroup's show their components based on a number of items, that come from a resource (trough IDE) or from code. An application that has internationalization typically will add the items from code, namely add all resource strings of the items. So how can you tell if a checkbox is set or not?? Well IMHO you can only do that by checking the position of the items in the stringlist and then check the checked property on that position. Not by name. If you choose to use a checkboxgroup, then you have decided to use it based on indexes. That in your case it contains translated strings, doesn't matter. It is no a reason to add this functionality. If you don't have a fixed number of items, and you want to access the individual items by function, then your decision to use a checkboxgroup is wrong. You can have exactly the functionality that you want with a GroupBox and individual checkboxes (which is mostly better since you can use fixed horizontal spacing). What spacing do you mean? [...] so searching by name is improving readability and making the code more robust. And slows it also down. True. But hardly noticable. TCheckGroup has seldom more than 20 items. EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight] will always be more clear than EditorOptionsGroupBox.CheckedByName[13] EditorOptionsGroupBox.Checked[USES_SYNTAX_HIGHLIGH] is also perfectly clear. But requires some new constants. and inserting an item in the groupbox will not require to renumber all other checkboxes. That is the disadvantage of using a checkboxgroup. .. because it's missing the above function. But that counts for all controls where items are accessed through an index. Which brings me to the following. Why not for other controls like: RadioGroup - ItemIndex ListBox - Selected item CHeckedListBox - Selected/Checked item Listview - Selected/checked item Treeview - selected node Toolbar - button Grid.Captions - caption . . etc Hmmm... now thinking on it if you compare this to datasets, on a dataset you can make its items (=fields) persistent. WOuldn't that be an idea to add that to (some) of the controls I mentioned above ? I think, such functions are slow, but often needed anyway. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
Mattias Gaertner wrote: On Thu, 29 Sep 2005 20:40:42 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Darius Blaszijk wrote: [...] But back to the basic question, what is the need: Why index by name ? CheckBoxGroup's like RadioGroup's show their components based on a number of items, that come from a resource (trough IDE) or from code. An application that has internationalization typically will add the items from code, namely add all resource strings of the items. So how can you tell if a checkbox is set or not?? Well IMHO you can only do that by checking the position of the items in the stringlist and then check the checked property on that position. Not by name. If you choose to use a checkboxgroup, then you have decided to use it based on indexes. That in your case it contains translated strings, doesn't matter. It is no a reason to add this functionality. If you don't have a fixed number of items, and you want to access the individual items by function, then your decision to use a checkboxgroup is wrong. You can have exactly the functionality that you want with a GroupBox and individual checkboxes (which is mostly better since you can use fixed horizontal spacing). What spacing do you mean? Spacing like http://www.dommelstein.nl/scrap/checkbox_spacing.png If you would like to get the checks at a grid distance, you have to tweak the heigth of the box. [...] so searching by name is improving readability and making the code more robust. And slows it also down. True. But hardly noticable. TCheckGroup has seldom more than 20 items. EditorOptionsGroupBox.CheckedByName[dlgUseSyntaxHighlight] will always be more clear than EditorOptionsGroupBox.CheckedByName[13] EditorOptionsGroupBox.Checked[USES_SYNTAX_HIGHLIGH] is also perfectly clear. But requires some new constants. Indeed, but the statement was about readability. and inserting an item in the groupbox will not require to renumber all other checkboxes. That is the disadvantage of using a checkboxgroup. .. because it's missing the above function. Indeed. What I argue is not about that function anymore, but what functions to add and when. Are we going to add some random utility funtion to some random controls ? That is my point. Another useful property would be the ability to enable/disable a checkbox. Or to put it in a unknown/treestate. While continuing to compare it to a dataset, maybe for this kind of compound controls, something like TCheckboxGroup.Checkbox[AIndex] or (indeed) TCheckboxGroup.CheckboxByCaption would be handy. But that counts for all controls where items are accessed through an index. Which brings me to the following. Why not for other controls like: RadioGroup - ItemIndex ListBox - Selected item CHeckedListBox - Selected/Checked item Listview - Selected/checked item Treeview - selected node Toolbar - button Grid.Captions - caption . . etc Hmmm... now thinking on it if you compare this to datasets, on a dataset you can make its items (=fields) persistent. WOuldn't that be an idea to add that to (some) of the controls I mentioned above ? I think, such functions are slow, but often needed anyway. The reason I thought of it is the continuos trouble I have with for instance grid.columns or statusbar.panels You only can access them by index. Having them as classfields makes life easier. Like a dataset, those items doesn't have to be persistent by default. We can for instance introduce a property PersistentItems: Boolean default False; Then it wont affect default behaviour, but only if the developer realy wants them tor that specific control. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
On Thu, 29 Sep 2005 23:46:14 +0200 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: [...] Spacing like http://www.dommelstein.nl/scrap/checkbox_spacing.png If you would like to get the checks at a grid distance, you have to tweak the heigth of the box. Exactly. Do you want a TCheckGroup without auto fill? [...] and inserting an item in the groupbox will not require to renumber all other checkboxes. That is the disadvantage of using a checkboxgroup. .. because it's missing the above function. Indeed. What I argue is not about that function anymore, but what functions to add and when. Are we going to add some random utility funtion to some random controls ? That is my point. Another useful property would be the ability to enable/disable a checkbox. Or to put it in a unknown/treestate. While continuing to compare it to a dataset, maybe for this kind of compound controls, something like TCheckboxGroup.Checkbox[AIndex] or (indeed) TCheckboxGroup.CheckboxByCaption would be handy. Indeed. But that counts for all controls where items are accessed through an index. Which brings me to the following. Why not for other controls like: RadioGroup - ItemIndex ListBox - Selected item CHeckedListBox - Selected/Checked item Listview - Selected/checked item Treeview - selected node Toolbar - button Grid.Captions - caption . . etc Hmmm... now thinking on it if you compare this to datasets, on a dataset you can make its items (=fields) persistent. WOuldn't that be an idea to add that to (some) of the controls I mentioned above ? I think, such functions are slow, but often needed anyway. The reason I thought of it is the continuos trouble I have with for instance grid.columns or statusbar.panels You only can access them by index. Having them as classfields makes life easier. Like a dataset, those items doesn't have to be persistent by default. We can for instance introduce a property PersistentItems: Boolean default False; Then it wont affect default behaviour, but only if the developer realy wants them tor that specific control. Sounds great. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Several patches
- Original Message - From: [EMAIL PROTECTED] To: lazarus@miraclec.com Sent: Friday, September 23, 2005 1:43 PM Subject: [lazarus] Several patches Here are two patches, which were lying around some time. grids: - code cleanup for goFixedRowNumbering - added goHideCells: if set the grid is blank. Usefull when no data is to be shown. snip Darius Lazarus grids have the clear method which does just that, the only thing is that one have to reconstruct the grid, and setting ColCount:=0 or RowCount:=0 has the same effect. Also, currently grids can have ColCount=FixedCols or RowCount=FixedRows, which should look like a empty grid but with Cols or Rows headers. Jesus Reyes A. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
