Si selecciono directorios funciona bien, pero cuando después de haber seleccionado alguno selecciono un enlace simbólico a un directorio que sólo tiene carpetas, al volver a seleccionar otro levanta un error en la línea 218 de "Objeto Nulo".

Ostras.. ( que dura es la vida del programador) Cuantas cosas hay que controlar.

La opción del Try resulta algo rara. Que probablemente muchos programadores la usen.
Como no levanta error ( debe ser que el jefe no lo controla al desarrollador).

Pero desde luego es para reñir al que lo hace. Yo sé, pongo la mano en el fuego..  , que vosotros no hacéis esas "maniobras".
(Pongo la mano pero con guante ignífugo).

¿ Qué te parece la solución de la bandera ?.  ¿ Es tan "así" como la de usar Try ?.
Al menos no se usa Try que resulta "churretoso".

Dudo que solucione el tema de los enlaces tal como esta. La vuelvo a subir.

Saludos

Archivos adjuntos

---

ClasificadorDeNombresDeArchivosPorExtensiones-0.0.6.tar.gz (Tamaño: 13.9 KB Descargas: 2)

Pero desde luego es para reñir al que lo hace. Yo sé, pongo la mano en el fuego..  , que vosotros no hacéis esas "maniobras".

Yo sí uso el Try en ocasiones. Por cuestiones de velocidad y ahorro de código.

Por ejemplo, con éste código:

Código:

if exist("mifichero.jpg") then
      PictureBox1.Picture = File.Load("mifichero.jpg")
endif

Tienes que comprobar si existe el fichero, es decir acceso al disco que te crió, y si es así cargarlo en el control... otro acceso al disco. Si no existe entonces no haces nada.
Pero ¿Qué ocurre si el fichero existe pero, a pesar de su nombre y extensión, no es una imagen válida? Pues que se generará otro error y entonces tendrías que añadir un

Código:

Catch
      If isnull(PictureBox1.Picture) then
           message.Error("El fichero no existe o es inválido")
     endif
end

Sin embargo, simplemente con

[code]

Problema resuelto. Si la imagen existe y es válida se cargará y se verá y si no... pues no se hace nada, que es lo que se pretendía.

Saludos.

Problema resuelto. Si la imagen existe y es válida se cargará y se verá y si no... pues no se hace nada, que es lo que se pretendía.

Muy bien explicado.

Try hace su función. Pero esa forma, ¿ es profesional ?.
Puede ser una solución fácil, o mejor dicho temporal o falta algo más de código.

- Has comprobado la existencia del archivo, lo has cargado. En caso contrario no hace nada.
- Luego lo has mejorado comprobando si el archivo no es valido. Informando de que hay un problema con este.

- Try ha hecho su trabajo, pero no se ha informado de que el archivo es invalido.

En este caso estamos tratando un archivo de imagen. Que puede ser invalido. Pero ahora imagina que estamos analizando
un directorio que contiene muchas imágenes y por lo que sea, algunos de estos están mal. Informar al usuario es un buen motivo.

Desde el punto de vista del usuario, quiere ver sus imágenes sin importar las peripecias que tenga que realizar el desarrollador para lograrlo.
Desde el punto de vista del desarrollador tiene que controlar distintas condiciones, algunas que ni puede imaginar que van a suceder.
 

"En la vida, nuestro primer trabajo es dividir y distinguir las cosas en dos categorías: las circunstancias externas
que no puedo controlar, y las decisiones que tomo con respecto a ellas y que tengo bajo mi control." Epicteto.

Saludos

Yo uso el Try para acelerar el desarrollo, pero generalmente termino sacándolo porque cuando el código es extenso y complejo, si el programa no funciona correctamente, pero no da error, 99/100 veces es un Try que ocultaba un mal funcionamiento.

Try hace su función. Pero esa forma, ¿ es profesional ?.

No lo es. Los que han tenido acceso a código profesional, como por ejemplo de Microsoft, recordaran las innumerables comprobaciones que hacen antes de ejecutar la tarea asignada. Sobre todo en acceso a archivos del disco.

Los que han tenido acceso a código profesional, como por ejemplo de Microsoft, recordaran las innumerables comprobaciones que hacen antes de ejecutar la tarea asignada. Sobre todo en acceso a archivos del disco.

Creo que Try es lo que da a entender la palabra "Probar, intentar"  y una vez estemos seguro de que funciona, eliminarlo.
Puede llegar a ser una forma de ocultar un error como dices. ¿ Y si luego ese error ocultado tiene consecuencias más adelante ?.

El Try es necesario y profesional. Es parte del lenguaje de gambas y es la única manera de verificar que una operación "con riesgo de fallar" (como cargar un archivo corrupto) ha sufrido un fallo.

De lo que habláis, supongo es de no verificar el error que se ha producido después del Try y eso está mal, o no, dependiendo de la finalidad de tu programa.
Siguiendo con el ejemplo de la imágenes (y esto es un caso real que enfrenté hace tiempo en el trabajo):
Haces una lista de archivos descargados vía ftp de un servidor y quieres poner el thumbnail de cada archivo bajado identificable según extensión, archivos que son de su padre y de su madre y que en su momento pueden haber sido bien cargados o abortados a media subida, o lo que sea.
Ahí haces tu función de thumbnails y en ella cargas la imagen. Si falla puede ser por múltiples causas que en este momento no te interesan. No puedes detener el programa con aviso sobre aviso de cada archivo ni plantear al usuario una serie de problemas que él no entiende (¿Qué es eso de archivo corrupto o incompleto?) y que te generarán incontables llamadas y quejas (o peor aún, que generarán en los usuarios la tendencia a no hacer caso de ningún aviso). Le pones un try al thumbnail y punto.

No hay que olvidar nunca al usuario. Eso de hacer programas para nosotros mismos está bien, pero el entorno profesional es otra cosa.

Saludos