Hasta el más tonto hace relojes: XEditor

[dec]

Hola,

Ea, pues ya está. Se trataba de que he usado la acción de edición estándar "Delete", y, de alguna manera, dicha acción estaba interfiriendo con el comando "ecDeleteChar" del editor. De momento he optado, sencillamente, por quitar dicha acción, pues, se trataba de un elemento en el menú contextual del editor que acaso hasta estuviera demás, teniendo en cuenta que uno pulsa la tecla "Suprimir" y no usa dicho elemento del menú.

No obstante, acaso añada el elemento cuando aprenda a enviar comandos al editor como ha de hacerse. Sea como sea, podéis descargar el programa de nuevo y comprobar que ahora la tecla "Suprimir" se comporta como vosotros esperábais, por un lado, y, también como yo esperaba... si hay texto seleccionado. Obviamente, esto de los comandos y "accesos directos" en el programa es algo a lo que tendré que prestar atención en el futuro.

http://goo.gl/ATCSn

¡Muchas gracias a todos!

[roman]

Ya probé y funciona bien. De todas maneras, es raro. Pareciera que la acción se inhabilitaba al detectar que no había nada selecciondo.

// Saludos

[dec]

Empezado por roman

Ya probé y funciona bien. De todas maneras, es raro. Pareciera que la acción se inhabilitaba al detectar que no había nada selecciondo.

// Saludos

Es posible Román: la acción "se queda" con la tecla sin que esta llegue al editor... alguien reportó algo parecido. Tal vez no debería usar las acciones estándar, que, por cierto no son muchas... aunque parece que el problema se dá sólo en el caso de esta tecla. Claro, porque, "CTRL+C" hace lo mismo, copiar texto, tanto en la acción estándar de Delphi como en el editor. Sin embargo, parece que la acción estándar de Delphi para borrar texto no hace lo mismo que el comando "ecDeleteChar" del editor.

[roman]

¡Ah! Pues acabo de ver que la acción estándar de Delphi hace lo mismo, es decir, se inhabilita el DELETE cuando no hay texto seleccionado.

// Saludos

[roman]

He aquí al culpable:

Código Delphi [-]
procedure TEditDelete.UpdateTarget(Target: TObject);
begin
  Enabled := GetControl(Target).SelLength > 0;
end;

Agrego:

Y me atrevería a afirmar que es así, "por diseño":

In TEditDelete, UpdateTarget checks whether the current target object (specified by the Target parameter) is an edit control that has some of its text selected. If so, UpdateTarget sets Enabled to true. If not, UpdateTarget sets Enabled to false.

Referencia

// Saludos

[dec]

Hola,

Gracias Román. Lo que dices es interesante, y, sin embargo, aún me atrevo a decir que acaso exista un "error", y, es que la acción se "come" la tecla en cuestión. Si dejase pasar la tecla, después de hacer su trabajo, el editor podría hacer el suyo. Pero no parece ser así. Claro, ahora que lo pienso, en realidad la tecla funciona... pero sobre un elemento "deshabilitado"... en fin. En este caso no tiene importancia, pues, como digo, para la acción suprimir, ¿quién usaría el elemento del menú? Yo creo que nadie...

[Neftali [Germán.Estévez]]

Correcto.

Gracias David.

[roman]

Empezado por dec

Hola,

Gracias Román. Lo que dices es interesante, y, sin embargo, aún me atrevo a decir que acaso exista un "error", y, es que la acción se "come" la tecla en cuestión. Si dejase pasar la tecla, después de hacer su trabajo, el editor podría hacer el suyo. Pero no parece ser así. Claro, ahora que lo pienso, en realidad la tecla funciona... pero sobre un elemento "deshabilitado"... en fin. En este caso no tiene importancia, pues, como digo, para la acción suprimir, ¿quién usaría el elemento del menú? Yo creo que nadie...

No hay error. Así está diseñado. La acción TEditDelete únicamente tiene dos métodos. El ya mencionado UpdateTarget y ExecuteTarget:

Código Delphi [-]
procedure TEditDelete.ExecuteTarget(Target: TObject);
begin
  GetControl(Target).ClearSelection;
end;

O sea que, aún cuando redefinamos UpdateTarget para que no se inhabilite la acción, también tendríamos que redefinir ExecuteTarget puesto que ClearSelection actúa sobre la selección. Y con esto ya nos cargamos toda la acción

// Saludos

[matabyte]

Bien! ahora ya me funciona correctamente lo de cerrar la ventana de la ayuda .

Otra cosa (me vas a odiar de tanto sacar pegas ):
-Cuando registras el programa no sale ninguna ventana de "gracias por registrar el programa". Como confirmación sería estupendo ponerla

-Al intentar cargar un fichero .avi de 350Mb, me dice obviamente "si quiero cargarlo". Le digo que si, y se queda un bueeen rato bloqueado (supongo que intentando leerlo), en ese rato el programa está bloqueado, luego me saca el mensaje de "Out Of Memory", estaría bien que tubiera una barra de progreso junto a un botón de cancelar

-Y igual es demasiado, pero que leyera los ficheros grandes por bloques (no todo a la vez, si no secuencialmente). Ya se sabe que los usuarios son capaces de abrir una imagen .iso de 16Gb con el notepad...

-Lo mismo me ocurre con ficheros .java de mas de 100Kb, el programa se "congela" sin permitir movimiento de la ventana.

Lo de los ficheros .java con UTF8, he intentado cambiar la codificacion desde el menu derecho, pero no pasa nada, no cambia de codificacion.

[dec]

¡Hola!

Empezado por matabyte

Bien! ahora ya me funciona correctamente lo de cerrar la ventana de la ayuda .

¡Me alegro, pues!

Otra cosa (me vas a odiar de tanto sacar pegas ):

Nada de eso, todos los comentarios son bienvenidos.

-Cuando registras el programa no sale ninguna ventana de "gracias por registrar el programa". Como confirmación sería estupendo ponerla

Es así adrede. Se trata de evitar "pistas" a los "crackers". De todas formas los mensajes de "no registrado" dejan de aparecer, y, los elementos de los menús para registrar el programa, así como las "nag screen" inicial y final, y también en el "acerca de..." se ve que el programa está registrado.

-Al intentar cargar un fichero .avi de 350Mb, me dice obviamente "si quiero cargarlo". Le digo que si, y se queda un bueeen rato bloqueado (supongo que intentando leerlo), en ese rato el programa está bloqueado, luego me saca el mensaje de "Out Of Memory", estaría bien que tubiera una barra de progreso junto a un botón de cancelar

No he probado con archivos tan grandes. Los componentes que uso no se llevan demasiado bien con archivos grandes. Ignoro si yo podría hacer algo... ahora pienso que sí, tratando de leer el archivo poco a poco e ir cargándolo "en stream" en lugar de con el método "LoadFromFile". Tengo que mirar esto...

-Y igual es demasiado, pero que leyera los ficheros grandes por bloques (no todo a la vez, si no secuencialmente). Ya se sabe que los usuarios son capaces de abrir una imagen .iso de 16Gb con el notepad...

De ahí la advertencia al tratar de abrir archivos "grandes"... Algo he leído sobre abrir archivos "a demanda", es decir, sólo el contenido "visible" en el editor, pero, reconozco que sobre esto estoy bastante pez... aunque sería interesante.

-Lo mismo me ocurre con ficheros .java de mas de 100Kb, el programa se "congela" sin permitir movimiento de la ventana.

Es curioso, porque, aunque es cierto que el programa se retrase un poco con archivos de varios MB, lo cierto es que no va mal (o yo no noto demasiada tardanza) con archivos del tamaño que dices... no sé porqué puede darse este problema. Acaso tengo que probar con algún archivo Java...

Lo de los ficheros .java con UTF8, he intentado cambiar la codificacion desde el menu derecho, pero no pasa nada, no cambia de codificacion.

¿Lo guardas después? De hecho el "documento" debería quedar "modificado" y, al guardarlo, se cambia la codificación... o debería cambiarse... a mí me funciona como digo, vamos...

¡Gracias por los comentarios!

[roman]

Hola,

Hay algo que a mi en lo particular no me gusta que hagan los programas y me acabo de dar cuenta que el tuyo lo hace ¿Porqué guardas la configuración del programa en CSIDL_PERSONAL (Mis Documentos) en lugar de CSIDL_APPDATA (AppData/Roaming)?

// Saludos

[dec]

Hola Román,

Comprendo que los datos del programa han de guardarse en donde dices, en efecto. Sin embargo, si se guarda en "Mis documentos" es, porque, los archivos INI (configuración del programa, colores de las sintaxis, etc.) son en realidad más bien datos del usuario. De hecho, una de las cuestiones que quiero incorporar al programa es la posibilidad de "guardar y recuperar" dichos datos. No los considero datos del programa, porque, tu configuración (por ejemplo en cuanto a colores de las sintaxis) no tiene porqué coincidir con la mía... y más allá de eso,... es que lo considero algo "personal", como si dijéramos. Tal vez esté equivocado, pero, he seguido este razonamiento.

P.S. Una de las cosas a hacer antes de publicar la primera versión estable del programa, es respetar la configuración del usuario. Esto es, el programa instalador "desinstala" el programa (actualmente) antes de instalarlo, borrando así los datos del usuario. Esto es ahora así, en principio, porque no me gusta dejar rastro de mis programas, y, como está teniendo tantos cambios, prefiero "borrar y reinstalar". Pero, con la primera versión estable he de respetar la configuración del usuario, no sobreescribiéndolos ni borrándolos, o, tal vez preguntando al usuario si quiere borrarlos o no.

[roman]

Ojo: CSIDL_APPDATA es un directorio específico del usuario y es donde las aplicaciones guardan las configuraciones del usuario, de manera que distintos usuarios pueden convivir en la misma máquina con distintas configuraciones. Es el lugar que aplicaciones como Firefox, Thunderbird, Netbeans, FileZilla, etc, guardan la configuración del usuario. El lugar para guardar datos de la aplicación comunes a todos los usuarios (si fuera el caso) sería CSIDL_COMMON_APPDATA.

CSIDL_PERSONAL es un lugar para que el usuario guarde sus propios documentos; su lista de compras, su currículum, la carta al padre, etc.

// Saludos

[dec]

Hola,

Quizá lleves razón Román, y, en todo caso es interesante lo que dices. Sin embargo, tengo mis dudas. Otro de mis proyectos, los plugins para NeoBook, guardan también los ejemplos en "Mis documentos", y, así lo hace también el propio NeoBook y otros programas: Visual Studio, Inno Setup, RAD Studio... ¿por qué? Yo pienso que lo hacen por el mismo motivo en que yo he decidido poner dichos archivos ahí: de alguna manera, dichos archivos pertenecen al usuario. Por ejemplo, en el caso de los ejemplos de mis plugins, el usuario puede modificar un ejemplo, y, una vez hecho, ¿a quién pertenece dicho archivo? Yo creo que al usuario... esa decir, no es un "dato de la aplicación", ni común ni particular.

Ahora bien, con Small Editor he seguido dicho razonamiento (repito que tal vez equivocado), aunque, en este caso no hay ejemplos... ¿y entonces porqué si no hay ejemplos sigo tratando los archivos de configuración como "archivos del usuario"? Por lo dicho más arriba... porque los considero archivos del usuario, porque el usuario puede cambiarlos, editarlos (es verdad que a través del programa, en principio), añadir nuevos (es posible añadir temas nuevos para las sintaxis), etc. En definitiva, ya ves que soy burro a más no poder. Je je je... Aunque después, si me convenzo, no soy tardo en hacer los cambios que sean menester.

[matabyte]

Empezado por dec

¡Hola!
Es curioso, porque, aunque es cierto que el programa se retrase un poco con archivos de varios MB, lo cierto es que no va mal (o yo no noto demasiada tardanza) con archivos del tamaño que dices... no sé porqué puede darse este problema. Acaso tengo que probar con algún archivo Java...

¿Lo guardas después? De hecho el "documento" debería quedar "modificado" y, al guardarlo, se cambia la codificación... o debería cambiarse... a mí me funciona como digo, vamos...

¡Gracias por los comentarios!

Lo del fichero de 100Kb que se congela el programa supongo que sera porque tarda en aplicarle la sintaxis de java (le he cambiado los colores), de todas formas mi cpu es un 6 nucleos y no deberia de tardar tanto, igual mejor que miraras lo de aplicar la sintaxis en segundo plano.

Lo de los ficheros grandes, yo pondria lo de mostrar solo la parte que estas mostrando, ya que es algo que estaria bien, ya que no solo archivos avi de 300Mb, tambien hay archivos grandes de texto, no se, abrir un html/c/pascal de 1Mb debe de tardar bastante y eso sin aplicar la sintaxis.

Lo de la codificacion, pensaba que lo cambiaba instantaneamente (la forma de mostrarlo), vamos, al hacer click en el formato, que mostrara ese formato. Si tengo que salvarlo para verlo con el formato nuevo es un poco lioso a la vez que peligroso (Si no se si el fichero esta en UTF8 o unicode y lo salvo en UTF8 y estaba en unicode todos mis preciosos kanjis desaparecen).

Bueno, animo con el programa, que va quedando muy bien!

[dec]

Hola Matabyte,

Empezado por matabyte

Lo del fichero de 100Kb que se congela el programa supongo que sera porque tarda en aplicarle la sintaxis de java (le he cambiado los colores), de todas formas mi cpu es un 6 nucleos y no deberia de tardar tanto, igual mejor que miraras lo de aplicar la sintaxis en segundo plano.

Sin duda puedo echar un vistazo a dónde se aplica la sintaxis, para tratar de optimizarlo. Estoy pensando, por ejemplo, en no aplicarla a los archivos "cuando se abren", sino, hacerlo cuando "pasan a ser el editor activo". Ir más allá sería algo complicado, me temo, puesto que depende de los componentes que estoy usando, y, no sé yo si estaré al nivel de poder hacer modificaciones en dichos componentes.

Empezado por matabyte

Lo de los ficheros grandes, yo pondria lo de mostrar solo la parte que estas mostrando, ya que es algo que estaria bien, ya que no solo archivos avi de 300Mb, tambien hay archivos grandes de texto, no se, abrir un html/c/pascal de 1Mb debe de tardar bastante y eso sin aplicar la sintaxis.

Llevas razón. Aunque creo que podemos coincidir en que son raros los archivos de código fuente mayores de 1 MB, por poner una cifra, esto no quiere decir que no existan dicho tipo de archivos. Igual podría tomarse la determinación de abrir "normalmente" los archivos "pequeños" y hacerlo de forma "pausada" con los archivos "grandes". Sin embargo, mucho me temo que ahora mismo no sabría por dónde empezar, es decir, tengo más dudas que otra cosa. Pero sería bueno estudiar este asunto.

Empezado por matabyte

Lo de la codificacion, pensaba que lo cambiaba instantaneamente (la forma de mostrarlo), vamos, al hacer click en el formato, que mostrara ese formato. Si tengo que salvarlo para verlo con el formato nuevo es un poco lioso a la vez que peligroso (Si no se si el fichero esta en UTF8 o unicode y lo salvo en UTF8 y estaba en unicode todos mis preciosos kanjis desaparecen).

No; vamos a ver. Aunque se me ocurre lo siguiente: al cambiar el formato, guardar y volver a abrir (refrescar) el archivo en cuestión, lo cierto es que cambiar la codificación de caracteres desde el editor no implica cambios en el archivo, sólo que el archivo se guardará, cuando se haga, en la codificación seleccionada. Creo que la pérdida de datos podría darse más bien cuando un archivo no se abre correctamente, es decir, cuando no se reconoce la sintaxis y se aplica la predeterminada (acaso ANSI).

Empezado por matabyte

Bueno, animo con el programa, que va quedando muy bien!

Muchas gracias por tus palabras y por tus comentarios. De veras lamento no poder atenderlos a todos rápidamente, pero, mucho me temo que algunas cosas, sencillamente, tendrán que esperar, al menos un tiempo, hasta que pueda ver cómo y de qué manera se pueden implementar. Pero todas son cosas que, ciertamente, hay que tener en cuenta, porque, además, si no las tengo en cuenta yo... las tendrán en cuenta las personas posiblemente interesadas en el programa.

¡Muchas gracias otra vez!

[dec]

¡Hola a todos!

Unas cuantas cosas. Estoy dándole vueltas a la optimización de la apertura de archivos "grandes", y, leyendo esta página web, parece que los componentes SynEdit tienen cierto "cuello de botella" cuando el "WordWrap" está activado. En efecto, he podido comprobar que, si desactivo dicha opción al cargar archivos, estos se cargan más rápidamente. Después es cuestión de activar la opción si es que es necesario. Esto mejora al menos un poco (bastante, diría yo) la carga de archivos grandes.

Por otro lado, me he dado cuenta de que, en efecto, si un archivo grande quedaba "en la sesión", al iniciar el programa este podía quedarse colgado, tal como comentó el compañero Matabyte arriba. He descubierto dónde estaba el problema y lo he solucionado. Esto quiere decir que, más o menos rápidamente, ahora el programa abrirá los archivos grandes "guardados en la sesión", esto es, al menos no se quedará colgado.

Y ahí le seguimos averiguando cómo mejorar la carga de archivos grandes... por cierto, no he notado mejora si no cargo la sintaxis. Y, claro está, ahora mismo no comprendo muy bien cómo, si es tan sencillo como expongo en el primer párrafo, no se desactiva la opción "Wordwrap" cuando se carga un archivo... ignoro porqué es así, pero, como digo, no es preciso tocar el código de los propios componentes SynEdit y podemos nosotros desactivar dicha opción antes de cargar el archivo en cuestión.

¡Muchas gracias a todos!

[roman]

Hola,

Estoy viendo la búsqueda en archivos. Unas sugerencias:

1. Poder especificar varios directorios es muy bueno, pero sería aún mejor que pudieras indicarlos todos con el cuadro de seleccionar directorio. Actualmente, el uso de este cuadro sobreescribe todo el contenido de la caja de texto.

2. En los resultados, añadir una columna con un pequeño extracto del contexto para así saber si es lo que uno quiere o no.

3. Que cuando selecciono un resultado de la búsqueda, me lleve a la línea donde apareció y no al principio del archivo.

4. Cuando ya terminé mi búsqueda, ¿cómo me deshago de la pestaña de resultados?

// Saludos