¿Ayuda urgente por favor?
 

Hola amigos del foro, necesito de su ayuda. El problema es que necesito hacer algo parecido a un OnCreate, OnActive y OnDestroy como el de las Form pero para aplicación porque la verdad es que no tengo ni la más mínima idea de como hacerlo.

Gracias de antemano....:confused::eek::eek::confused:

Antes de nada te recomiendo que leas la Guía de estilo de los foros y que intentes utilizar títulos más descriptivos en tus mensajes y referentes al problema del mensaje; Lo de "ayuda urgente" no dice gran cosa del problema que tienes.

En cuanto a tu pregunta, no he entendido nada. No se a qé te rfieres con OnCreate, OnDestroy,... de la aplicación. No se si te podría servir utilizar los del form principal o los necesitas a nivel general; en el segundo caso. podrías mirar el componente TAppllicationEvents de la paleta Adicional, para intereptar mensajes a nivel de toda la aplicación. Colocalo en un form y revisa los eventos. De todas formas, no me ha quedano claro lo que buscas.

Hola Neftali, presisamente a eso me refiero a una funcion que aga lo mismo que el oncreate, ondestroy de la form prinsipal pero a nivel de sistema....

De verdad que si no poenes un pocoi de tu parte y te explicas mejor es imposible.
OnCreate es un evento (que no hace nada); Como evento que es, "salta" cuando un formulario se crea. En él tú programas lo que quieras. Pero como evento que es NO HACE NADA.

Ahora di, ¿Quieres una función o un evento? No tiene nada que ver lo uno con lo otro. ¿De aplicación o de sistema? No tiene nada que ver lo uno con lo otro.

Intenta explicar detalladamente cuando quieres que "salte" el OnCreate de sistema al que te refieres... O si es una función cuando quieres que se ejecute y qué debe hacer...

Mira Neftali te voy a explicar lo que estoy tratado de hacer para que me entiendas, lo estoy haciendo es un programa el cual cuenta con una form y un memo en el cual voy registrando todas las teclas que son pulsadas en Windows. Ahora lo que quiero hacer es que cuando la aplicación abra me cargue los datos almacenados en un txt pero para eso tengo que crear primero el form, por otra parte cuando se sierre la aplicación me guarde lo datos nuevos. Lo de cargar y guardar ya lo se hacer en donde estoy trabado es precisamente que me realice estas acciones, la primera al arrancar y la segunda el finalizar la aplicación....

has probado con los eventos de TApplication??, por ejemplo en tu caso deberias asignar el evento onMessage.

Hola,

Yo creo que bastaría con utilizar los eventos "OnCreate" y "OnClose" del formulario principal, probablemente el mismo que contenga el "TMemo" del que hablas. :)

Adjunto un sencillo ejemplo de lo que digo.

hola dec, gracias por el ejemplo eso era esactamente lo que me asica falta lo que tengo una duda en la parte esa donde tu pones.

resourcestring
rsArchivoDatos = 'datos.txt';

Que es eso resourcestring....

Hola,

De la ayuda de Delphi:

Aunque he de reconocer que un servidor utiliza los "resourcestring" un poco como "constantes de tipo string"... sin más. Es decir, no mirando si estos se almacenan como recursos, si pueden cambiarse sin necesidad de compilar la aplicación, etc.

Empero, algunas herramientas, como pueda ser DxGetText dan un tratamiento "especial" a los "resourcestring". Por ejemplo DxGetText puede "parsear" un archivo ".pas" y "tomar" las cadenas "resourcestring" automáticamente.

En todo caso, utilizados como constantes, los "resourcestring" ofrecen todo lo bueno de estas, según mi opinión. Personalmente, no me gusta mezclar las cadenas con el código fuente, y de ahí que use con profusión "resourcestring". ¿Que por qué no uso constantes directamente? No sé... no creo que tenga una respuesta muy lógica para esto. :)

Bueno ya veo sabes que me esta empezando a gustar esto del "resourcestring" quien sabe a lo mejor sigo tu ejemplo y empiezo a utilizarlo también, gracias un ves mas...

Fuera de foco
 

Lo que comento no tiene que ver con el hilo, pues creo que la inquietud ha sido satisfecha.

a quien le gusta usar resourcestring???? GUACALA

1. El recurso es visible para cualquier "ResHacker"
2. Una comprimida (mew) y chau recurso
3. Delphi guarda estos recursos como WideString... osea que por cada caracter usado hay otro inutil!

quieres saber mas?

¿Cuál sería el inconveniente de esto? Esa es la idea, que puedan editarse con un ResHacker, para poder localizar la aplicación ¿no?

// Saludos

Hola
Lo siento mucho pero lo tengo que comentar, para mi es una falta de respeto, tanto hacia la persona que hizo el hilo, como los que participan en el, decir esto:
Creo que si quedo alguna duda, se pierde el hilo del asunto y se trunca.
Para mi un comentario como este deberia ir a la taberna, no se, digo yo, para mi es insolente y fuera de lugar.
Saludos

Ok
 

Acepto el comentario Caral, intentare no volver a realizar un comentario de esa clase, truncare mi libre expresion para evitar futuras explicaciones de parte mia. Y en todo caso si otra persona considera que mi participacion es agresiva agradecere críticas constructivas pero no en hilos particulares como este.

Al grano, espero que este post sea mas ilustrador; al creador del hilo le aconsejo hacer Ctrl+Click a un método o propiedad de un formulario y Ctrl+F para buscar la cadena FOnCreate... así aprendí yo como funciona la VCL del Delphi y tambien como interaccionan los componentes que tanto buscamos y que en realidad son muy faciles de hacer.

De lo otro, me parece que los puntos 2 & 3 no fueron rechazados como argumentos para no utilizar resourcestring, lo de los programas tipo ResHacker; este argumento esta directamente relacionado con la seguridad del programa.

¿Rechazados? Pero si no es una votación :D Yo seguiré usando resource strings siempre que lo requiera. Lo de la seguridad no me parece un argumento importante en este contexto, no es que vaya yo a guardar ahí mi número de cuenta bancaria.

Por otra parte, no veo que nadie esté coartando nada, simplemente dieron una opinión.

// Saludos

mmm...
 

No es que trate de justificar el uso o no de ciertas tecnologias (unicode ó .rsrc) pues por algo fueron creados... solo muestro (en este caso), los "inconvenientes" de los resourcestrings... ahora si las utilizas y que por sierto es una exageracion lo de la tarjeta de debito y fuera de contexto, es una desicion meramente tuya Suerte con ello! pero mucho cuidado...

¿Fuera de contexto? Este, pue sí, justamente por eso lo mencioné: ¿qué tiene que ver la seguridad con los resource strings?

// Saludos

:l
 

Tienes algo de razon... relacion directa no hay y es un hecho muy subjetivo en relacion a la forma de programación. Pero, pon un programa mio hecho en Delphi con un resourcestring al frente de un "usuario experto", éste muy probablemente no conozca utilitarios como WinHex o un PExplorer. Pero si conocerá a un ResHacker porque en el 2006-x le gustó unos iconitos de un programa, busco como robarlos y lo encontró.

Entonces lo utiliza y se da cuenta que por ejemplo el programador no puso el numero de su tarjeta de debito, pero si el texto de sus derechos de autor... Entonces el usuario agarra y le quita/cambia dicho nombre. Cualfuese el contenido de los resourcestrings el lo podrá ver/modificar/borrar con dicho utilitario. Pero si utilizas una cadena convencional o constante, pues estará al alcance solo de algunos, pues ni como programadores, algunos desconocen de editores hexadecimales y aunque lo hagan si lo comprimes con un upx es más probable que los .rsrc se vean y lo convencional no.

PD: el Visual Studio 2003+ abre los .exe, .dll, .ocx y otros, los muestra y permite editar tales controversiales recursos sin problema.

Siguiendo esa lógica, tiramos por la basura todos los programas hechos hasta ahora, que traen la licencia en un .txt, señores, en el año 2007 y ¡¡ viene la licencia con el bloc de notas !!.... sinceramente, creo que es pasarse.

Si crees que puedes tener problemas con eso, contrato redactado por abogados en papel y firmados por ambas partes.

En ResourceString se suele guardar las constantes usadas en el programa ... que al final son mostradas al usuario, y no creo que sea motivo de paranoias, si el usuario quiere modificarlas... que las modifique, pero en el exe original, grabado en CD vendrán como yo las puse. La fecha de modificación del ejecutable, cantará notablemente, y ya puestos, crea un md5 o un hash del archivo y si alguien lo modifica, pues que avise al usuario y se cierre, pero vamos, que eso es harina de otro costal.

Saludos

EEehhh
 

hey lepe, tampoco es para que me des palo con sarcasmos. Lo de la paranoya si, tienes toda la razon... puede que la inexperiencia me haga hablar.

Que vivan los ResourceStrings... mientras yo pueda hacer cracks de sus sistemas!

¡Pues hazlos! ¡Esa es justamente la idea de los resource string! Que cualquiera pueda traducir una aplicación. Por ello es que no entiendo la insistencia en la seguridad. No están pensados para guardar datos seguros, sino los textos que el usuario ve, y que por tanto son susceptibles y deseables de traducir.

// Saludos

Yo coincido con Roman. El chiste de los resStr es precisamente que se pueden modificar sin recompilar. Un programador paranoico obviamente no creo que sea tan tonto de poner lo que quiere "proteger" (como su copyright o su nombre) en un resStr.

Hace años, en las epocas de MS-DOS cuando no habia Windows ni aplicaciones en español. Me ponía a "localizar" aplicaciones usando "fuerza bruta". Abria el exe con un editor Hex y cambiaba cuanto texto encontraba, el problema era cuando no cabia la traducción. Así fue como empezaron a aparecer en mi facultad copias "castellanizadas" de PC-Tools, Norton Disk Doctor, etc. Mas adelante me di cuenta que a mis propios y "geniales" programas alguien más podia hacerles lo mismo. Como usaba Turbo Pascal 3.0 (si, 3.0) me di cuenta que si ponia las cadenas a "proteger" como esto: "#164+#60+..." aparecian correctamente en lapantalla al desplegarlas pero al buscarlas con un Hex no había ni rastro de ellas. Por el contrario si ponia la cadena en forma literal si aparecía. No he revisado si esto aun sirve...

Nop
 

Disculpenme pero no estoy de acuerdo con ustedes, estaba a punto de dejar este tema o pasarlo a la seccion de seguridad... (si me siguen lo hacemos).

Creo que si usamos ResourceString; para almacenar cualquier cosa, independientemente del grado de seguridad que los datos alojados requieran, estamos mostrando un poco de lo que al usuario no le interesa (o talvez no puede) saber. Siempre pense que si uno va a realizar una aplicacion, debe ser totalmente transparente para el usuario final, y para esto se debe realizar una "interfaz" de lo más amigable. En qué lugar de las aplicaciones como Word (office), Notepad, Delphi, Postgres, etc. los desarrolladores nos incitan a modificar la sección .rsrc. de sus ejecutables para configurarlos???

El modo más correcto de hacer lo que ustedes dicen, es usar menús con acceso a configuración (Herramientas -> Configuración), o en su defecto decirle al usuario modifique manualmente la configuración (editar un .INI). O para un usuario experto dejarle un .XML y que por medio de éste haga lo que quiera.

Poder traducir? no creo Dec, hice este comentario para que quienes lo lean decidan, viendo cuántos PROs y cuantos CONTRAs tienen al utilizarlo.

Ahh, AzidRain... lo que tu me dices tampoco concuerdo. No me cuesta nada hacer un Ctrl+F9 para recompilar; los nuevos releases no solo cambian en un contenido textual, y si lo hacen deberían usar al registro para guardar la nueva configuración.

Con respecto a lo otro; no si tu forma servirá "#164+#60+...", pero si estoy seguro que los datos se pueden proteger...
Saludos!

Disculpa, pero es que los argumentos que expones no tiene que ver con la seguridad, que es en lo que ha derivado este hilo. Que los recursos sean o no el mejor método para traducir aplicaciones es harina de otro costal.

Ahora, si insistes en la seguridad, ¿te parece más seguro un archivo ini o xml?

// Saludos

Huufffffff
 

Cita:

Empezado por cHackAll 2. Una comprimida (mew) y chau recurso 3. Delphi guarda estos recursos como WideString... osea que por cada caracter usado hay otro inutil!

Cita:

Empezado por cHackAll ...me parece que los puntos 2 & 3 no fueron rechazados como argumentos para no utilizar resourcestring...

Cita:

Empezado por cHackAll ...independientemente del grado de seguridad que los datos alojados requieran...

Estoy hablando de los motivos por los que yo digo: "GUAACA", de los ResourceStrings, que claro es un tema que tiene que ver con el grado de seguridad que la aplicacion tendrá. Al no utilizarlos, su aplicacion será (muy probablemente) más segura.

No es un ini o xml mas seguro, si no mas apropiado para los datos que uds. guardan en tan polemicos .rsrc.

¿Claro? Ese que eres tú quien hablaste de seguridad pero ya te hemos argumentado que eso no tiene relación. A ese respecto, los recursos no son más que un repositorio de datos y nadie los pensó para guardar datos seguros. Si tienes datos confidenciales, ciertamente, un recurso no es lugar para ponerlo, así como tampoco lo es un ini o un xml.

En cuanto a los otros puntos, tambien son discutibles y si quieres lo hacemos. Yo por ejemplo, cuando recién escribiste ese comentario, hice la prueba con upx y nada que se pierden los recursos. Es cierto que después de comprimido, ya no puedes modificarlos, pero eso no es razón para no usarlos. En todo caso, primero editas y luego comprimes.

Lo del widestring está para poder usar unicode.

Yo entiendo que a ti en particular no te gusten los recursos y es muy respetable, pero de ahí a descalificar una herramienta por un gusto, hay una diferencia.

// Saludos

Muy interesante
 

Muy interesante este hilo, se aprende mucho !!

Saludos a todos !!

No estoy de acuerdo con eso.

(1) Creo que si esa afirmación es cierta, es que estás metiendo en los ResourceStrings algo que no debes.

Entiendo que lo que se pone en un ResourceString (puesto que es sabido que es visible para cualquiera) es cualquier dato que no comprometa la seguridad de la aplicación. Por lo tanto si usar ResourceStrings hace la aplicación más insegura es que no estás cumpliendo este requisito (1).

Caramba, como puede llegar a liarse un hilo titulado "¿Ayuda urgente por favor?" :eek:

No pensaba meterme, pero ahi va mi opinion.

1. No entiendo por que una aplicación es mas insegura si alguien se dedica a cambiar los textos que aparecen en ella. ¿También es mas "insegura" si le cambia los iconos?, es mas, aunque cambiara la licencia, tendría el mismo valor que un contrato falso, es decir, ninguno.
2. Cualquier otro método para guardar texto dentro del ejecutable de forma "segura", pasaría por el cifrar el texto o firmarlo con un hash. Entonces me pregunto por que no cifrar los recursos o firmarlos con un hash, la "seguridad" es independiente del sistema que escojamos para almacenar la información.
3. En cualquier caso, un buen "craker" no tendrá problemas en destrozar lo que sea. Así que no entiendo por que ponerse paranoico, si lo quieren hacer lo harán.

Es solo mi opinión, aunque estoy dispuesto a respaldarla con código :cool:

Ahí ahí,... ¡¡¡Abofeteando y tirando el guante!!! :D

Huy, pues si un "cracker" se digna a destrozar mi programa me daria por bien servido, eso quiere decir que realmente es intgeresante lo que hago.

:(:(:(, Vaya, pues no hago programas que valga la pena violentar......:D

Salud OS.

Hola
El que sabe sabe.
Y yo que me queje del hilo, y la estoy pasando de perla, aprendiendo de los maestros.
Saludos

Parece "Duelo de Titanes"
 

Alguien tendria la bondad de enseñarme como planear una aplicacion para que se pueda traducir en un futuro a otro idioma ? ( el texto de los botones, menus, etc... ). Escucho que es con los resources, pero de en adelante ni idea tengo de que hacer para lograrlo !

Tambien, lo de la seguridad... si alguien desea darme algunos consejos en como proteger un programa. ( entiendo que un buen crack-ero rompe cualquier programa, pero por lo menos que le cueste trabajo ! ).

( Pregunto aqui, porque este hilo dice mas que los hilos en la seccion de "proteccion" ).

- Estaba pensando ayer como a las 3 de la madrugada que
si el hace cracks le dicen crack-ero,
y que hace pan le dicen panad-ero,
y el que trabaja con tapiz le dicen tapic-ero,
y el que corta la carne le dicen carnic-ero,

entonces, acaso seria correcto decir que
- quien es experto en API's es un API-ero ?,
- y quien trabaja con tablas sean un Tabl-ero ?,
- y quien maneja bien los hilos sera un Hil-ero ?

...y despues de eso, me di cuenta que lo conveniente era acostarme a dormir... !

Saludos a todos !!

Allí les voy!
 

Vamos a definir todos y cada uno de los argumentos, creo que en éste punto están todas las ideas pero algunas inconclusas o mal definidas.

Hablamos de los ResourceStrings: La utilizacion o no de éstos es el tema que tanta polémica a formado. Voy a exponer cada uno de los puntos de la forma mas clara posible refiriendome al por qué dije "GUACA" de tales y por que yo evitaré en lo posible hacer uso de los mismos.

1. "Recursos mutilados" quienes les gusta realizar aplicaciones de pocos Kb?
Posiblemente sea el argumento más refutado por Uds.; comparé un grupo de compresores, scramblers, y encriptadores; concluí que existen dos que son los mejores, el PECompact fué el mejor para ejecutables normales a grandes. y el mew, el cual utilizo para los archivos más pequeños, éste último es muy bueno y hasta comparable con el upx en aplicaciones medianas. Una de sus características es que posibilita la mutilación de los recursos.

No defiendo con ahínco esta posición pues quienes utilizan mew? quienes lo conocen? solo yo??

1.1. Inmerso en el punto está el hecho de que otros compresores como el upx se rayan al comprimir algunos ejecutables con cadenas de recursos. Para que no pase esto normalmente te dan la opción en un CheckBox que dice "Compress resources" para que el usuario decida hacer un programa (como citaba algúno): "configurable" y cuando éstos datos los ve cualquiera pues los cambia... talvez le pone insultos! yo se que arán con mi programa? si es bueno hasta dónde o que manos llegara? y eso es un tema que deja mucho que desear con respecto a la seguridad (o por lo menos con la integridad de la aplicación), pero claro que es subjetivo a la forma en que el programador plasma sus ideas. Para configurar (repito), lo correcto (creo yo) es un menú, un archivo ini, xml o datos en el registro (que tambien puede ser un hecho polémico).

2. Hablaba del WideString (unicode), una aplicación tiene cierto peso (tamaño), éste en muchos de los casos no nos interesa. Pues hablamos de PCs que antes hubiensen sido consideradas como MainFrames. Pero yo sigo con un pensamiento de ahorro; considero que una aplicacion pequeña que hace muchas cosas tiene los procedimientos bien optimizados, o en lenguaje de maquina o que simplemente interactúa de una forma adecuada con el S.O. Cuando el Güindos lee dichas variables en unicode debe llamar a la API 'UnicodeToUtf8' (claro después de usar APIs como: FindResourceEx, LoadResource, y LoadString para obtener la posicion en memoria donde se encuentra el recurso), como siempre una caja negra! parece estar bastante optimizada pero quién sabe!. Nuestro Delphi tiene su versión:

cuando uno hace lo siguiente:

Código Delphi [-]
 
uses Windows;
ResourceString
 hello = 'Hola amigos de ClubDelphi!';
begin
 MessageBox(0, PChar(hello), nil, 0);
end.

obtiene un ejecutable de 15.5 Kb. y cuando uno hace:

Código Delphi [-]
 
uses Windows;
const
 hello = 'Hola amigos de ClubDelphi!';
begin
 MessageBox(0, PChar(hello), nil, 0);
end.

obtiene un ejecutable de 8 Kb. Compruebenlo Uds. mismos!

Se preguntarán por qué? Es simple: con la segunda el Compilador genero un programa que llama directamente a la API con una direccion en memoria que contiene la cadena. Con la segunda; primero debe cargar el recurso, ésto lo hace con un procedimiento llamado 'LoadResString' que está en la unidad System. éste procedimiento genera un arbol de llamadas muy interesante:

LoadResString
FindResourceHInstance
DelayLoadResourceModule
GetModuleFileName
LoadResourceModule
GetModuleFileName
RegOpenKeyEx
ToLongPath
GetModuleHandle
GetProcAddress
GetLongPathName
lstrcpyn
FindBS
lstrcpyn
lstrcpyn
FindFirstFile
FindClose
_strlen
lstrcpyn
_strlen
lstrcpyn
RegQueryValueEx
RegCloseKey
lstrcpyn
GetLocaleInfo
lstrcpyn
LoadLibraryEx
LoadString
SetString
LStrToPChar

Y que de seguro se me fue un par! 0j0 que solo fueron llamadas, y todo el código (if, then, or, else, operadores ifs anidados) lo obvio, pues no quiero aburrirlos.

El unicode es una cosa buena, pero no muy aplicable para todos los casos al igual que esa palabrita reservada que tanto dolor de cabeza nos dá. En las primeras participaciones del hilo ví que hacían referencia a un archivo! un .txt y considero que no lo notaremos, pero qué sucede si se nos vuelve costumbre? si hacemos una aplicacion mediana a grande los mínimos retardos se sumarán y notarán. Pero bueno.. paso al último punto que a propósito es nuevo.


3. Agarré y comparé los recursos que el 'explorer.exe' tiene en la versión para eQuispe; encontré 102 cadenas de recurso (si me equivoque es porque los conté a "dedo")
y agarré el 'explorer.exe' de la versión Vista... encontré asombrado 0 (cero), recursos de cadena. Que sucedió?? por que una empresa como Microsoft decidió ya no utilizarlos en sus cadenas? tendrá que ver con aquellos usuarios perrisimos como yo? será más seguro o que?

NOTAS:
Una de las posiciones mas valederas decía: "...they can be modified without recompiling the program..." a mi no me molesta hacer Ctrl+F9! o si voy a poner algun dato que sirva
como configuración pues hago un menu, ini o xml que al final llega a ser la opcion mas "correcta"

Otro me decía "...harina de otro costal..." pues yo digo que siempre y cuando dicha harina tenga que ver con la misma familia del trigo vale la pena hecharle un 0j0.

MI conclusión con respecto al hilo: pues queda claro lo que yo pienso, al lector amante del Delphi le dejo a su criterio los argumentos adjuntos. Si Ud. piensa que el uso de éstos es el adecuado talvez tenga razón y yo sea (como que si soy) un paranoico ahorrador de bits. El unicode sirve y mucho, pero es aplicable solo en aplicaciones como el µTorrent en las que todo el mundo necesita un archivo de idiomas... y 0j0 que es un archivo adjunto, en ningun momento dejaron al usuario la posibilidad de usar un ResHacker como comentaba en otro post.

Programas utilizados para el análisis: Delphi 6 & 7SE, mew11 SE v1.2, ResHacker 3.4, upx 2.03w, Visual Estudio 2005, Güindos eQuispe & Vista Ultimate.


Saludos afectuosos amigos de Club Delphi, y lleguemos como alguien decía: lejos !!!

¡Ah caray, muy impresionante! Pero ¿sabes? Sigues hablando de seguridad y no has dado un sólo argumento al respecto. Ahora, si te interesa mucho el tamaño de tus aplicaciones, creo que Delphi no es la herramienta que necesitas, a menos- claro -que decidas renunciar a la VCL, pero entonces tampoco estoy muy seguro que valga la pena.

// Saludos

Uppps
 

Amigo Roman, quito la palabra seguridad y la dejo con integridad... pero ese no es el punto y lo dije N veces.

Mi herramienta SI e Delphi. Para aplicaciones normales a grandes me funciona super la VCL, para pequeñas hago mis propios formuilarios con APIs y cosas por el estilo.

PD: Algo que me encanta del Delphi a comparacion con otros lenguajes es que puedo meterle assembler.

Yo sé que tu herramienta es delphi. Pero es que a lo largo de este hilo has expresado una visión muy particular acerca de porqué a tí no te gustan los recursos, y tus argumentos van por el tenor de

- seguridad
- tamaño
- compresión

Lo primero ahora le llamas integridad, pero eso no cambia las cosas. La "pelea" no es por terminología y si alguien cambia los ítems del menú por insultos pues qué mal por ese alguien pero nada tiene que ver con los recursos en sí. Tamaño y compresión van por la misma línea: tamaño. Y ahí es donde ironicé sobre lo de la vcl. No digo que haya que despreocuparse totalmente por el tamaño (hablo de software :D), pero tampoco es algo que deba quitarnos el sueño en la mayoría de ocasiones. Si nos lo quitase, entonces, realmente usar la vcl sería prohibitivo.

// Saludos

last?
 

Bueno, estoy algo cansado de defender una posición que al parecer es totalmente intrascendente para ustedes, pero de cosas como esas esta plagado mi pequeño mundo. He argumentado en el #34 todo lo que me parece valedero... pero hasta ahora no le veo puntos a favor del uso de tales ResourceStrings por parte suya, uds. defienden a los ResourceStrigns pero quiero posiciones argumentadas (repito). Y si no, lo dejo como una humilde opinión mía. :o

Saludos.