In upgrading to Lazarus 1.1 and issue I first came across in this thread has returned. I think I decided not to use the controls in 0.9.31 but I want to consider them again in Lazarus 1.1,
http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-August/065582.html .

There is also a mantis issue for it -
http://bugs.freepascal.org/view.php?id=8328.

In 0.9.30 it is defined in lclintf.h as

function Frame3d(DC: HDC; var ARect: TRect; const FrameWidth : integer;
const Style : TGraphicsBevelCut): Boolean; {$IFDEF
IF_BASE_MEMBER}virtual;{$ENDIF} and is also in the Graphics unit as
procedure Frame3d(var ARect: TRect; const FrameWidth: integer; const Style:
TGraphicsBevelCut); virtual;

The control I am working with, TJanPanelButton uses the signature in lclintfh.inc calling it as Frame3d( Self.Canvas.Handle, R, FFrameWidth, bvRaised );

Juha Mahinnen added a patch to Extctrls to match the Delphi implementation here - http://docwiki.embarcadero.com/Libraries/en/Vcl.ExtCtrls.Frame3D. Although it matches the Delphi definition is it in the wrong place as it affects the apparently original Lazarus implementation?

In the mean time I have to ifdef it and call Self.Canvas.Frame3D(R, FFrameWidth, bvRaised ) instead of Frame3d( Self.Canvas.Handle, R, FFrameWidth, bvRaised ) which matches the definition of TCanvas in Graphics. Is that any good?

    ;

If you want to use
Frame3d(DC: HDC; var ARect: TRect; const FrameWidth : integer; const Style : TGraphicsBevelCut): Boolean
then you must add LCLIntf to your uses clause, and even qualify it: LCLIntf.Frame3D(R, FFrameWidth, bvRaised).

Stephano

I am not sure if I understand the problem. Is there an ambiguity between this :

  Frame3d( Self.Canvas.Handle, R, FFrameWidth, bvRaised );

and this :

  Self.Canvas.Frame3D(R, FFrameWidth, bvRaised );

Regards
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120501/fe2633ec/attachment.html>

I think he wants to use
LCLIntf.Frame3d(DC: HDC; var ARect: TRect; const FrameWidth : integer; const Style : TGraphicsBevelCut): Boolean

In that case, he must add LCLIntf to his uses clause.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120501/eac90788/attachment.html>

Both LCLIntf and Extctrls are already declared in the uses clause, but it appears that definining the new Frame3D procedure in ExtCtrls overrides the definition in LCLIntf, so it raises the question of whether the new Frame3D definition should be in another unit in order not to override the other definition.

Which frame3d in ExtCtrls is hiding LCLIntf.frame3d?

In any case, you can qualify it by using LCLIntf.frame3d(...)

Stepahno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120501/85afec7c/attachment-0001.html>

Yes, LCLIntf must be added to uses clause but still there is no ambiguity and thus no danger of calling a wrong function by accident. They all have different parameter signatures.
I still don't quite understand the original problem.

Global in ExtCtrls :

  procedure Frame3D(ACanvas: TCanvas; var ARect: TRect; TopColor,
BottomColor: TColor; const FrameWidth: integer);

Global in LCLIntf :

  function Frame3d(DC: HDC; var ARect: TRect; const FrameWidth : integer;
const Style : TGraphicsBevelCut): Boolean;

TCanvas (2 overloaded versions) :

  procedure TCanvas.Frame3d(var ARect: TRect; const FrameWidth : integer;
const Style : TGraphicsBevelCut);
  procedure TCanvas.Frame3D(var ARect: TRect; TopColor, BottomColor: TColor;
  const FrameWidth: integer);

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120501/8507b4f8/attachment.html>