>This is OK, apart from the fact that, wherever I use the function, I need to
>include in the interface uses statement the unit name where the type is
>declared.
>So I tried to get rid of the type definition and use directly the "array of
>integer" like this:
>        function GetValues: array of integer;
>but this is not accepted. So, this is the question: Is there a way ? Is
>there another way to get back an array of values from a function  ?

> Then I use the type as a return type in a number of functions in several
> units, like this:
>     function GetValues: TMyArray;
>     ........
> and I use the function:     MyArrayValues:= GetValues;   where  MyArray is
> of type TMyArray.

> This is OK, apart from the fact that, wherever I use the function, I need
to
> include in the interface uses statement the unit name where the type is
> declared.
> So I tried to get rid of the type definition and use directly the "array
of
> integer" like this:
>         function GetValues: array of integer;
> but this is not accepted. So, this is the question: Is there a way ? Is
> there another way to get back an array of values from a function  ?

> Stark <starkwed...@virgilio.it> wrote in message
> news:LFon9.6453$Fz.186107@news1.tin.it...
> > I am declaring a dynamic array as a type:
> > Type
> >   TMyArray = array of integer;

> > Then I use the type as a return type in a number of functions in several
> > units, like this:
> >     function GetValues: TMyArray;
> >     ........
> > and I use the function:     MyArrayValues:= GetValues;   where  MyArray
is
> > of type TMyArray.

> > This is OK, apart from the fact that, wherever I use the function, I
need
> to
> > include in the interface uses statement the unit name where the type is
> > declared.
> > So I tried to get rid of the type definition and use directly the "array
> of
> > integer" like this:
> >         function GetValues: array of integer;
> > but this is not accepted. So, this is the question: Is there a way ? Is
> > there another way to get back an array of values from a function  ?

> You can pass dynamic arrays as open array parameters (the declaration is,
> confusingly enough,  the same).
> If you only intend to write to the array I would use the out modifier
rather
> than var like so.........

> procedure GetValues(out Data: array of integer);

> And call it like so.........

> GetValues(MyArrayValues);

> You can use the High and Low functions within the procedure, but you can't
> change the array's length with SetLength.

> Dave

>>This is OK, apart from the fact that, wherever I use the function, I need to
>>include in the interface uses statement the unit name where the type is
>>declared.

> You can declare the type in the same unit which exports the function.

> If exactly the same type is required to propagate the result to other
> procedures, then you should collect all common type declarations in one
> dedicated unit, or in a unit which is commonly used in your project.

>>>This is OK, apart from the fact that, wherever I use the function, I need to
>>>include in the interface uses statement the unit name where the type is
>>>declared.

>> You can declare the type in the same unit which exports the function.

>> If exactly the same type is required to propagate the result to other
>> procedures, then you should collect all common type declarations in one
>> dedicated unit, or in a unit which is commonly used in your project.

>Or, if you want to keep certain things separate, use an include file.

>>In article <20021005191613.09330.00001...@mb-bd.aol.com>, VBDis wrote:
>>> Im Artikel <LFon9.6453$Fz.186...@news1.tin.it>, "Stark"
>>><starkwed...@virgilio.it> schreibt:

>>>>This is OK, apart from the fact that, wherever I use the function, I need to
>>>>include in the interface uses statement the unit name where the type is
>>>>declared.

>>> You can declare the type in the same unit which exports the function.

>>> If exactly the same type is required to propagate the result to other
>>> procedures, then you should collect all common type declarations in one
>>> dedicated unit, or in a unit which is commonly used in your project.

>>Or, if you want to keep certain things separate, use an include file.

> That probably won't work.  TMyType declared in one unit isn't the same
> as TMyType declared in some other unit.  If you do it with include
> files, you'll get two (or more) different types with the same name.

>I thought it doesn't matter for basic types (type aliases).

>But I took it as in two different programs (sharing code), not two
>program-parts sharing code.