Hi All,
What is the portable equivalent of the Win32 GetCharABCWidths API call?

Would Canvas.TextWidth be enough?

Thanks,

Dominique.

Hi Dominique,

The portable equivalent is in LclIntf, but it's not implemented in all widgetsets. Last fall I was playing around with this function for Carbon. Not sure where I left it but here's what I came up with. Maybe you could implement it for non-win32 widgetsets.

Thanks.

function TCarbonWidgetSet.GetCharABCWidths(DC: HDC; p2, p3: UINT;
  const ABCStructs): Boolean;
type
  TABCArray = array[0..255] of TABC;
  PABCArray = ^TABCArray;
var
  ABCPtr   : PABCArray;
  CharNum  : Integer;
  CharStr  : string;
  CharSize : TSize;
begin
  ABCPtr := PABCArray(@ABCStructs);
  for CharNum := p2 to p3 do
    begin
    CharStr := Chr(CharNum);
    GetTextExtentPoint(DC, PChar(CharStr), 1, CharSize);
    ABCPtr^[CharNum-p2].abcA := 0;
    ABCPtr^[CharNum-p2].abcB := CharSize.cx;
    ABCPtr^[CharNum-p2].abcC := 0;
    end;
  Result := True;
end;

Hi Philip,
So am I right in saying that ABCStructs is available as a native lcl struct?

I mainly need this for Mac OS X for now, but will need it for Linux further down the line.

So use TCarbonWidgetSet what unit do I need to include and do you have a small example of using GetCharABCWidths in Mac OS X?

Thanks,

Dominique.

Dominique Louis wrote

So am I right in saying that ABCStructs is available as a native lcl struct?

Well, in my local copy I see that this function is only implemented for win32. Not even in wince it works. I am not 100% sure what it does, but if you can substitute that with other text measuring routines I think that would be the best solution.

Looking at the comments about it, it seams this was a hack in the past to allow the LCL to use this function on win32 and fallback to other text routines on other platforms, but now it's no longer used by LCL and should probably be removed.

LCLIntf is a small compatibility layer for things that where traditionally done by winapi under delphi, not a new wine.

Hi Dominique,

You would implement TCarbonWidgetset.GetCharABCWidths in carbonwinapi.inc. Then recompile carbon widgetset.

Then add LclIntf to your uses section. When you compile an app with the Carbon widgetset it will now use the implemented function.

ABCStructs is used in winapi.inc, etc. so yes, it's a standard LCL structure.

Two alternative strategies that do not involve modifying the Carbon widgetset:

(1) You could determine why you need this function and rewrite the code so that you don't need it anymore. I believe this is Felipe's suggestion, although this requires that you understand what the code is doing. If you're porting code, this may be more difficult than the next strategy...

(2) Add a function named GetCharABCWidths to your unit or to a general "Win API collection point" unit used by your units so that your code calls that function instead of the LclIntf function. (Be sure to put this unit in your uses _after_ LclIntf or Windows.) Then implement your function however you want so that it works in a general way without dependence on the underlying widgetset.

Using one of these strategies will also protect you in the event that this function is removed from LclIntf. Sudden changes frequently occur to the LCL so the less dependence on obscure Win API functions, the better.

In one of my projects I used strategy (2) above to implement about 50 Win API functions in a platform-independent way, primarily using existing LclIntf functions and RTL functions. This way I don't have to implement them on each widgetset or, what's probably even more difficult, persuade the Laz developers to add them to LclIntf and then support them.

Thanks.

-Phil

Philip J wrote

ABCStructs is used in winapi.inc, etc. so yes, it's a standard LCL structure.

I think that's going a bit too far. If it's a winapi not implemented anywhere except win32 I don't think it's a standard LCL structure.

There is a high probability this is a left over which should now be removed, specially if this can be accomplished with other more stablished APIs.