¿funcion que devuelva mas de 1 valor?

[JXJ]

las funciones solo devuelven 1 valor.

es posible hacer ua funcion que devuelva mas de 1 valor

por ejemplo

yo llamo a una funcion llamada

Código Delphi [-]
function procesararchivo(pathyarchname:string; accionenelarchivo:String):String;
begin
 
  result:='archivo procesado'
end
 
pero si prefiero que me devuelva mas de 1 valor
 
function procesararchivo(pathyarchname:string; accionenelarchivo:String):String;
begin
 
   //aqui me invento el result quieor 2 valores si todo salio bien
   result: 'archivo procesado' + 'todosalio bien'
 
   // si hubor erro  result: 'archivo no procesado' +  no existe'
end

encontrre esto en php
de un array.

pero como declaro ese tipo de result
como declaro un array en delphi como resultado de una funcion?
http://www.superhosting.cl/manuales/...e-valores.html

[[Caral]]

Hola
Perdona pero no entiendo.
Lo poco que se de funciones es que en base a una operacion dan un resultado.
Esta operacion contiene parametros los cuales son declarados o bien al inicio o dentro de la misma funcion.
En el caso de estas funciones que muestras no contienen nada.
Lo mas seguro es que no lo entienda, por eso mejor pregunto.
Saludos

[ecfisa]

Hola JXJ.

El mismo tema se trato en este hilo, me acuerdo por que cuando leí el título pensé inmediatamente en devolver un registro.(que fué una de las propuestas que ya habían contestado).

Un saludo.

[[Delphius]]

Hola,
A ver... si la idea es que el resultado en realidad sea un "algo más otros" la función en realidad, técnicamente, SI está regresando varios valores... en cierto modo.
Pongamos por ejemplo que sea algo como:

Código Delphi [-]
const
OK = 0;
RESULT_OK1 = 1;
RESULT_OK2 = 2;
...
RESULT_OKN = N;

RESULT_NOT_OK = -1;
...

Si se diseña la función para regresar siempre un resultado que sea:

Código Delphi [-]
result := OK + LaConstante

Entonces podría decirse que si, la función estará regresando diferentes valores. El problema pasa aquí no por el lado de la función, sino del cliente que la utilizará. Es YA UNA RESPONSABILIDAD DE ÉSTE de procesar ese resultado variante. La manera más fácil y elemental de dar respuesta es disponer de un CASE:

Código Delphi [-]
res := LlamandoAFuncion(...);
case res of
RESULT_OK1: ...
...
RESULT_OKN: ...
else ...
end;

Esta técnica, o algunas variantes menores, es utilizada en algunas bibliotecas. El concepto y la aplicación se sustenta en el uso de constantes, un resulto muy útil y pasado por alto.

Otra posibilidad que también puede considerarse como se señala en el hilo recomendado ecfisa es el uso de parámetros "var".

Es decir:

function NombreFuncion(Param1, tipo; ... ; var ParamResult: tipo);
begin
....
end;

Y dentro del cuerpo de la función alterar el valor de ParamResult por el adecuado.

Noten como ambos esquemas son posibles, es más yo sugeriría que los valores que devuelva ParamResult estén definidos como constantes:

Código Delphi [-]
res := NombreFuncion(...,res_out);
case res_out of:
....

Uno de los peores males y diseños que deben evitarse es que una función regrese un array. Incluso, en lo posible debe de evitarse regresar una estructura como ser un record, o que esté formado por un conjunto de datos simples. Esto hace que existe un acoplamiento de estampado, que si bien manejado no es maligno debe repensarse su utilización.

Además este acoplamiento se sugiere, y se lo utiliza de forma inversa. Es decir el módulo cliente o coordinador es quien le pasa como parámetro a otro módulo la estructura que requiere.
La idea que la función le regrese al cliente o coordinador dicha estructura es un esquema un tanto fuera de lo normal, a pesar de que pueden aceptarse casos como éste.

Hay dos peligros de este acoplamiento:
información Innecesaria: pueden darse casos en que no toda la información de dicha estructura se utilice por tanto se malgasta "espacio" o se pierde utilidad, y termina obscureciendo su uso.
bundling o empaquetamiento artificial: que se terminen empaquetando en una estructura de datos información no relacionada con la idea de reutilizarla en otros módulos y ganar "espacio" en los parámetros. Por ejemplo:

Código Delphi [-]
TInfoVentasRecibo: record
NroFactura: integer;
NroRecibo: integer;
DetalleFactura: array[0..MAX_FACTURAS] of TFactura;
DetalleRecibo: array[0..MAX_RECIBOS] of TRecibo;
end;

En el ejemplo se ha intentado "empaquetar" tanto la información sobre las Facturas y Recibos en una sola cosa pensando que sería una gran idea tenerlas juntas porque en dos o tres lugares se requiere de ambas. ¿Porqué no mejor separar Facturas de Recibos?

¿Se ve mejor el peligro de este acomplamiento? El acoplamiento por medio de parametros por referencia/valor de datos simples es más fácil de mantener, limpio y sano que este empaquetado.

En lo posible hay que llegar al acoplamiento de datos o al de Control (cuando un parámetro se utiliza para controlar la lógica interna).

Saludos,

[[Delphius]]

Es más el tema del acoplamiento de control puede llevarse desde el módulo coordinador (cliente) como del subordinado. Es decir pueden esperarse ambas direcciones del parámetro de control:

1. Que el subordinado reciba el control, o bien
2. Que el subordinado sea quien notifique del control a aplicar

Para el caso 1, el parámetro de control regula la lógica interna:

Código Delphi [-]
function Nombre(Param1: tipo; ParamControl: tipo): tipo;
begin
 // aqui los controles y evaluaciones sobre ParamControl
end;

Para el caso 2, se requiere de "var":

Código Delphi [-]
function Nombre(Param1: tipo; var Control: tipo): tipo;
begin
  // aqui el algoritmo y las modificaciones a Control
end;

El caso 2 como ya debe haber quedado claro se emplea cuando el subordinado debe notificar de algo "extra" o que sea a modo de control, o de cambio de "estado" al coordinador. Luego queda en el coordinar lleva a cabo lo necesario y en su responsabilidad de que hacer con él.

Un caso aún aceptable de acoplamiento es un híbrido: una combinación del acoplamiento de datos más de control. Pero también debe evitarse.

De hecho la escala de acoplamiento sugerida de mantener es:

1) Acoplamiento de datos
2) Acoplamiento estampado
3) Acoplamiento de control
4) Acoplamiento Híbrido
5) Acoplamiento Común
6) Acoplamiento por Contenido (o Patológico)

Siendo 1 es más deseable y 6 el menos deseable.

El punto y a lo que voy es que se debería pensar bien objetivamente que es lo que se pretende de esto. ¿Cuál es verdadero objetivo y lo que motiva a que una función deba regresar varios resultados? ¿Se debe hacer algo en función de esos resultados? ¿Esos resultados son utilizados para alguna situación diferente o a un tratamiento diferente?

Responder a esas preguntas puede ayudar a determinar si en verdad el diseño que se estaba pensando es el más adecuado.

Saludos,

[[Delphius]]

¿Y... a todo esto, como ha quedado? Parece que ha JXJ le cortaron las manos porque se lo ha visto por aquí y no ha comentado al respecto.

Saludos,

[JXJ]

Empezado por Delphius

¿Y... a todo esto, como ha quedado? Parece que ha JXJ le cortaron las manos porque se lo ha visto por aquí y no ha comentado al respecto.

Saludos,

pues no entendi muy bien.. pero me gusta como se ve la funcion de

Ñuño Martínez
http://www.clubdelphi.com/foros/show...cion+resultado

Código Delphi [-]
FUNCTION Funcion (CONST Entrada: STRING; OUT Salida: STRING): BOOLEAN;
BEGIN  
  Salida := '';  
  RESULT := FALSE;  
  IF Entrada <> '' THEN Salida := 'Hay entrada';  
  RESULT := Length (Entrada) > 5;
END;

namas no entiendo como la llamo o como recibo el result mas el otro valor de
retorno.

procedure recibe2valores;

begin

if Funcion ('valor de entrada', ) = True
then
begin

end
else
begin

end
end