Writing InterBase UDFs in Delphi
I wrote an article on creating InterBase User-Defined Functions in Delphi eons ago, and in it I suggest using the IBX declarations of the IB API calls when you need them. Since then, IBX has undergone internal changes to allow it to use some new features of IB, so the suggested syntax requires some revision. Instead of calling IB API calls as unqualified "simple" methods, the API calls are now part of an interface, and you need to get a reference to the interface before using them. The general syntax is:
uses
IBHeader, IBIntf;
// […]
var
GDSLib: IGDSLibrary;
begin
GDSLib := GetGDSLibrary;
GDSLib.CheckIBLoaded;
GDSLib.isc_do_something;
end;Share This | Email this page to a friend
Posted by Craig Stuntz on October 16th, 2007 under Delphi, InterBase |8 Responses to “Writing InterBase UDFs in Delphi”
Leave a Comment
Server Response from: dnrh1.codegear.com
RSS Feed
January 11th, 2008 at 2:05 pm
Craig,
Thank you for tips in your articles …
I need to make a UDF receive an integer and make the conversion to the same pchar. Ex:
function fn_IntToStr( var Codigo: Integer; szRes: PChar ): PChar; cdecl;
begin
??????????????
end;
You can help me, please?
January 11th, 2008 at 2:08 pm
Why? IB can already convert an Integer to a VARCHAR just by CASTing it.
January 11th, 2008 at 2:12 pm
But my UDF, in fact, will add zeros in the string:
function StrZero( var Value, Size: Integer; szRes: PChar ): PChar; cdecl;
begin
??????????????
end;
Thank you for your attention.
January 11th, 2008 at 2:17 pm
Er, OK, but you can still do that in a proc.
To do this, I’d probably use the WinAPI function wvsprintf, which knows how to prefix an integer with zeros in order to fill a fixed width.
Use ib_malloc / FREE_IT to create the buffer, then pass a format string containing the 0 command and the width, the buffer you just created, and the integer argument to wvsprintf to format the output.
Free the allocation by declaring the UDF with FREE_IT.
January 11th, 2008 at 2:31 pm
Craig,
This is the function that I use today, I would like to optimize, leaving to use, if possible, the function SysUtils.IntToStr.
function StrZero( var Code, SizeRes: Integer; szRes: PChar ): PChar; cdecl;
var SizeCode, ZeroNumber, i: Integer;
StrCode: string;
begin
Result := szRes;
StrCode := SysUtils.IntToStr( Code );
SizeCode := System.Length( StrCode );
ZeroNumber := SizeRes - SizeCode;
for i := 1 to ZeroNumber do begin
szRes^ := ‘0′;
Inc( szRes );
end;
for i := 1 to SizeCode do begin
szRes^ := StrCode[i];
Inc( szRes );
end;
szRes := #0;
end;
January 11th, 2008 at 2:36 pm
OK, enough. If you want my help, please spell out /exactly/ which problem you are trying to solve instead of trickling out a little bit more information with each comment you post.
What problem are you trying to solve?
January 11th, 2008 at 4:24 pm
It is not exactly a problem, but optimization of code. In my current code I create a variable of type string (StrCode), which receives the result of the conversion by the IntToStr function. Then I still have to call the function Length to verify the size of the generated string.
From what I could see in their examples, the ideal is to work directly with the pointers of variables allocated by Interbase, and I have managed to do that in my various other UDFs, which receive a PChar as parameter. But in the case of this function in particular, it receives a Integer, I could not find a way to read (converting or not) the parameter Integer received by function to concatenate with the number of zeros needed to return the size requested in SizeRes parameter.
Thank you very much for the attention you are giving to my problem, I tried to explain as best I could.
January 11th, 2008 at 4:32 pm
I doubt your current code is particularly slow. Especially in comparison to DB access.
Trying to change a routine from code which you *do* understand, which appears to work, and which doesn’t have a demonstrated performance problem to code which you don’t understand in order to "optimize" something which has never been shown to be a problem in the first place is premature optimization, and shouldn’t be done.