¿funcion que devuelva mas de 1 valor?
 

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

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

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.

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,

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,

¿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

A ver...
La propuesta de Ñuño es equivalente a una función con un parámetro por referencia. Es decir que un parámetro este precedido por la cláusula var de modo tal que se permita la modificación de dicho valor por parte de la función.

Es decir algo como:

Código Delphi [-]
function Nombre(Param1: integer; var Param2: integer): integer;
begin
  result := ...
  Param2 := ...
end;

Cuando se pasa un parámetro por refencia, se permite que dentro del código se altere su valor por lo que al final de la función es posible que el valor sea diferente. Esta es una de las maneras en como una función puede devolver más de un resultado:
1) El resultado propiamente de la función:

Código Delphi [-]
res2 := 5;
res := Nombre(10,res2);

2) El 2do resultado que queda almacenado en el 2do parámetro (para el ejemplo en la variable res2 y ya no necesariamente el valor será 5 como inicialmente por tanto hay que comprobar su valor:

Código Delphi [-]
if res2 <> 5
   then ShowMessage('res2 ha cambiado por ' + IntToStr(res2));

Si hay más por regresar se pueden disponer de tantos parámetros "vars" como se requieran:

Código Delphi [-]
function Nombre(P1: integer; var P2, P3, .... PN: integer): integer;

Pero en lo posible hay que evitar esta técnica.

Como dije al comienzo de mi anterior mensaje, si el resultado de la función siempre será parecido a algo como:

Código Delphi [-]
resultadoFinal = resultado_constante + resultado_variable

Y siempre que resultado_constante sea un valor fijo y resultado_variable sea variable o que asuma el valor dependiendo del caso.

Entonces, si... la función puede regresar diferentes valores y sin necesidad de requerir añadir parámetros por referencias.

En este escenario ya pasa por el cliente de la función (en donde se la utilizará) el llevar el adecuado control de los resultados. Y esto se puede hacer fácilmente con el uso de constantes.

La segunda alternativa para regresar múltiples resultados es utilizando registros, y hacer que la función regrese uno:

Código Delphi [-]
type
TResultados = record
  Res1, Res2, Res3, ...., ResN: integer;
end;

function Nombre(Param1: integer): TResultados;

Pero como he dicho, en lo posible debe evitarse estos tipos de funciones ya que lleva a un acomplamiento empaquetado y condiciona a tanto la función como al cliente a tener un mayor acomplamiento y un cambio en la función llevará a un cambio en el cliente, y vaya a saber donde más.

Si no se entiende eso, entonces me pregunto de que otra manera debo explicarlo porque es de lo más simple y elemental. Me extraña que alguien que ya lleva más de 2000 mensajes y un buen tiempo en los foros no logre entender lo que he dicho anteriormente. Sabiendo que tu JXJ supuestamente eres un profesional, y que a la teoría y los conceptos de acoplamiento y cohesión te son más que estudiados ya que es una de las primeras cosas que se enseñan en la carrera.

Saludos,

Pues yo esto sí que no le entiendo nada. ¿Qué tiene que ver lo que esxpones con regresar más de un valor? Porque, se entiende que la pregunta de JXJ se refiere a más de un valor en una sóla llamada a la función. ¿O te refieres a que los múltiples valores serían la constante (un valor) y la otra parte (el otro valor)? Pero esto sería un poco bobo, así que no creo que sea eso.

No quisiera polemizar pero me parece que ésta es una ofensa gratuita.

// Saludos

A veces (más veces de las que quisiera) yo también cometo errores gordos de novato, y otras veces son cosas simples que se supone que lo sabe cualquiera y resulta que no lo sabía, en fin, que todos los día se aprende algo, aunque sea tan simple como las vocales***


*** Una vez me preguntaron ¿cuáles son las vocales?, y me quedé con la mente totalmente en blanco, al final contesté un tímido "uuummm... pues no sé, no recuerdo" :o
La persona que me preguntó se dirigió al público y dijo algo así como: "y aquí tenemos un caso claro de la incultura, el analfabetismo que nos rodea en todos los aspectos de la vida y hacen que esta sociedad sea tan retrógrada, paleta y casposa".
No me levanté para darle una patada donde más duele porque entonces habría añadido: "un caso claro de la bestialidad, salvajismo, brutalidad de la sociedad actual", así que me contuve, agaché la cabeza y esperé al final para salir escondido entre las sombras. :o:o:o


Edito: cuando salí a la calle me dije: "¿las vocales?, qué pregunta más tonta, a,e,i,o,u ¡en qué estaba yo pensando!"

yo en estos casos usaba un procedure

y variables globales. para hacerlo mas facil. con las prisas de entregar
proyecto en horas. pues. a codificar como loco, con que funcione..
y se entrege en los plazos que el cliente pide...


gracias muchachos por su atenta atencion.

:D