Re: [lazarus] Delphi incompatibilities in TForm
Giuliano, I fully agree with you and couldn't say it better myself. This is our company's feeling about commercial software as well. The same thing could be said for my previous two companies I worked for. The clients dictates what they like and we must supply - after all, they paid for the software. We always implement two or three different GUI styles in a prototype. Show it to the client and 100% of the time they choose the one that isn't based on standard Windows style guides (all my previous projects were Windows only - the latest one isn't). Simple things like alternate colors in grid rows to button style tabsheets, etc.. The OS theme should be used as a default to the LCL, but the developer must ultimately be able to override those defaults via properties or sub-classing components. And those changes must be able at design time and runtime. Regards, - Graeme - On 4/17/07, Giuliano Colla <[EMAIL PROTECTED]> wrote: In this case the developer has the option to use an application specific appname.gtkrc file to override the standard theme and use his own. This is hardly a solution. What real people in real world needs is to give the right appearence to widgets, in order to create user friendly applications. This means dynamically changing colors, image backgrounds, and whatever is needed to convey the right information in the most intuitive way. For the same reasons, buttons and other widgets are often of different size and shape, and widget style and theme goe to hell. A default theme is a goot thing for beginners, just to provide them a consistent starting point, but as they proceed and learn, they override the theme more and more frequenly, until nothing is left. The sacred cow of Widget Style can be reasonable for default values, but nothing more. Besides my company needs, which doesn't give a damn about themes and widget style, of all the commercial Delphi application I've seen, and I've seen quite a lot, there's none which sticked to any known widget style, but all of them were using colors, shapes and bitmaps consistent with company style, and application needs, which was neither Qt, nor Windows, nor, God forbid, Gtk. Just my penny of wisdom, late in the night. Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Maskedit and copyrighted material
On 4/17/07, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: For future implementations, I think it´s ok to copy the class declaration on the interface section (or am I wrong?), Of course I meant only the public parts, and not the private section. I just did a diff between menus.pp from lazarus and menus.pas from delphi, and it looks a good example of how to create a compatible interface (public parts of the classes look very similar on the interface, but private sections and all implementation code is completely different. The only part a little scary is the declaration of TMenuActionLink. There are no differences, but this class has only protected section. Also on menuactionlink.inc the code is a little bit too similar. But then it has only trivial procedures like getters. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
On 4/17/07, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: Mark, could you point us to how to fix this? (Which is something much better to do rether then pointlessly arguing about this) What exactly is theming support? How does one implement it? Are there functions in Gtk to retrive the colors for the theme, and then you use them and set the color for the app? And how could one set the color of a form? I searched a lot, but the I wonder if it wouldn't be done similar to the suggested ways of changing the GtkLabel background color. I did some Google'ing and for a GtkLabel they seem to create a in-memory rc-style (something like that). Apply the colors to the rc-style and apply the style to the GtkLabel. Take all this with a pinch of salt, as I have no idea how low level Gtk works. I only use the LCL. :-) code is a bit hard to understand. There are several layers of components on a TForm on gtk. There is a normal widget, then a scrolling widget, then another widget to make the client area separate from the menu, and then another thing... Good question.. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Maskedit and copyrighted material
I did some random checks, and the rest of the lcl code looks ok. I checked clipbrd, stdactns, forms, etc, and looks clean from vcl code, with original implementations and white places on things not implemented yet. But there could be more copyrighted spots, so a good check would be nice. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Maskedit and copyrighted material
Felipe Monteiro de Carvalho schreef: I would sugest investigating all patches by Tony. Does anyone know how to get all revisions with a svn log with the string "Tony" ? I couldn´t find such option on viewcvs Get the complete log at http://svn.freepascal.org/svn/logs/lazarus-all.log and search for Tony. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Maskedit and copyrighted material
On 4/17/07, Vincent Snijders <[EMAIL PROTECTED]> wrote: Get the complete log at http://svn.freepascal.org/svn/logs/lazarus-all.log and search for Tony. Just did. Hi did some small patches about things that don´t exist on delphi. He also created the first implementation for printers.pas. His implementation was in fact a copy from Delphi with some things comented out. But subsequently the unit was completely rewriten, and isn´t a delphi copy since 2004. Details here: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/lcl/printers.pas?root=lazarus&rev=9948&view=log -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Maskedit and copyrighted material
Felipe Monteiro de Carvalho wrote: The first patch about this is marked as: [snip] For future implementations, I think it´s ok to copy the class declaration on the interface section (or am I wrong?), because you are using it to provide a compatible interface, and then one should not look at Delphi´s implementation and implement it´s own version as he imagines things should work. Copying public and protected as in writing them over is ok, copying as in copy&paste not imo. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] devel: Imaging, Mask vs. Alpha
Mattias Gaertner wrote: On Mon, 16 Apr 2007 22:46:49 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Mon, 16 Apr 2007 11:20:55 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Continuing my TRawImageQuestion. While implementing cursors and imagelists, Paul and I start to get confused. It appears that Mask and Alpha are treated as equal while in fact they are each others inverse. (An 1 in a mask means that this part of the image is masked, not drawn, where for alpha a 1 means opaque, fully drawn) A RawImageDesription describes the RGB and Alpha parts of an image. It has also a flag that the Alpha is separate. This got introduced since traditional windows has only an image and a (1bpp) mask. When reading such image, the mask gets converted into a 1bit separate alpha. With CreateBitmapFromRawImage the fun starts. It creates a bitmap and mask handle form the rawimage. The maskhandle is created from the (separate) alpha and is in fact returning an alpha handle and not a maskhandle. On win32 this is nonsense since alpha is never separated. So I think a Maskhandle should return what it means: a handle to a Mask (and only in the case when the description had the AlphaSeparate flag). Comments ? Maybe we need an enum, how to interpret the alpha value? I was think on that also, but somehow didn't sound right. I don't know exactly for all widgets, but as far as I can tell the separate alpha is only used for win32 1bit masks. If this is the case, then ignore my other mail since TRawImage.MaskData is indeed MaskData. But then the AlphaSeparate, AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder and AlphaByteOrder are not really Alpha, but Mask -> MaskSeparate (or HasMask), MaskBitsPerPixel, MaskLineEnd, MaskBitOrder and MaskByteOrder True. What do we take instead of the enum? define: if Mask is separate, then it is opacity, otherwise transparency? Something like that. But IMO there is no such thing as MaskIsSeparate since there won't be an included mask. HasMask is a better name I think. And if we add MaskPrec and MaskShift: cardinal; then the Alpha definition is complete independent of a Mask definition BTW, why are the xxxPrec and xxxShift defined as Cardinal and not byte ? Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] devel: Imaging, Mask vs. Alpha
On Tue, 17 Apr 2007 10:24:36 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > On Mon, 16 Apr 2007 22:46:49 +0200 > > Marc Weustink <[EMAIL PROTECTED]> wrote: > > > >> Mattias Gaertner wrote: > >>> On Mon, 16 Apr 2007 11:20:55 +0200 > >>> Marc Weustink <[EMAIL PROTECTED]> wrote: > >>> > Continuing my TRawImageQuestion. > > While implementing cursors and imagelists, Paul and I start to > get confused. It appears that Mask and Alpha are treated as > equal while in fact they are each others inverse. (An 1 in a > mask means that this part of the image is masked, not drawn, > where for alpha a 1 means opaque, fully drawn) > > A RawImageDesription describes the RGB and Alpha parts of an > image. It has also a flag that the Alpha is separate. This got > introduced since traditional windows has only an image and a > (1bpp) mask. When reading such image, the mask gets converted > into a 1bit separate alpha. > > With CreateBitmapFromRawImage the fun starts. It creates a bitmap > and mask handle form the rawimage. The maskhandle is created from > the (separate) alpha and is in fact returning an alpha handle and > not a maskhandle. On win32 this is nonsense since alpha is never > separated. So I think a Maskhandle should return what it means: a > handle to a Mask (and only in the case when the description had > the AlphaSeparate flag). > > Comments ? > >>> Maybe we need an enum, how to interpret the alpha value? > >> I was think on that also, but somehow didn't sound right. I don't > >> know exactly for all widgets, but as far as I can tell the > >> separate alpha is only used for win32 1bit masks. > >> If this is the case, then ignore my other mail since > >> TRawImage.MaskData is indeed MaskData. But then the AlphaSeparate, > >> AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder and AlphaByteOrder > >> are not really Alpha, but Mask -> MaskSeparate (or HasMask), > >> MaskBitsPerPixel, MaskLineEnd, MaskBitOrder and MaskByteOrder > > > > True. > > What do we take instead of the enum? > > define: if Mask is separate, then it is opacity, otherwise > > transparency? > > Something like that. But IMO there is no such thing as MaskIsSeparate > since there won't be an included mask. HasMask is a better name I > think. ok. Will you change it? > And if we add MaskPrec and MaskShift: cardinal; then the Alpha > definition is complete independent of a Mask definition Ehm, but they are not independent, are they? You can not have both!? > BTW, why are the xxxPrec and xxxShift defined as Cardinal and not > byte ? Why should they? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] devel: Imaging, Mask vs. Alpha
Mattias Gaertner wrote: On Tue, 17 Apr 2007 10:24:36 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Mon, 16 Apr 2007 22:46:49 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Mon, 16 Apr 2007 11:20:55 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Continuing my TRawImageQuestion. While implementing cursors and imagelists, Paul and I start to get confused. It appears that Mask and Alpha are treated as equal while in fact they are each others inverse. (An 1 in a mask means that this part of the image is masked, not drawn, where for alpha a 1 means opaque, fully drawn) A RawImageDesription describes the RGB and Alpha parts of an image. It has also a flag that the Alpha is separate. This got introduced since traditional windows has only an image and a (1bpp) mask. When reading such image, the mask gets converted into a 1bit separate alpha. With CreateBitmapFromRawImage the fun starts. It creates a bitmap and mask handle form the rawimage. The maskhandle is created from the (separate) alpha and is in fact returning an alpha handle and not a maskhandle. On win32 this is nonsense since alpha is never separated. So I think a Maskhandle should return what it means: a handle to a Mask (and only in the case when the description had the AlphaSeparate flag). Comments ? Maybe we need an enum, how to interpret the alpha value? I was think on that also, but somehow didn't sound right. I don't know exactly for all widgets, but as far as I can tell the separate alpha is only used for win32 1bit masks. If this is the case, then ignore my other mail since TRawImage.MaskData is indeed MaskData. But then the AlphaSeparate, AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder and AlphaByteOrder are not really Alpha, but Mask -> MaskSeparate (or HasMask), MaskBitsPerPixel, MaskLineEnd, MaskBitOrder and MaskByteOrder True. What do we take instead of the enum? define: if Mask is separate, then it is opacity, otherwise transparency? Something like that. But IMO there is no such thing as MaskIsSeparate since there won't be an included mask. HasMask is a better name I think. ok. Will you change it? Yes. And if we add MaskPrec and MaskShift: cardinal; then the Alpha definition is complete independent of a Mask definition Ehm, but they are not independent, are they? You can not have both!? It is a bit useless, but technically there is imo no limitation. And for naming it becomes clear what is meant. Mask for Mask and Alpha for alpha. Thinking of it, when having a MaskPrec=0 it means the same as HasMask=False BTW, why are the xxxPrec and xxxShift defined as Cardinal and not byte ? Why should they? Since I think a 100 bit precision and a 123456789 shift won't be needed. I was even considering in making them an enum, so some lookups could be made easier and some range checking can be avoided Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TCustomGrid and GridLineWidth property
On 4/17/07, Jesús Reyes A. <[EMAIL PROTECTED]> wrote: Yes, is not yet implemented, the true is that I never found a use for that, maybe you found it? How else do you hide the grid lines? -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] devel: Imaging, Mask vs. Alpha
On Tue, 17 Apr 2007 11:07:59 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > On Tue, 17 Apr 2007 10:24:36 +0200 > > Marc Weustink <[EMAIL PROTECTED]> wrote: > > > >> Mattias Gaertner wrote: > >>> On Mon, 16 Apr 2007 22:46:49 +0200 > >>> Marc Weustink <[EMAIL PROTECTED]> wrote: > >>> > Mattias Gaertner wrote: > > On Mon, 16 Apr 2007 11:20:55 +0200 > > Marc Weustink <[EMAIL PROTECTED]> wrote: > > > >> Continuing my TRawImageQuestion. > >> > >> While implementing cursors and imagelists, Paul and I start to > >> get confused. It appears that Mask and Alpha are treated as > >> equal while in fact they are each others inverse. (An 1 in a > >> mask means that this part of the image is masked, not drawn, > >> where for alpha a 1 means opaque, fully drawn) > >> > >> A RawImageDesription describes the RGB and Alpha parts of an > >> image. It has also a flag that the Alpha is separate. This got > >> introduced since traditional windows has only an image and a > >> (1bpp) mask. When reading such image, the mask gets converted > >> into a 1bit separate alpha. > >> > >> With CreateBitmapFromRawImage the fun starts. It creates a > >> bitmap and mask handle form the rawimage. The maskhandle is > >> created from the (separate) alpha and is in fact returning an > >> alpha handle and not a maskhandle. On win32 this is nonsense > >> since alpha is never separated. So I think a Maskhandle should > >> return what it means: a handle to a Mask (and only in the case > >> when the description had the AlphaSeparate flag). > >> > >> Comments ? > > Maybe we need an enum, how to interpret the alpha value? > I was think on that also, but somehow didn't sound right. I don't > know exactly for all widgets, but as far as I can tell the > separate alpha is only used for win32 1bit masks. > If this is the case, then ignore my other mail since > TRawImage.MaskData is indeed MaskData. But then the > AlphaSeparate, AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder > and AlphaByteOrder are not really Alpha, but Mask -> > MaskSeparate (or HasMask), MaskBitsPerPixel, MaskLineEnd, > MaskBitOrder and MaskByteOrder > >>> True. > >>> What do we take instead of the enum? > >>> define: if Mask is separate, then it is opacity, otherwise > >>> transparency? > >> Something like that. But IMO there is no such thing as > >> MaskIsSeparate since there won't be an included mask. HasMask is a > >> better name I think. > > > > ok. Will you change it? > > Yes. > > >> And if we add MaskPrec and MaskShift: cardinal; then the Alpha > >> definition is complete independent of a Mask definition > > > > Ehm, but they are not independent, are they? You can not have both!? > > It is a bit useless, but technically there is imo no limitation. > And for naming it becomes clear what is meant. Mask for Mask and > Alpha for alpha. Thinking of it, when having a MaskPrec=0 it means > the same as HasMask=False True. > >> BTW, why are the xxxPrec and xxxShift defined as Cardinal and not > >> byte ? > > > > Why should they? > > Since I think a 100 bit precision and a 123456789 shift won't be > needed. You will only save the memory by using packed or an array. With packed we will loose speed and with an array loose readability. > I was even considering in making them an enum, so some > lookups could be made easier and some range checking can be avoided I don't see, how you can avoid range checking? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] devel: Imaging, Mask vs. Alpha
Mattias Gaertner wrote: On Tue, 17 Apr 2007 11:07:59 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Tue, 17 Apr 2007 10:24:36 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Mon, 16 Apr 2007 22:46:49 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Mon, 16 Apr 2007 11:20:55 +0200 Marc Weustink <[EMAIL PROTECTED]> wrote: Continuing my TRawImageQuestion. While implementing cursors and imagelists, Paul and I start to get confused. It appears that Mask and Alpha are treated as equal while in fact they are each others inverse. (An 1 in a mask means that this part of the image is masked, not drawn, where for alpha a 1 means opaque, fully drawn) A RawImageDesription describes the RGB and Alpha parts of an image. It has also a flag that the Alpha is separate. This got introduced since traditional windows has only an image and a (1bpp) mask. When reading such image, the mask gets converted into a 1bit separate alpha. With CreateBitmapFromRawImage the fun starts. It creates a bitmap and mask handle form the rawimage. The maskhandle is created from the (separate) alpha and is in fact returning an alpha handle and not a maskhandle. On win32 this is nonsense since alpha is never separated. So I think a Maskhandle should return what it means: a handle to a Mask (and only in the case when the description had the AlphaSeparate flag). Comments ? Maybe we need an enum, how to interpret the alpha value? I was think on that also, but somehow didn't sound right. I don't know exactly for all widgets, but as far as I can tell the separate alpha is only used for win32 1bit masks. If this is the case, then ignore my other mail since TRawImage.MaskData is indeed MaskData. But then the AlphaSeparate, AlphaBitsPerPixel, AlphaLineEnd, AlphaBitOrder and AlphaByteOrder are not really Alpha, but Mask -> MaskSeparate (or HasMask), MaskBitsPerPixel, MaskLineEnd, MaskBitOrder and MaskByteOrder True. What do we take instead of the enum? define: if Mask is separate, then it is opacity, otherwise transparency? Something like that. But IMO there is no such thing as MaskIsSeparate since there won't be an included mask. HasMask is a better name I think. ok. Will you change it? Yes. And if we add MaskPrec and MaskShift: cardinal; then the Alpha definition is complete independent of a Mask definition Ehm, but they are not independent, are they? You can not have both!? It is a bit useless, but technically there is imo no limitation. And for naming it becomes clear what is meant. Mask for Mask and Alpha for alpha. Thinking of it, when having a MaskPrec=0 it means the same as HasMask=False True. BTW, why are the xxxPrec and xxxShift defined as Cardinal and not byte ? Why should they? Since I think a 100 bit precision and a 123456789 shift won't be needed. You will only save the memory by using packed or an array. With packed we will loose speed and with an array loose readability. No if you declare a record like TMyRecord = record field1: Cardinal; field2: Byte; field3: Byte; field4: Byte; field5: Cardinal; end; then the record is aligned on a cardinal boundary and field2..4 are aligned on a byte boundary, without the need for packing. field5 is aligned to a cardinal boundary again. The example here only occupies 12 bytes, without speed degradation. I was even considering in making them an enum, so some lookups could be made easier and some range checking can be avoided I don't see, how you can avoid range checking? If you define a lookup array[0..15] you dont have to check if Prec will be larger than 15 for instance. Marc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] [patch] - grids.pas (GridLineWidth)
Hi
Attached is a patch for the TCustomGrid.GridLineWidth property. Please
review before applying this patch.
This is not a full implementation but rather a quick cosmetic
implementation. The difference is that this patch changes the grid
line width for painting only, but not the actual offset or regions of
the cells due to the change in Grid Line Width. Fixed columns don't
draw the grid lines thicker than 1 (not sure if this is correct
behaviour).
At least with this patch you are now able to hide the grid lines
(GridLineWidth = 0) when required. This is the main feature I was
missing to get my custom component to work.
In the Delphi implementation, the cell size will stay the same even
though the grid line width increases. Delphi does cause a very
strange effect (I think it's a bug) when the GridLineWidth is set to a
negative values. I don't think Lazarus needs to copy that behaviour
so the lowest value the GridLineWidth will go is 0 in the LCL.
--
Graeme Geldenhuys
There's no place like S34° 03.168' E018° 49.342'
Index: lcl/grids.pas
===
--- lcl/grids.pas (revision 10957)
+++ lcl/grids.pas (working copy)
@@ -2694,6 +2694,7 @@
{$endif}
with R, Canvas do begin
Pen.Color := fBorderColor;
+ Pen.Width := 1;
MoveTo(0,0);
LineTo(0,Bottom);
LineTo(Right, Bottom);
@@ -2936,44 +2937,64 @@
begin
// Draw Cell Grid or Maybe in the future Borders..
with Canvas, aRect do begin
-if (gdFixed in aState) then begin
+if (gdFixed in aState) then
+begin
Dv := goFixedVertLine in Options;
Dh := goFixedHorzLine in Options;
Pen.Style := psSolid;
- if not FFlat then begin
-if FTitleStyle=tsNative then begin
+ if FGridLineWidth > 0 then
+Pen.Width := 1
+ else
+Pen.Width := 0;
+ if not FFlat then
+ begin
+if FTitleStyle=tsNative then
+begin
aR := aRect;
DrawFrameControl(Handle, ar, DFC_BUTTON, DFCS_BUTTONPUSH);
exit;
-end else begin
- Pen.Color := cl3DHilight;
- MoveTo(Right - 1, Top);
- LineTo(Left, Top);
- LineTo(Left, Bottom);
- if FTitleStyle=tsStandard then begin
-// more contrast
-Pen.Color := cl3DShadow;
-MoveTo(Left+1, Bottom-2);
-LineTo(Right-2, Bottom-2);
-LineTo(Right-2, Top);
+end
+else
+begin
+ if FGridLineWidth > 0 then
+ begin
+Pen.Color := cl3DHilight;
+MoveTo(Right - 1, Top);
+LineTo(Left, Top);
+LineTo(Left, Bottom);
+if FTitleStyle=tsStandard then
+begin
+ // more contrast
+ Pen.Color := cl3DShadow;
+ MoveTo(Left+1, Bottom-2);
+ LineTo(Right-2, Bottom-2);
+ LineTo(Right-2, Top);
+end;
end;
end;
end;
Pen.Color := cl3DDKShadow;
-end else begin
+end
+else
+begin
Dv := goVertLine in Options;
Dh := goHorzLine in Options;
Pen.Style := fGridLineStyle;
Pen.Color := fGridLineColor;
+ Pen.Width := fGridLineWidth;
end;
-if Dh then begin
- MoveTo(Left, Bottom - 1);
- LineTo(Right, Bottom - 1);
+
+if fGridLineWidth > 0 then
+begin
+ if Dh then begin
+MoveTo(Left, Bottom - 1);
+LineTo(Right, Bottom - 1);
+ end;
+ if Dv then begin
+ MoveTo(Right - 1, Top);
+ LineTo(Right - 1, Bottom);
+ end;
end;
-if Dv then begin
- MoveTo(Right - 1, Top);
- LineTo(Right - 1, Bottom);
-end;
end;
end;
@@ -3284,9 +3305,9 @@
procedure TCustomGrid.SetGridLineWidth(const AValue: Integer);
begin
- // Todo
- if FGridLineWidth=AValue then exit;
- FGridLineWidth:=AValue;
+ if FGridLineWidth = AValue then
+exit;
+ FGridLineWidth := AValue;
Invalidate;
end;
@@ -6120,10 +6141,11 @@
goSmoothScroll ];
FScrollbars:=ssAutoBoth;
fGridState:=gsNormal;
- fDefColWidth:=DEFCOLWIDTH;
- fDefRowHeight:=DEFROWHEIGHT;
- fGridLineColor:=clSilver;
+ FDefColWidth:=DEFCOLWIDTH;
+ FDefRowHeight:=DEFROWHEIGHT;
+ FGridLineColor:=clSilver;
FGridLineStyle:=psSolid;
+ FGridLineWidth := 1;
fFocusColor:=clRed;
FFixedColor:=clBtnFace;
FSelectedColor:= clHighlight;
Re: [lazarus] License clarification for lazarus plug-ins
On Fri, Mar 30, 2007 at 06:38:00PM +0200, Micha Nelissen wrote: > If you haven't noticed yet, we have put an entry in the FAQ on the wiki > clarifying the license requirements for plug-ins in combination with > Lazarus, as there has been some confusion in this matter. > > http://wiki.lazarus.freepascal.org/Lazarus_Faq#Can_I_make_commercial_plug-ins_for_Lazarus_.3F > > > Can I make commercial plug-ins for Lazarus ? > > Yes, the IDEIntf part of the IDE is licensed under the LGPL with the > same exception, so that shared data structures in this part will not > force you to license your plug-in or design-time package under the GPL. > You are free to choose a plug-in of any license; we don't want to limit > your choice. Therefore non-GPL compatible plug-ins are allowed. Note > that it's not allowed to distribute a precompiled Lazarus with these > non-GPL-compatible plugins included statically; however, we do not see > this as a severe limitation, since recompiling Lazarus is easy. > So, will you go after violations like the GLScene integrated lazarus? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Felipe Monteiro de Carvalho ha scritto: Mark, could you point us to how to fix this? (Which is something much better to do rether then pointlessly arguing about this) What exactly is theming support? How does one implement it? Are there functions in Gtk to retrive the colors for the theme, and then you use them and set the color for the app? And how could one set the color of a form? I searched a lot, but the code is a bit hard to understand. There are several layers of components on a TForm on gtk. There is a normal widget, then a scrolling widget, then another widget to make the client area separate from the menu, and then another thing... I tried to debug, step by step, and one gets up to the point where a TGtkWidgetSet.SetWidgetColor is executed in gtkobject.inc, which finally calls a gtk_widget_set_style(aWidget,windowStyle) after setting some windowStyle fields. The same procedure is used for other widgets, such as buttons, where it works. Maybe the catch is in either setting windowStyle fields, or in calling the set_style method. From Glade I understand that a GTK form has no background color in itself (just a transparent background, about Style consistency!) but only a bitmap, so maybe a form widget should be treated differently from other widgets. Either setting other fields of windowStyle, or using a different method if AWidget is a form. If nobody is more knowledgeable, we may attempt the hard way, of trial and error, such as setting different windowStyle fields, or a different approach, tampering with form's canvas (as I currently do, but from the application). Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] License clarification for lazarus plug-ins
Marco van de Voort schreef: On Fri, Mar 30, 2007 at 06:38:00PM +0200, Micha Nelissen wrote: If you haven't noticed yet, we have put an entry in the FAQ on the wiki clarifying the license requirements for plug-ins in combination with Lazarus, as there has been some confusion in this matter. http://wiki.lazarus.freepascal.org/Lazarus_Faq#Can_I_make_commercial_plug-ins_for_Lazarus_.3F Can I make commercial plug-ins for Lazarus ? Yes, the IDEIntf part of the IDE is licensed under the LGPL with the same exception, so that shared data structures in this part will not force you to license your plug-in or design-time package under the GPL. You are free to choose a plug-in of any license; we don't want to limit your choice. Therefore non-GPL compatible plug-ins are allowed. Note that it's not allowed to distribute a precompiled Lazarus with these non-GPL-compatible plugins included statically; however, we do not see this as a severe limitation, since recompiling Lazarus is easy. So, will you go after violations like the GLScene integrated lazarus? In what way is the GLScene license non-GPL compatible? Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
On Tue, 17 Apr 2007 03:09:11 +0200 Giuliano Colla <[EMAIL PROTECTED]> wrote: > Lord Satan ha scritto:On Mon, 16 Apr 2007 23:58:30 +0200 > "Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote: > > Forcing all GTK applications to always use the theming colors is *not* > always the developers desire. > > In this case the developer has the option to use an application specific > appname.gtkrc file to override the standard theme and use his own. > > > This is hardly a solution. > > What real people in real world needs is to give the right appearence to > widgets, in order to create user friendly applications. This means > dynamically changing colors, image backgrounds, and whatever is needed to > convey the right information in the most intuitive way. For the same reasons, > buttons and other widgets are often of different size and shape, and widget > style and theme goe to hell. Real people are indows users? And the real world is the commercial one or do you mean crappy shareware apps as they do the same? I don't think it is very user friendly to override the users personal theme settings. The most intuitive way to convey information forces you to ignore the users theme? I think you have some problems with GUI design and how it should work. But I won't argue with you anymore just go ahead, fix the problem and sent a patch. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] GTK2 and ComboBox problem - correction
On Tuesday 17 April 2007 03:27, Andrew Haines wrote: > ok, I've just now added a bit of code about the combobox in gtk2. can > you update to at least revision 10957 and see if it has fixed the problem? > > Andrew updated so the revision no for 'trunk' shows as 10957 according to kdesvn. rebuilt Lazarus but problem still persists. btw if it helps I'm using FPC 2.0.4 ned. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Lord Satan ha scritto: On Tue, 17 Apr 2007 03:09:11 +0200 Giuliano Colla <[EMAIL PROTECTED]> wrote: Lord Satan ha scritto:On Mon, 16 Apr 2007 23:58:30 +0200 "Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote: Forcing all GTK applications to always use the theming colors is *not* always the developers desire. In this case the developer has the option to use an application specific appname.gtkrc file to override the standard theme and use his own. This is hardly a solution. What real people in real world needs is to give the right appearence to widgets, in order to create user friendly applications. This means dynamically changing colors, image backgrounds, and whatever is needed to convey the right information in the most intuitive way. For the same reasons, buttons and other widgets are often of different size and shape, and widget style and theme goe to hell. Real people are indows users? And the real world is the commercial one or do you mean crappy shareware apps as they do the same? I don't think it is very user friendly to override the users personal theme settings. The most intuitive way to convey information forces you to ignore the users theme? I think you have some problems with GUI design and how it should work. But I won't argue with you anymore just go ahead, fix the problem and sent a patch. You're right. If a feature isn't there, we do our best trying to provide it. Then it's up to developers to decide if they want override user theme or not. However, just to clarify my point of view, I've got a couple of examples. To test Lazarus, I've developed a small app wich mimcs Midnight Commander. It's something anybody might want to use from time to time, it's general purpose, and it *must* follow user personal preferences. Colors, fonts, etc. can't be anything else but what comes from personal theme choice. If the user loves a pink form, let him have it. But my applications, those I get my bread and butter from, are meant for customers which just have their specific needs, which go far beyond what a theme can do. That's the real word I was speaking about. Such as using a touch screen, and having buttons the size of your fingers and not the size of your mouse pointer. Or coping with unskilled operators, which are just confused by a "Windows like" behavior, because they're not used to it. Jumping from one field to the next is made by arrow-up and arrow-down, because TAB could be acceptable, but with SHIFT-TAB they get confused. All application specific things, which do not fit in any theme. But which make up quite a lot of the total. So OK, lets follow a theme when it's reasonable, let's give the designer the choice of overriding it when necessary. Delphi designers, which are far from stupid, went that way. It's a good way and it would be a pity to drop it. Delphi compatibility, IMHO should mean picking up the best of Delphi, dropping the bad things. Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
On 4/17/07, Giuliano Colla <[EMAIL PROTECTED]> wrote: Back to business. I've got exactly the same problem, but for me, with GTK1, changing the TEdit background color works just fine. Doesn't it work for you? Hey, progress!!! It didn't work 2 weeks ago. :-) It's still not 100% though. At least now the TEdit is consistent with other controls that have the same bug. http://www.freepascal.org/mantis/view.php?id=7555 I can change the background to a select few colors, but can't set it back to the default clWindow. See attached screenshot. The top edit changed color when I blanked the field, but as soon as I entered data, it should have changed to clWindow, which it didn't. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' editscreen.png Description: PNG image
Re: [lazarus] Delphi incompatibilities in TForm
On 4/17/07, Giuliano Colla <[EMAIL PROTECTED]> wrote: You're right. If a feature isn't there, we do our best trying to provide it. Then it's up to developers to decide if they want override user theme or not. However, just to clarify my point of view, I've got a couple of examples. [snip] I'm so glad someone understands what I'm trying to say. You've hit the nail on the head. Software is meant to be flexible and to fulfil the end-users needs. My end-users paid for their software and they don't want (for whatever reason that might be) the standard look for certain things. Be that Windows software or Linux software. As far as I understand from the theming support under Linux and Lazarus. Does that now mean I can change the look under Windows (TForm.Color for example), but not allowed under Linux. I thought Linux was all about choice! No suddenly we may have no choice. I can even give "real world example" other than software. ;-) If we as people had to follow the same 'theme' the following would happen: * We would all wear identical clothes. * We would have the same color car - God forbid the wife says she wants a red car. The factory said it must be black. * We would all drink the same brand beer (Ar) etc. PS 'Lord Satan': As per your rules that we may not override themes, how would you envision I notify my users what is required fields in a data entry screen at Form Show (see my previous thread for a longer explanation). An then notify them what is invalid or missing data at Save. No popups are allowed! In Delphi and Kylix I change the background color of a TEdit to clYellow for required fields and clRed for invalid or missing data. As soon as valid information has been entered the TEdit's background color changes back to normal (the default theme color - whatever that might be). -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] License clarification for lazarus plug-ins
On Tue, Apr 17, 2007 at 01:03:01PM +0200, Vincent Snijders wrote: > >>non-GPL-compatible plugins included statically; however, we do not see > >>this as a severe limitation, since recompiling Lazarus is easy. > >> > > > >So, will you go after violations like the GLScene integrated lazarus? > > In what way is the GLScene license non-GPL compatible? It's MPL, and it is designtime. Note that "violation" is a bit of a big word, specially since all people involved are on speaking terms. It is more meant as a testcase for the new policy. Specially because this is the exact example that I gave that started this discussion (MPL designtime) The first point would be to investigate if there is MPL code in the designtime parts. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
On 4/17/07, Giuliano Colla <[EMAIL PROTECTED]> wrote: > I can change the background to a select few colors, but can't set it > back to the default clWindow. See attached screenshot. The top edit > changed color when I blanked the field, but as soon as I entered data, > it should have changed to clWindow, which it didn't. This is true for all the controls I've tested. Oops! :-) Cheer up, the road is long and full of sharp stones, but we'll make it! :-) I'm sure we will. Thanks for the work-around hints. I'll give them a try. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Graeme Geldenhuys ha scritto: On 4/17/07, Giuliano Colla <[EMAIL PROTECTED]> wrote: Back to business. I've got exactly the same problem, but for me, with GTK1, changing the TEdit background color works just fine. Doesn't it work for you? Hey, progress!!! It didn't work 2 weeks ago. :-) It's still not 100% though. At least now the TEdit is consistent with other controls that have the same bug. http://www.freepascal.org/mantis/view.php?id=7555 I can change the background to a select few colors, but can't set it back to the default clWindow. See attached screenshot. The top edit changed color when I blanked the field, but as soon as I entered data, it should have changed to clWindow, which it didn't. This is true for all the controls I've tested. My workaround: get the Hex value for the default color, and use it instead. In place of clBtnFace I use $E0E0E0, in my environment. But if you must check the property later, you must set the color twice: Widget.color := $E0E0E0; // Changes the color Widget.Color := clBtnFace; // doesn't change anything but sets the property consistently with the color shown. Cheer up, the road is long and full of sharp stones, but we'll make it! Giuliano P.S. I tried to set all conceivable fields of WindowsStyle to the desired color, but the result is always the same. The only workaround available is: 1) Form1.Color := clWatever; // this sets the form property which is seen by ParentColor of children widgets 2) Application.ProcessMessages; (otherwise the change is deferred, and the form goes back to the original color) 3) Form1.Canvas.Color := clWatever; 4) Form1.Canvas.FillRect(0,0,width,height); Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TCustomGrid and GridLineWidth property
--- Graeme Geldenhuys <[EMAIL PROTECTED]> escribió:
> On 4/17/07, Jesús Reyes A. <[EMAIL PROTECTED]> wrote:
> >
> > Yes, is not yet implemented, the true is that I never found a use
> for that,
> > maybe you found it?
>
> How else do you hide the grid lines?
>
Some ways:
1) grid.Options := grid.Options - goGridHorzLine - goGridVertLine
{-goFixedVertLine-goFixedHorzLine};
2) Grid.GridLineStyle := psClear; (non-fixed gridlines only)
3) Grid.GridLineColor := Grid.Color; (ditto, and not in every
application)
Jesus Reyes A.
__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Graeme Geldenhuys ha scritto: [...] PS 'Lord Satan': As per your rules that we may not override themes, how would you envision I notify my users what is required fields in a data entry screen at Form Show (see my previous thread for a longer explanation). An then notify them what is invalid or missing data at Save. No popups are allowed! In Delphi and Kylix I change the background color of a TEdit to clYellow for required fields and clRed for invalid or missing data. As soon as valid information has been entered the TEdit's background color changes back to normal (the default theme color - whatever that might be). Back to business. I've got exactly the same problem, but for me, with GTK1, changing the TEdit background color works just fine. Doesn't it work for you? Giuliano _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Bitmap troubles on Win9x
Hi I have a program that I've made with lazaus which in the main form is a Toolbar and a some menus, the menu items and toolbar buttons are all setup with actions in an action list. The trouble I'm finding is that if they have bitmaps when starting the program on Windows 95 and 98 I get: "Error [menu item name].BitMap.Data: Failed to create bitmaps" This also happened on Win95 (bit not win98) with a listview component on a different window before I gave the bitmaps to the toolbar and menus. After clicking OK I get: Runtime error 217 at $005370F2 $005370F2 DOUNHANDLEDEXCEPTION, line 156 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc $00533C5C fpc_reraise, line 266 of C:/lazarus/source/fpcbuild/2.0.4/fpcsrc/rtl/inc/except.inc $0040C77B TAPPLICATION__CREATEFORM, line 1558 of ./include/application.inc $0057863C main, line 21 of remdebug.lpr $005339EE EXE_ENTRY, line 420 of system.pp The bitmaps are stored in an ImageList component. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] [patch] - grids.pas (GridLineWidth)
--- Graeme Geldenhuys <[EMAIL PROTECTED]> escribió: > Hi > > Attached is a patch for the TCustomGrid.GridLineWidth property. > Please > review before applying this patch. > Looks ok, the only problem I see is that, currently the property default for GridLineWidth is set to 1, but as grid doesn't set the GridLineWidth at creation it takes value 0, this value is stored in lfm file for every project that uses grids (TDrawGrid and TStringGrid) previous to this patch, nobody reported this bug before I think because it didn't have any effect. But now people will find suddenly their grids doesn't have gridlines, the fix is just to change the value to 1 in object inspector and save the form. This have to be done anyway, so I applied the patch in revision 10961 and fixed the grid lines in lazarus sources in revision 10962 > This is not a full implementation but rather a quick cosmetic > implementation. The difference is that this patch changes the grid > line width for painting only, but not the actual offset or regions > of > the cells due to the change in Grid Line Width. No problem, it's the way it works currently. > Fixed columns > don't > draw the grid lines thicker than 1 (not sure if this is correct > behaviour). I don't think it is, I will try to fix it. > > At least with this patch you are now able to hide the grid lines > (GridLineWidth = 0) when required. This is the main feature I was > missing to get my custom component to work. I agree it does a better work than the current methods. > > In the Delphi implementation, the cell size will stay the same even > though the grid line width increases. Delphi does cause a very > strange effect (I think it's a bug) when the GridLineWidth is set > to a > negative values. I don't think Lazarus needs to copy that > behaviour > so the lowest value the GridLineWidth will go is 0 in the LCL. > I agree, we will have to change this so it becomes more delphi compatible anyway, but for the moment I think it's ok as is. > > > -- > Graeme Geldenhuys Thanks. Jesus Reyes A. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] [patch] - grids.pas (GridLineWidth)
Wouldn't it make more sense to have the GridLineWidth property default to 1 and show 1 in Object Inspector so it's Delphi compatible? I.e., GridLineWidth is not saved to form file unless a value other than 1 is entered. -Original Message- From: Jesus Reyes [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 3:00 PM To: lazarus@miraclec.com Subject: Re: [lazarus] [patch] - grids.pas (GridLineWidth) --- Graeme Geldenhuys <[EMAIL PROTECTED]> escribió: > Hi > > Attached is a patch for the TCustomGrid.GridLineWidth property. > Please > review before applying this patch. > Looks ok, the only problem I see is that, currently the property default for GridLineWidth is set to 1, but as grid doesn't set the GridLineWidth at creation it takes value 0, this value is stored in lfm file for every project that uses grids (TDrawGrid and TStringGrid) previous to this patch, nobody reported this bug before I think because it didn't have any effect. But now people will find suddenly their grids doesn't have gridlines, the fix is just to change the value to 1 in object inspector and save the form. This have to be done anyway, so I applied the patch in revision 10961 and fixed the grid lines in lazarus sources in revision 10962 > This is not a full implementation but rather a quick cosmetic > implementation. The difference is that this patch changes the grid > line width for painting only, but not the actual offset or regions > of > the cells due to the change in Grid Line Width. No problem, it's the way it works currently. > Fixed columns > don't > draw the grid lines thicker than 1 (not sure if this is correct > behaviour). I don't think it is, I will try to fix it. > > At least with this patch you are now able to hide the grid lines > (GridLineWidth = 0) when required. This is the main feature I was > missing to get my custom component to work. I agree it does a better work than the current methods. > > In the Delphi implementation, the cell size will stay the same even > though the grid line width increases. Delphi does cause a very > strange effect (I think it's a bug) when the GridLineWidth is set > to a > negative values. I don't think Lazarus needs to copy that > behaviour > so the lowest value the GridLineWidth will go is 0 in the LCL. > I agree, we will have to change this so it becomes more delphi compatible anyway, but for the moment I think it's ok as is. > > > -- > Graeme Geldenhuys Thanks. 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 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Graeme Geldenhuys wrote: > Well again, our porting of the Delphi/Kylix application took a turn > for the worse. I can send a few screenshots to show what it looks > like under Linux (not even close to what it should look like). Under > Windows it seems to be okay (for the most part). Putting some screenshots in the wiki for a group of related issues may be helpful: it shows a more concrete goal is reached than just simply implement/fix a couple of "random" bug reports. > Ah, enough of my ramblings If anybody read this far, I'm impressed. > :-) It would be unethical to ignore you ;-). Micha _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] [patch] - grids.pas (GridLineWidth)
--- "Hess, Philip J" <[EMAIL PROTECTED]> escribió: > Wouldn't it make more sense to have the GridLineWidth property > default to 1 and show 1 in Object Inspector so it's Delphi > compatible? I.e., GridLineWidth is not saved to form file unless a > value other than 1 is entered. > Yes, it should work like that. Previously no value was explicitly set in GridLineWidth so it was 0 in object inspector and that was a bug (unnoticed because this property was ignored) as result and because as GridLineWidth was declared as "default 1" the line "GridLineWidth = 0" was streamed into lfm file in all forms that have stringgrids or drawgrids, so now even when 1 is used correctly in grid constructor, the stored 0 overrides this at loading. for new projects nothing have to be done, for old projects one have to manually change the value from 0 to 1, if something is not working please report. 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
[lazarus] Lazarus gtk2 on windows
Hi, As of svn revision 10963 the gtk2 interface is working in windows. There are bugs. And also some more bugs. So for all you windowsers who would like to hack at the gtk2 interface feel free :) here's a pic of lazarus running on windows compiled for the gtk2 interface: http://hainesservice.net/andrew/lazarus/laz-gtk2-win32.png Andrew _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TCustomGrid not the same as Delphi
- Original Message - From: "Graeme Geldenhuys" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 1:22 AM Subject: Re: [lazarus] TCustomGrid not the same as Delphi On 4/17/07, Jesús Reyes A. <[EMAIL PROTECTED]> wrote: > In Delphi's TCustomGrid the DrawCell() method is 'virtual abstract', > but in Lazarus it is virtual. It's necesary to change it to virtual abstract?, I initially thought that it could be used for some standard drawing but eventually found it wasn't necesary. I wouldn't say it's necessary, it's just different to Delphi's VCL. Also anybody that created a custom component in Delphi - based on the TCustomGrid overrides the DrawCell() method and doesn't call inherited, because they expect the TCustomGrid.DrawCell to be abstract. That's what I thought. I did the same while porting my component, but luckily I had a peak at the TCustomGrid code and saw it DrawCell has some code, so called inherited in my component. I just think that code might get skipped, because developers are not used to calling inherited in TCustomGrid descendants. > I'm busy porting a custom component we created that was based on > TCustomGrid under Delphi 7 & Kylix 3 to Lazarus. As I mentioned the > DrawCell was abstract under Delphi, but yet it does painting under > Lazarus. Calling an abstract method doesn't sound right to me, but maybe it has some use, can you comment on the usefulness of this?. It's strange that delphi or Sorry, you miss understood me. I was only pointing out that the VCL has TCustomGrid.DrawCell defined as abstract and the LCL has it as virtual. Any developer used to using the VCL and TCustomGrid is not going to call inherited when they override the DrawCell method. Oh, I assumed to much, because you said that you was porting a component I thought that your component already included an inherited call. As delphi allows it I thought that was currently the case. I'm sorry for the confusion. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' 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
[lazarus] Plug-in functionality
Hi all, Since Lazarus does not support dynamically loaded DLL's, can anyone offer suggestions for creating a plug in functionality for a Windows/Linux application? Thanks a bunch, -- Warm Regards, Lee _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Delphi incompatibilities in TForm
Flávio Etrusco wrote: 2) Delphi Form has a Bitmap property which allows to set a background image on the form, while Lazarus does not. What version is it? I vaguely remember seeing this on a very recent version of Delphi (probably Turbo Delphi Explorer), but in Delphi7 there isn't any such property... Nor is there a property like that in D6. I've always had to use TImage and stretch it across the form the few times I needed this functionality. -- Warm Regards, Lee _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Plug-in functionality
Lee Jenkins schrieb: Hi all, Since Lazarus does not support dynamically loaded DLL's, can anyone offer suggestions for creating a plug in functionality for a Windows/Linux application? Why you think it dont support dynamically loaded dlls ? I work for years with them and fpc/lazarus... _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Plug-in functionality
Christian Ulrich wrote: Lee Jenkins schrieb: Hi all, Since Lazarus does not support dynamically loaded DLL's, can anyone offer suggestions for creating a plug in functionality for a Windows/Linux application? Why you think it dont support dynamically loaded dlls ? I work for years with them and fpc/lazarus... That may be my mistake then Christian. I thought I read that somewhere, I've never tried it. Nonetheless, that is good news. -- Warm Regards, Lee _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] [patch] - grids.pas (GridLineWidth)
Yes, that makes sense now. I had looked at one of my .lfm's that had been auto-converted from Delphi and it didn't have a GridLineWidth property. I see now that .lfm's saved by Laz do have a 0 value for GridLineWidth. -Original Message- From: Jesus Reyes [mailto:[EMAIL PROTECTED] Sent: Tue 4/17/2007 4:29 PM To: lazarus@miraclec.com Subject: RE: [lazarus] [patch] - grids.pas (GridLineWidth) --- "Hess, Philip J" <[EMAIL PROTECTED]> escribió: > Wouldn't it make more sense to have the GridLineWidth property > default to 1 and show 1 in Object Inspector so it's Delphi > compatible? I.e., GridLineWidth is not saved to form file unless a > value other than 1 is entered. > Yes, it should work like that. Previously no value was explicitly set in GridLineWidth so it was 0 in object inspector and that was a bug (unnoticed because this property was ignored) as result and because as GridLineWidth was declared as "default 1" the line "GridLineWidth = 0" was streamed into lfm file in all forms that have stringgrids or drawgrids, so now even when 1 is used correctly in grid constructor, the stored 0 overrides this at loading. for new projects nothing have to be done, for old projects one have to manually change the value from 0 to 1, if something is not working please report. Jesus Reyes A. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/ _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives <>
Re: [lazarus] Plug-in functionality
On 4/18/07, Lee Jenkins <[EMAIL PROTECTED]> wrote: That may be my mistake then Christian. I thought I read that somewhere, I've never tried it. Nonetheless, that is good news. What doesn´t work on Free Pascal is creating a dll that exports classes, like for example building the full fpc runtime library into a DLL. Exporting normal functions works ok. For a common software it´s almost always enouth to write a procedural interface, so that is what I recomend. I read something about this being solved or partially solved on 2.2 -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] [patch] - grids.pas (GridLineWidth)
Hi Philip Something off-topic that I noticed about you previous emails. I believe you are using MS Outlook for sending email. I highly recommend you change you default email format from the Microsoft proprietary TNEF (RichText) format to HTML or even better Plain Text. The TNEF format can only be read by MS Outlook, not even Outlook Express can read it. For all other mail clients, they will only see a WinMail.dat attachment and a blank message body. As the snippet below indicates. Here are some more info on the problem and instructions on how to change the settings in Outlook. http://www.dwheeler.com/essays/microsoft-outlook-tnef.html --_=_NextPart_001_01C78166.D78E1EA9 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiADAQaQCAAEAAABAAEAAQeQBgAI5AQAAADoAAEIgAcAGElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAgACAAEEgAEAMgAAAFJFOiBbbGF6YXJ1c10gW3Bh dGNoXSAtIGdyaWRzLnBhcyAoR3JpZExpbmVXaWR0aCkAChEBBYADAA4AAADXBwQAEQAXAAcADgAC ACEBASCAAwAO1wcEABEAFwAIAB4AAgAyAQEJgAEAIQAAADk2MzhCQzdDQTc3NjNFNDM4QUM0 OUZBRThDRkVCM0Q4AIkHAQOQBgB4DAAAOQMAJgAAAwA2AABAADkAWokYqmaBxwEe Regards, - Graeme - On 4/18/07, Hess, Philip J <[EMAIL PROTECTED]> wrote: Yes, that makes sense now. I had looked at one of my .lfm's that had been auto-converted from Delphi and it didn't have a GridLineWidth property. I see now that .lfm's saved by Laz do have a 0 value for GridLineWidth. -- Graeme Geldenhuys There's no place like S34° 03.168' E018° 49.342' _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
