Support Oracle ftNumber type

[Liang]

Hello

Is it possible for TDBChart to support a DataSet who hold fields in type of ftNumber returned by Oracle?

Currently all these fields are treated as text, so it is not possible to draw series unless I need to manually cast hundreds of ftNumber fields into ftFloat or ftLargeInt.

is there any simple or trick I can play to automatically treat ftNumber type as ftFloat or ftLargeInt?

[Narcís]

Hi Liang,

Is it possible for TDBChart to support a DataSet who hold fields in type of ftNumber returned by Oracle?

Currently all these fields are treated as text, so it is not possible to draw series unless I need to manually cast hundreds of ftNumber fields into ftFloat or ftLargeInt.

I have added your request to the wish-list to be considered for inclusion in future releases.

is there any simple or trick I can play to automatically treat ftNumber type as ftFloat or ftLargeInt?

The only solution I can think of is manually readying your dataset and populating TeeChart series using existing methods: Add, AddXY, AddArray, etc. Obviously, at some stage you'll have to convert a text type to a numeric type.

[Liang]

Hello

I have modified the source code for supporting Oracle NUMBER type as following:

In Chart.pas

Code: Select all

Function TeeFieldType(AType:TFieldType):TTeeFieldType;
begin
  Case AType of
    {$IFDEF CLR}TFieldType.{$ENDIF}ftAutoInc,
    // etc. etc 
  else
    begin
      if Integer(AType)=107 then // this is Oracle Number type, cast to integer. During the implementation, 
      // the Oracle-supporing dataset component will use its own ->AsFloat to convert it to a float type for charting
      begin
        Result:=tftNumber;
      end
      else
        result:=tftNone;
    end
  end;
end;

It works fine. Please kindly check it. I would like to contribute them to you.

[Narcís]

Hello Liang,

As you can see here, TFieldType's maximum value is 51 so it doesn't make much sense to use casting AType to 107. Where did you got that from? Is there any Oracle test database or a trial version we can use to test this here?

Thanks in advance.

[Liang]

Hello

I am using Devart's ODAC for Oracle database access.

And they have especially uses 107 to represent OracleNumber type.

So I guess that there may be of some standard on using 107 as Integer number to represent OracleNumber for data inter-changing?

[Narcís]

Hi Liang,

Thanks for the info.

People at Devart already admitted they are doing it the wrong way

http://www.devart.com/forums/viewtopic. ... tfieldtype

We don't think we should modify our source for such specific circumstances moreover considering that Deavart may fix this issue.

We have added an internal procedure, as a public variable in DBChart, which you can use to define your own codes, for example:

Code: Select all

procedure MyFieldType(const AType:TFieldType; var TeeType:TTeeFieldType);
begin
  if Ord(AType)=107 then TeeType:=tftNumber;
end;

...
TeeOnGetFieldType:=MyFieldType;
...

[Liang]

Hello

If I understand it correctly, your mentioned "variable" is an event procedure, which will be fired on Checking the fieldType?

If so, would you please kindly directly declare it as an event:

OnGetFieldType=procedure(const ASource:TComponent; const AType:TFieldType;var TeeType:TTeeFieldType) of object;

So user can just click the event and put his own code in for overridding the result?

[Narcís]

Hello Liang,

What you request is only used in the editors and is global for all TDBChart and TDBTree successors. We think it's too specific for being an event, we think an event should be used for notifying rather than for "collect" variables. Moreover, this is only necessary to be able to deal with Devart's implementation which omitted standard TFieldType.

You could create your own chart class inheriting from TDBChart and implementing it as you wish. Object oriented programming essence is overriding objects!

So user can just click the event and put his own code in for overridding the result?

Does this mean you are exposing TeeChart API to your end-users? If so please contact our Sales Dept. at sales at steema dot com explaining your applications nature.

Thanks in advance.

[Liang]

Hello

I do not suggest Oracle support only in the editors but a general support.

Considering the fact that 107 is DevArt's specific, maybe other Oracle component has other value, so for a wider range support, regardless what actual Oracle component user is using, I think expose this event out is more user friendly for easier handling as following

1. User clicked the event
2. And override the result based on his specific Oracle-supported components as

Code: Select all

void __fastcall TFrorm1::DBChart1OnGetFieldType(TObject *Sender,TComponent *ASource, TFieldType *AType, TTeeFieldType &TeeType)
{
   if ((Integer)AType==[107 or other value, which is whatsoever component's specific to represents its Oracle Number type])
  {
    TeeType=tftNumber; //<--- user override result here
  };
}

So, I am not request to expose TeeChart API out to end-user, but would rather have this event expose to software developers.

Your suggest to use a global variable of course also works, but coding is a little more complicated for a C++ user.

[Narcís]

Hello Liang,

We think this is just necessary because of a sub-par implementation of one specific component ignoring the standards of the environment it is designed for. If we find that it is necessary in other circumstances we might consider implementing the event. However, probably this is the first similar case we found during the 15 years of life of TeeChart VCL. Moreover Devart team stated they are looking for a solution to the issue so that feature wouldn't be necessary either.