Re: [lazarus] I have a dream
En/na Marc Weustink ha escrit: For scrolling after a line is added, I don't know. Personally I hate it when a memo gets updated and I want to read the contents the same time. Well, there could be a property that controls this behavior. Or scroll to the bottom only if the last line is visible (assuming that if it isn't visible you've manually scrolled to read old messages). That's what, e.g., kconsole does, and I manually replicated it with a TSynMemo (I'm not sure it'll work with a plain TMemo), something like: function TMyForm.AtBottom:boolean; begin Result:=SMemo.TopLineSmemo.Lines.Count-Smemo.LinesInWindow; end; procedure TMyForm.ScrollToBottom; begin SMemo.TopLine:=SMemo.Lines.Count-SMemo.LinesInWindow+1; end; procedure TMyForm.test; var autolast:boolean; i:integer; begin autolast:=AtBottom; SMemo.lines.beginupdate; for i:=1 to 10 do SMemo.lines.append(IntToStr(i)); SMemo.lines.endupdate; if autolast then ScrollToBottom; end; Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007 _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Luca Olivetti ha scritto: En/na Marc Weustink ha escrit: For scrolling after a line is added, I don't know. Personally I hate it when a memo gets updated and I want to read the contents the same time. Well, there could be a property that controls this behavior. That would be cool. If you must read all the text memo, having it scrolling is a big nuisance. If text memo are individual lines, and the last one is then most relevant, then manually scrolling goes from a nuisance to an impossibility. If you need both, you may add a button to set the property according the need of the moment. If the widget has the property, you save extra coding. IMHO when you have visual components, you should have in code what the program wants to do, in the component properties how to show it, without need of extra code. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
On 29/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote:
So my question is still open. There's a way to make the IDE/compiler
aware of the change of conditionals? I'm the only one with this requirement?
I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
used to use application wide defines passing in -dwhatever. This
caused lots of problems, like you described. I now instead use defines
per unit. Below the compiler mode (top of unit) I place a new line
{$Define DEBUG} to enable debuging per unit. If I want to disable such
debugging, comment that line as follows: {.$Define DEBUG}
Obviously this works for me, because that's the only IFDEF's I have in
fpGUI. Others usage may vary. My 2c worth.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Graeme Geldenhuys schreef: On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Don't assume, research. Not convinced, Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Isn't it lot easier to create an include file with all the defines,
and include it everywhere you need it? If you need several sets of
defines, just create higher level symbols that enable/disable those
sets.
Regards!
-Marco
2008/1/30, Graeme Geldenhuys [EMAIL PROTECTED]:
On 29/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote:
So my question is still open. There's a way to make the IDE/compiler
aware of the change of conditionals? I'm the only one with this requirement?
I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
used to use application wide defines passing in -dwhatever. This
caused lots of problems, like you described. I now instead use defines
per unit. Below the compiler mode (top of unit) I place a new line
{$Define DEBUG} to enable debuging per unit. If I want to disable such
debugging, comment that line as follows: {.$Define DEBUG}
Obviously this works for me, because that's the only IFDEF's I have in
fpGUI. Others usage may vary. My 2c worth.
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Graeme Geldenhuys ha scritto:
On 29/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote:
So my question is still open. There's a way to make the IDE/compiler
aware of the change of conditionals? I'm the only one with this requirement?
I have also noticed that issue, mostly with my IFDEF DEBUG lines. I
used to use application wide defines passing in -dwhatever. This
caused lots of problems, like you described. I now instead use defines
per unit. Below the compiler mode (top of unit) I place a new line
{$Define DEBUG} to enable debuging per unit. If I want to disable such
debugging, comment that line as follows: {.$Define DEBUG}
Obviously this works for me, because that's the only IFDEF's I have in
fpGUI. Others usage may vary. My 2c worth.
Unluckily my mileage varies a lot. We have a codebase which is used to
build different applications. Roughly 30 to 35 units and tens of
thousands of lines.
When an application is reasonably different from others, it gets its own
directory and all customization is made there.
But when some applications are very similar, and maybe go to the same
customer, we may have two or three projects on the same directory, which
are using the same source files, and a few conditionals scattered around
to pick up the proper options where appropriate.
If one has last built project1, and then does some editing and just
compiles (instead of building) project2, project2 may inherit units
which where compiled with project1 conditionals, generating a mix-up,
which may go undetected.
That's why I was looking for a way to avoid this problem.
Thanks, however,
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
On 30/01/2008, Marco Alvarado [EMAIL PROTECTED] wrote: Isn't it lot easier to create an include file with all the defines, and include it everywhere you need it? If you need several sets of defines, just create higher level symbols that enable/disable those sets. Thanks Marco. We have done exactly that in the tiOPF project. So far it wasn't needed for fpGUI because I normally want to debug a certain unit. One at a time, otherwise I get flooded with debug information. Maybe I should incorporate the tiLog and tiGUILog unit from tiOPF into fpGUI. In the tiGUILog unit you can enable/disable debug information at runtime. Very handy!! The GUI log window get fed from a separate log thread which uses caching and a lower priority so as not to slow done the running of your application. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
On 30/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: If one has last built project1, and then does some editing and just compiles (instead of building) project2, project2 may inherit units which where compiled with project1 conditionals, generating a mix-up, which may go undetected. That's why I was looking for a way to avoid this problem. OK, I understand your issue now. Simple solution is: Always do a Build All. :-) Create a keyboard shortcut for Build All, or use Ctrl+F9 for Build All instead of the default compiler (I use Build = Ctrl+F9 and Build All = Shift+Ctrl+F9). Alternatively, install the Editor Toolbar package, add all the different build and compile functions to the toolbar. Now everything is one click away! Quick and easy solution... :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Graeme Geldenhuys ha scritto: On 30/01/2008, Giuliano Colla [EMAIL PROTECTED] wrote: If one has last built project1, and then does some editing and just compiles (instead of building) project2, project2 may inherit units which where compiled with project1 conditionals, generating a mix-up, which may go undetected. That's why I was looking for a way to avoid this problem. OK, I understand your issue now. Simple solution is: Always do a Build All. :-) By what means do you suggest to obtain that from everybody: moral suasion, menaces, salary cut, spanking or other corporal punishment? :-) Create a keyboard shortcut for Build All, or use Ctrl+F9 for Build All instead of the default compiler (I use Build = Ctrl+F9 and Build All = Shift+Ctrl+F9). Alternatively, install the Editor Toolbar package, add all the different build and compile functions to the toolbar. Now everything is one click away! Quick and easy solution... :-) See above! However a Toolbar shortcut might be an incentive. Thanks for the hint. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Vincent Snijders ha scritto: Graeme Geldenhuys schreef: On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Don't assume, research. Not convinced, GTK1 implementation of TMemo InsertText: if NewTextLength - CutLength 0 then begin gtk_editable_insert_text(PGtkEditable(widget), char, NewTextLength - CutLength, Position); end; g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text'); GTK2 implementation of Tmemo InsertText: if NewTextLength - CutLength 0 then begin gtk_text_buffer_insert(TextBuffer, StartIter, TheText, NewTextLength - CutLength); end; g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text'); GTK2 scrolls in order to show the text just inserted, GTK1 doesn't. Convinced now? Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Vincent Snijders ha scritto: Giuliano Colla schreef: Vincent Snijders ha scritto: Graeme Geldenhuys schreef: On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Don't assume, research. Not convinced, GTK1 implementation of TMemo InsertText: if NewTextLength - CutLength 0 then begin gtk_editable_insert_text(PGtkEditable(widget), char, NewTextLength - CutLength, Position); end; g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text'); GTK2 implementation of Tmemo InsertText: if NewTextLength - CutLength 0 then begin gtk_text_buffer_insert(TextBuffer, StartIter, TheText, NewTextLength - CutLength); end; g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text'); GTK2 scrolls in order to show the text just inserted, GTK1 doesn't. Convinced now? Convinced, that you did some research: yes. Convinced, that you did enough research: no. Convinced, that scrolling the text after inserting text is agains the native behaviour of the native widgetset: no, not at all. IMO, the LCL should give the application users a native look and feel using the native components as much as possible. At this moment, we are failing in this respect with our current implementation of the Treeview and the Toolbar, for example, since they are drawn by the LCL and not by the widget set. This will probably change in the future, keeping the current Treeview as TLCLTreeView or something like that. The LCL should give the application developer a consistent (VCL compatible) interface to accomplish that. In this case when you append or insert text the application developer expects that gtk1 and gtk2 (and all widget set) do the same thing: either scroll to end or leave the cursor on the current position. I don't think that this scrolling (or not scrolling) can be considered intrisically part of a widget set. Suppose we decide that a widget should scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should do that. The gtk1 implementation should add extra code to accomplish that. Suppose we decide that a widget should not scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should not do that. The gtk2 implementation should record the current position and add extra code to accomplish to keep the cursor on the current position. I would sugest to fix the gtk1 implementation. I hope this is clear now, if not, feel free to ask for clarification. What you say is clear, and I do agree with you. LCL should provide consistent behavior across widgetsets. Maybe I can disagree on what's the best way (i.e. minimum work-best result) to achieve this result, but that's another matter, and it's up to you, after all. I can just provide my point of view as a contribute to the discussion. But when I see other developers say exactly the opposite, i.e. that LCL should provide native behavior, and maintain that some properties shouldn't be implemented in some widgesets because they're not natively available, then I get confused. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Giuliano Colla schreef: Vincent Snijders ha scritto: Graeme Geldenhuys schreef: On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Don't assume, research. Not convinced, GTK1 implementation of TMemo InsertText: if NewTextLength - CutLength 0 then begin gtk_editable_insert_text(PGtkEditable(widget), char, NewTextLength - CutLength, Position); end; g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text'); GTK2 implementation of Tmemo InsertText: if NewTextLength - CutLength 0 then begin gtk_text_buffer_insert(TextBuffer, StartIter, TheText, NewTextLength - CutLength); end; g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text'); GTK2 scrolls in order to show the text just inserted, GTK1 doesn't. Convinced now? Convinced, that you did some research: yes. Convinced, that you did enough research: no. Convinced, that scrolling the text after inserting text is agains the native behaviour of the native widgetset: no, not at all. IMO, the LCL should give the application users a native look and feel using the native components as much as possible. At this moment, we are failing in this respect with our current implementation of the Treeview and the Toolbar, for example, since they are drawn by the LCL and not by the widget set. This will probably change in the future, keeping the current Treeview as TLCLTreeView or something like that. The LCL should give the application developer a consistent (VCL compatible) interface to accomplish that. In this case when you append or insert text the application developer expects that gtk1 and gtk2 (and all widget set) do the same thing: either scroll to end or leave the cursor on the current position. I don't think that this scrolling (or not scrolling) can be considered intrisically part of a widget set. Suppose we decide that a widget should scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should do that. The gtk1 implementation should add extra code to accomplish that. Suppose we decide that a widget should not scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should not do that. The gtk2 implementation should record the current position and add extra code to accomplish to keep the cursor on the current position. I would sugest to fix the gtk1 implementation. I hope this is clear now, if not, feel free to ask for clarification. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
On Wed, Jan 30, 2008 at 08:36:00PM +0100, Giuliano Colla wrote: OK, I understand your issue now. Simple solution is: Always do a Build All. :-) By what means do you suggest to obtain that from everybody: moral suasion, menaces, salary cut, spanking or other corporal punishment? :-) Much worse. Threathen to introduce formal procedures. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Giuliano Colla wrote: Vincent Snijders ha scritto: Giuliano Colla schreef: Vincent Snijders ha scritto: Graeme Geldenhuys schreef: On 29/01/2008, Vincent Snijders [EMAIL PROTECTED] wrote: You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. But how do you know if that's not maybe the native behaviour of the underlying widgetset? I think this is what Giuliano was trying to say or assumed. Don't assume, research. Not convinced, GTK1 implementation of TMemo InsertText: if NewTextLength - CutLength 0 then begin gtk_editable_insert_text(PGtkEditable(widget), char, NewTextLength - CutLength, Position); end; g_signal_stop_emission_by_name(PGtkObject(widget), 'insert_text'); GTK2 implementation of Tmemo InsertText: if NewTextLength - CutLength 0 then begin gtk_text_buffer_insert(TextBuffer, StartIter, TheText, NewTextLength - CutLength); end; g_signal_stop_emission_by_name(PGtkObject(Textbuffer), 'insert-text'); GTK2 scrolls in order to show the text just inserted, GTK1 doesn't. Convinced now? Convinced, that you did some research: yes. Convinced, that you did enough research: no. Convinced, that scrolling the text after inserting text is agains the native behaviour of the native widgetset: no, not at all. IMO, the LCL should give the application users a native look and feel using the native components as much as possible. At this moment, we are failing in this respect with our current implementation of the Treeview and the Toolbar, for example, since they are drawn by the LCL and not by the widget set. This will probably change in the future, keeping the current Treeview as TLCLTreeView or something like that. The LCL should give the application developer a consistent (VCL compatible) interface to accomplish that. In this case when you append or insert text the application developer expects that gtk1 and gtk2 (and all widget set) do the same thing: either scroll to end or leave the cursor on the current position. I don't think that this scrolling (or not scrolling) can be considered intrisically part of a widget set. Suppose we decide that a widget should scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should do that. The gtk1 implementation should add extra code to accomplish that. Suppose we decide that a widget should not scroll when adding line to a LCL TMemo should scroll that line into view, then all widgetset should not do that. The gtk2 implementation should record the current position and add extra code to accomplish to keep the cursor on the current position. I would sugest to fix the gtk1 implementation. I hope this is clear now, if not, feel free to ask for clarification. What you say is clear, and I do agree with you. LCL should provide consistent behavior across widgetsets. Maybe I can disagree on what's the best way (i.e. minimum work-best result) to achieve this result, but that's another matter, and it's up to you, after all. I can just provide my point of view as a contribute to the discussion. But when I see other developers say exactly the opposite, i.e. that LCL should provide native behavior, and maintain that some properties shouldn't be implemented in some widgesets because they're not natively available, then I get confused. Native widgets native behaviour. The LCL adds functionality to native widgets so a LCL user wil benefit from that and will het the same behaviour. (also the VCL added some different behaviour to win32 widgets) On case by case base it is decided if a certain behaviour is compatible with delphi, is better than delphi or is behaving like most widgetsets. For scrolling after a line is added, I don't know. Personally I hate it when a memo gets updated and I want to read the contents the same time. Marc Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Marco van de Voort ha scritto: On Wed, Jan 30, 2008 at 08:36:00PM +0100, Giuliano Colla wrote: OK, I understand your issue now. Simple solution is: Always do a Build All. :-) By what means do you suggest to obtain that from everybody: moral suasion, menaces, salary cut, spanking or other corporal punishment? :-) Much worse. Threathen to introduce formal procedures. Mmmmh. Then I too would be forced to follow them! They'll never believe it! :-( Better dig into Codetools unexplored land and find a way to insert a -B in Compiler Options! Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Giuliano Colla wrote: With Lazarus this need has further increased, in order to achieve consistent behavior with different widgesets: gtk1 TMemo doesn't scroll automatically when text entered exceeds the visible portion, while gtk2 and qt do, gtk1 doesn't remove the scrollbars when cleared, Qt disables the child form when then main form is disabled, while gtk1/2 don't, etc.etc. Some time ago I fixed the gtk1 bug where the memo would not scroll when Lines.Add was used. Currently it will scroll if the cursor is at the end of the text when Lines.Add is used. The cursor will then be moved to the end of the text as well. Both gtk1 and gtk2 will behave the same in this regard. Andrew _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Giuliano Colla schreef: For my applications I'm forced to use some ifdefs, in order to have the same codebase for a number of similar applications. With Lazarus this need has further increased, in order to achieve consistent behavior with different widgesets: gtk1 TMemo doesn't scroll automatically when text entered exceeds the visible portion, while gtk2 and qt do, gtk1 doesn't remove the scrollbars when cleared, Qt disables the child form when then main form is disabled, while gtk1/2 don't, etc.etc. You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. That is why there different widgetset backends too, not just to create different widgets, but also to make them behave consistent. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] I have a dream
For my applications I'm forced to use some ifdefs, in order to have the same codebase for a number of similar applications. With Lazarus this need has further increased, in order to achieve consistent behavior with different widgesets: gtk1 TMemo doesn't scroll automatically when text entered exceeds the visible portion, while gtk2 and qt do, gtk1 doesn't remove the scrollbars when cleared, Qt disables the child form when then main form is disabled, while gtk1/2 don't, etc.etc. With ifdefs I meet the problem which exists since when ifdefs have been invented: a unit compiled with a conditional set in a given way, isn't recompiled if the global setting is changed, because the compiled unit appear to be in sync with the source. If one forgets to rebuld everything, or if one forgets what was the setting of the last build, one may obtain a program which compile properly, but shows unwanted inconsistencies, sometimes hard to detect. My dream is to have am environment which can detect an inconsistency in conditionals, and rebuild whatever is needed automagically. As Lazarus/fpc is the best development environment in the world :-) (even if it doesn't support dynamic packages ;-) ) I'd like to see it having also this feature, which nobody else, to my knowledge, provides. Is there a way to achieve that? Are there already some hooks in .ppu or in .o which can be exploited for that purpose? I'd gladly help to develop what's required, but advice from compiler/IDE guru's could lead me to the right path (or make me forget about it :-( ). Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Giuliano Colla wrote / napísal(a): Is there a way to achieve that? Are there already some hooks in .ppu or in .o which can be exploited for that purpose? I'd gladly help to develop what's required, but advice from compiler/IDE guru's could lead me to the right path (or make me forget about it :-( ). Yes there is, by stopping useless discussions and doing some bug fixing. These inconsistencies are mostly bugs, and YOU can squish them just like any other person. Giuliano Ales _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I have a dream
Vincent Snijders ha scritto: Giuliano Colla schreef: For my applications I'm forced to use some ifdefs, in order to have the same codebase for a number of similar applications. With Lazarus this need has further increased, in order to achieve consistent behavior with different widgesets: gtk1 TMemo doesn't scroll automatically when text entered exceeds the visible portion, while gtk2 and qt do, gtk1 doesn't remove the scrollbars when cleared, Qt disables the child form when then main form is disabled, while gtk1/2 don't, etc.etc. You don't need ifdefs. You need to fix the differences. Fix the gtk1 interface to scroll the memo. Fix the gtk1 interface to remove the scrollbars, when the memo is cleared Fix gtk1 and gtk2 interface to disable childforms, if the main form is enabled. This is just a side issue. In this very moment some additional ifdef's are required just to go on quickly. I met some of those issues while dealing with a test of threads with different widgesets. It wasn't worth while to stop and fix the widgeset just to make a test program output more readable. But once those issues are fixed (with my help, if I'm up to the task), the need for unavoidable ifdef's remains, related to application options. So my question is still open. There's a way to make the IDE/compiler aware of the change of conditionals? I'm the only one with this requirement? Can I do something in this line? Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
