FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
parámetros en funciones RGB y HSL
Hola a todos!
Hace un tiempito abrí un hilo para averiguar cómo pasar de RGB a HSL. Entre el código que Jachguate y Seoane me han facilitado tengo una duda con parámetros.. en la siguiente línea: Código Delphi [-] function HSLtoRGB (H, S, L: double): TColor; entiendo que "le doy" a la función los parámetros H,S,L de tipo double y me "devuelve" un TColor. ahora bien, en la línea: Código Delphi [-] procedure RGBtoHSL (RGB: TColor; var H, S, L : double); tengo las sig. preguntas: 1) veo que es un procedimiento, y como tal, no devuelve ningún resultado, entonces ¿como hace el procedimiento para darme los valores HSL? 2) ¿por qué figuran los valores HSL en la lista de parámetros si tendrían que ser el resultado? 3) ¿cómo hago para llamar correctamente a la función? digamos, por ejemplo que querría saber un HSL para un RGB=0,0,255 No puse tanto código para que sea más simple la lectura. Desde ya muchas, gracias. Norum |
#2
|
||||
|
||||
Hola Norum,
Fíjate que en los parámetros H, S, y L están después del var. Ese valor indica que dichos parámetros se pasan del tipo valor. Esto quiere decir que la variable que suministre en cualquiera de esos parámetros puede ser modificada dentro del procedimiento. Te lo explico con un ejemplo: Cuando tu haces: procedure SeleccionarOperacion(Operacion: integer); begin ... end; El valor de operación permanecerá fijo. Podrá ser modificado dentro del cuerpo del procedimiento, pero una vez que termine el valor de Operación seguirá siendo el mismo. Es decir que si pasas el valor 5, seguirá siendo 5. Mientras que si haces:
el valor al finalizar se modificó. Por tanto, si pasas el valor 5, cuando finalize podrá valer 1, 70, 100, etc... Por tanto cuando llames a RGBtoHSL, deberás suministrar variables en dichos parámetros. Una vez que finaliza el procedimiento, en H, S y L quedará el valor correspondiente. Con respecto a tu otra duda, lee sobre las funciones GetRValue, GetBValue, GetGValue. RGBToColor, ColorToRGB, entre otras. Saludos, |
#3
|
|||
|
|||
Gracias Delphius!
Antes que nada me quería disculpar porque el mensaje anterior no salió muy prolijo. Lo encerré en las etiquetas pero en mi pantalla se vé mal, no me sale el recuadro para el código. Si estoy haciendo algo mal por favor avísenme. Estuve leyendo de la ayuda qué son los parámetros por valor(por defecto) y por referencia (con la palabra "var"). Más o menos lo entendí. Así que con mi duda anterior lo que hice fue declarar en mi unidad principal variables "H, S, L" y inicializadas en cero en la parte de interface para que las funciones en otra unidad las puedan ver y modificar. A la hora de pasar parámetros los pasé normalmente y funcionó todo. Me queda duda si lo hice bien o por ahí el código me quedó medio ineficiente, ya que lo que a uno "le parece" no siempre es lo "adecuado". Saludos y gracias de Nuevo, Norum. |
#4
|
||||
|
||||
Cita:
Cita:
El problema de tener esas variables globales es que puede caerse en el riesgo de mostrarlas a quienes no necesitan saber. Por lo general se sigue este principio: Quien tiene la obligación de modificar el valor es el propio objeto (o unit, según sea el caso) que posee la información para ello. ¿Que significa esto? Que se espera que la propia Unit u Objeto sea quien tiene la facultad de modificar el valor, mientras que el resto de las Units deberían leerlo. Es un grave peligro dejar la posibilidad de que otras Units tengan la habilidad de modifar algo que no les pertenece, podría llevar a la inconsistencia de información (otra Unit espera un valor determinado, pero al leer recibe otro). Pero también existen casos en que no hay manera de que funcione este principio. En ocasiones es necesario contar con las variables globales. En pocas, no puedo decirte si haz hecho bien al seguir ese camino o no. Tu mismo deberás darte cuenta si a la larga (o al mediano plazo) continuar este enfoque es productivo. Además, al no tener acceso a tu código poco puedo opinar. En la poca experiencia que tengo, yo me dije que si hay dudas es probable de que el diseño sea débil y por tanto el código es débil. Seguir un plan de trabajo asistido por casos de pruebas es una buena ayuda. Yo, al menos no continuo con otra cosa hasta no sentirme más seguro. Como tu mismo dijiste, cada uno tiene una mirada del análisis. Pero no por ello podemos decir que estés errado. Saludos, |
#5
|
|||
|
|||
Hola Delphius!
Vayamos por partes.... Con respecto al formato para que quede el código encuadrado, lo hice con el boton de "resaltar sintaxis de delphi", ahora lo raro es que en la vista preliminar se veía bien como debería ser, ahora en la versión final salió lo que salió, medio desparejo. Voy a ver en la próxima a ver cómo sale. Con respecto a la Cara Oculta, lo estuve leyendo, me parece un librazo, pero justamente no es para novatos, Ian Marteens lo explica al principio. Si bien pude seguirlo un poco al principio y el libro tiene un tono ameno y divertido, que me ha hecho reir más de una vez (supongo que a otro le ha pasado lo mismo), después se torna más complejo. Voy a ver de nuevo donde trata el tema de parámetros por valor y por referencia. Muy buena esa frase Cita:
Por último, voy a seguir adelante porque creo que esto no tiene mucha vuelta que darle. Si se llega a complicar con más unidades (cosa que no creo), voy a investigar más a fondo este tema de no dejar variables "muy al descubierto". Gracias de nuevo y van 3! Norum |
#6
|
||||
|
||||
Cita:
Cita:
A ver... el asunto de valor o referencia no es tan complicado. Cometí un error en el mensaje anterior. Veamos de nuevo.
Cuando los parámetros se pasan por valor, el compilador lo que hace es copiar el VALOR que contiene la variable Algo. Por lo que dicha variable no se ve alterada dentro del procedimiento. En cambio, cuando se pasa por referencia, el compilador suministra el "puntero" de dicha variable, y con esto se conseguie que la variable Algo pueda alterar su valor. Supongamos que tienes una variable MiAlgo y se hace esto:
Pero en cambio si haces:
Es decir que cuando se procede por referencia se está pidiendo que se trabaje con dicha variable y no una copia. Es por ello que una vez que finalizas este procedimiento debes chequear el valor que contiene MiAlgo. Se debe usar MiAlgo cuando tenga sentido esperar un cambio en alguna variable. O incluso cuando se desea obtener más de un valor. Te voy a poner un ejemplo, extremo, de un mal uso del var:
Lo que tenga la variable Suma será cambiado por la operación que se realice. En este caso la suma de A y B. ¿Es útil tener esto? La respuesta es no. Bastaría con tener una función:
Pero en cambio, es útil el valor de var cuando se desea crear variables de control de operación (o variables de estado). Por ejemplo puede ser útil esto:
Y asi como tenemos un procedimiento, podemos tener una función. Cita:
Saludos, |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Establecer parametros determinados en funciones y procedimientos | emeceuy | Varios | 8 | 03-09-2007 20:23:50 |
Parametros Opcionales no Parametros por defecto | Velia | Varios | 7 | 19-08-2006 16:18:42 |
Funciones por parametros... | omar_e_rc | Varios | 2 | 28-03-2005 00:12:27 |
Funciones y parámetros Fast Report | sur-se | Impresión | 1 | 18-08-2004 13:38:44 |
Enviar estructuras como parametros a funciones Oracle | SLAKE | Conexión con bases de datos | 0 | 02-10-2003 18:14:05 |
|