FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Sobre cierto resultado de la función SHGetSpecialFolderPath
Hola,
A raíz de este hilo me he propuesto realizar una sencilla clase que cuenta solo con un método cuyo cometido es devolver la ruta de un directorio "especial" de Windows determinado, como puedan ser los directorios "Mis documentos", "Mi música", etcétera. Para ello, principalmente, hago uso de la función del API de Windows "SHGetSpecialFolderPath" (más información sobre ella en el hilo citado arriba). Es el caso que prácticamente he concluído dicha sencilla clase (o al menos me lo creo) pero encuentro un problema con el resultado de la referida función: este es... cómo lo diría... incorrecto, en cierto modo. No el esperado en cualquier caso. Por ejemplo, si primero trato de hallar la ruta de un directorio y acto seguido compruebo la existencia del mismo el resultado es correcto, puesto que, efectivamante, el directorio cuya existencia se comprueba existe: así me lo indica la función "DirectoryExists" que utilizo para tal fin. Sin embargo, si lo que pretendo es añadir a la ruta del directorio obtenido alguna cadena,... aun cuando realizo la concatenación de la ruta y la cadena y el compilador no se queja de nada lo que obtengo al cabo es la ruta del directorio, pero sin la cadena unida a la misma. Supóngase que quiere crearse un directorio en donde está instalado Windows. Entonces pretendo hacer algo así:
He omitido algunas cuestiones, pero, creo que puede entenderse si digo que el "ShowMessage" me devuelve "C:\Windows",... y ni rastro de "\otroDirectorio". Llama la atención el "ShowMessage", puesto que muestre la ruta "C:\Windows", tal como se espera, pero, con lo que parece un buen número de espacios en blanco a la derecha de dicha ruta... de tal manera que el "ShowMessage" se sale de la pantalla, ni más ni menos. Traté de pasar el resultado/la ruta por "TrimRight", pero, esto no funciona. Y, si en lugar de mostrar la ruta en un "ShowMessage" la añado a una línea de un "TMemo" en esta no sobran caracteres, no hay caracteres en blanco, puede verse, en este caso "C:\Windows", sin más... ¿Cómo es posible esto? Creo que tendrá que ver con cómo trabajo con la función "SHGetSpecialFolderPath", concretamente con la instrucción "SetLength(Result, MAX_PATH);" que puede verse más arriba. Sin embargo, recurro a vuestra ayuda, a ver si podéis orientarme, como estoy seguro de que así será. Adjunto la unidad en la que implemento la sencilla clase "TDirectoriosWindows". Si en algo no me he explicado, pues me lo hacéis saber y trato de hacerlo de buena gana. Muchas gracias de antemano por vuestra ayuda. |
#2
|
||||
|
||||
Cita:
1. El porqué de SetLength 2. Qué es un string 1. Normalmente Delphi manejará de forma automática la asignación, reasignación y destrucción de la memoria asociada a un string. Dado que tú estás usando una función de la API de Windows para vaciar datos en el string, Delphi pierde la oportunidad de poder manejar automáticamente la asignación y por ello hay que ayudarle indicándole la cantidad de memoria que debe asignar. Esto creo que ya lo sabes pero hay que observar que le estás diciendo que la cadena va a ser siempre de tamaño MAX_PATH aun cuando ShGetSpecialFolderPath devuelva una cadena mucho menor (como en 'C:\Windows') 2. Bueno, parece obvio pero el caso es que un string en Delphi ha llegado a ser mucho más que el original tipo de datos planeado por Wirth. Aunque el término 'string' conlleva el significado histórico de una "cadena de caracteres", en realidad un string puede almacenar cualquier secuencia de bytes y no sólo los correspondientes a caracteres. Y esto incluye el byte 0, que es justamente el byte que la API de Windows usa para indicar el final de una cadena. Entonces, en tu uso de ShGetSpecialFolderPath, lo que obtienes es un string de longitud MAX_PATH con los siguientes datos (binarios): 'C:\Windows0.................................................' donde los puntos significan "basura", cualquier cosa que hubiera en esa localidad de memoria (posiblemente ceros, no estoy seguro de si SetLength inicializa a ceros la memoria asignada). La causa exacta de los errores que obtienes no la sé pero muy posiblemente tenga relación con esto que te explico: obtienes una cadena "demasiado" larga. Creo que una forma de solucionarlo sería usando un arreglo de caracteres para recibir el resultado de ShGetSpecialFolderPath:
Un arreglos de caracteres (basado en cero) es compatible tanto con un PChar como con un String. Windows no tiene problemas para uar el buffer declarado y la asignación Result := Buffer se encargará de la conversión apropiada a string. Al margen de esto, me parece que no es correcto usar GetCurrentProcess como primer parámetro de ShGetSpecialFolderPath. El parámetro, según el SDK de Windows debe ser un identificador de ventana, no de un proceso. // Saludos |
#3
|
||||||
|
||||||
Hola roman,
Muchas gracias por tu interés y tu ayuda: todo salió a pedir de boca, como no podía ser de otro modo. Muy interesantes además los comentarios que realizas al hilo del problema que planteaba. Cita:
Cita:
Más claro me queda (ahora que tú lo pones así) el que estaba utilizando el tamaño de "MAX_PATH", aun cuando esto, como se puede comprobar, no es necesario: de hecho no es necesario el "SetLengh". Cita:
Cita:
Pero ese código "no compila". Provoca el error: "Constant object cannot be passed as var parameter"... todavía no tengo muy claro de qué se trata, pero, el error estaba en la instrucción mal usada: "SetLength". Esto, sin duda, pasa por copiar y pegar más de la cuenta y no saber lo que uno se trae entre manos. Cita:
Cita:
He pensado en cambiarlo por "GetActiveWindow", pero, puesto que no estoy muy seguro de obtener el resultado esperado, y además esta función, en caso de fallo devuelve "null" y acaso esto pueda causar problemas, he decidido, al menos por el momento, incluir un nuevo parámetro al único método de "TDirectoriosWindows", el cual solicita precisamente el "OwnerHandle" que precisa la función "SHGetSpecialFolderPath". He visto en la "idea" publicada en el Grupo Albor por Francisco Charte referida en el hilo a que antes hacía mención que dicho autor hace uso del "Handle" del formulario en que utiliza la función "SHGetSpecialFolderPath" y, por el momento, en lugar de "GetActiveWindows", como digo, he preferido solicitar un parámetro similar, aunque tal vez esto sea cargar el mochuelo al potencial usuario de "TDirectoriosWindows"... Bueno roman. Gracias de nuevo por todo. No podía esperar menos de ti ni de este lugar. Adjunto la unidad donde se implementa "TDirectoriosWindows" con las modificaciones comentadas y ya funcionando, al menos, sin el problema que ha originado este hilo. |
#4
|
||||
|
||||
Cita:
// Saludos |
|
|
|