Autoit.ES

Publicado: **08 Nov 2011, 09:35**

Lo de la velocidad es cosa de probarlo, a menos que estés sacando texto en un TextEdit, por ejemplo, puede que no se note la diferencia.
El ejemplo del diccionario no lo puse sólo por lo del multilenguaje, en realidad me interesaba más mostraros el asunto del diccionario, porque en otras circunstancias también podría ser muy útil.

En el caso del multilenguaje (¿quién dijo que estaba "solucionado"?

) se me ocurre otra posibilidad bastante eficiente:
Crear directamente variables AutoIt.

Es la idea de usar nombres clave para las cadenas, el nombre se usa para el nombre de la variable, y la cadena obviamente es su valor.
Así si en el archivo de idioma nos encontramos por ejemplo:
txtTabSheet1=Archivo

En código haremos:
Assign("txtTabSheet1", "Archivo", 2)
(el 2 es para que cree la variable con ámbito global)
Notad que he cambiado el nombre de la cadena para que no coincida con la variable del tabsheet. Lógicamente al estar usando variables tenemos que asegurarnos de que no usamos claves que ya sean variables en nuestro programa.

Luego a la hora de usar la variable hay dos opciones. La normal no nos interesa demasiado porque es casi lo que tenemos:
$TabSheet1 = GUICtrlCreateTabItem(Eval("txtTabSheet1"))
Bueno, sí que nos interesa porque es MEGARÁPIDO, en lo que no se gana mucho es a la hora de usar las cadenas, pues en este caso en vez de la función _bpi() o el acceso al diccionario usamos Eval().

Pero el código aún se puede hacer más simple usando directamente la variable. En principio no se puede hacer porque como la variable no está declarada (se crea en tiempo de ejecución con Assign, no en la compilación) el compilador da error cuando intentas usar esas variables.
Así que para solucionarlo lo mejor es: crearlas, naturalmente

No es problema porque sabemos qué cadenas usamos en el programa, y encima la declaración explícita nos da la opción de dar ya los valores del idioma por defecto.

Así hacemos:
Global $txtTabSheet1="Archivo" ;valor por defecto
Assign("txtTabSheet1", "File") ;se ha leído el idioma inglés
$TabSheet1 = GUICtrlCreateTabItem($txtTabSheet1) ; ¡se usa la variable directamente!

(ya no hace falta el tercer parámetro en Assign(), pues ya hemos creado la variable como global)

Naturalmente el Assign no se hace directamente, sino que como estamos leyendo el archivo de idioma estaremos usando variables en un bucle:
Assign($clave, $valor)
Si alguna clave no existe en el archivo de idioma no será reasignada, con lo que se usará el valor por defecto.

Por supuesto para las cadenas multilínea o con textos insertados sigue haciendo falta usar StringFormat(), si a nadie se le ocurre una manera mejor.

Publicado: **09 Nov 2011, 20:05**

A ver si soy un poco o un mucho torpe.

La función Assign ¿qué diferencias/ventajas tiene sobre $a=un valor.?

EDITO: MUY TORPE, entiendo que el uso de Assign es para poder hacer el bucle que comentas, Assign($clave,valor), cosa que no se podría hacer de otro modo

Publicado: **10 Nov 2011, 12:21**

Con Assign puedes tener variable el nombre de la variable.
En la declaración y/o asignación directa el nombre debe saberse en tiempo de compilación.

Intentar crear $var1, $var2 y $var3 de la siguiente manera, como os he visto intentar usar, es una barbaridad:

Código: Seleccionar todo

For $i = 1 To 3
	$var & $i = "tengo valor " & $i
Next

Pero sí se puede hacer con Assign:

Código: Seleccionar todo

For $i = 1 To 3
	Assign("var" & $i, "tengo valor " & $i)
Next

Pero no podremos usar esos nombres de variable directamente porque al declararse en tiempo de ejecución el compilador dará error, para eso se usa Eval:

Código: Seleccionar todo

For $i = 1 To 3
	ConsoleWrite("$var" & $i & " vale: " & Eval("var" & $i) & @CRLF)
Next

Pero esto no ocurre con el tema del programa multilenguaje, pues como sabemos qué cadenas vamos a usar las podemos declarar primero (de hecho podemos aprovechar y darles ya el texto por defecto), y entonces el compilador no da error y las podemos usar después directamente, sin Eval:

Código: Seleccionar todo

Global $var1, $var2, $var3
For $i = 1 To 3
	Assign("var" & $i, "tengo valor " & $i)
Next
ConsoleWrite($var1 & @CRLF)
$var2 = $var2 & $var3

Publicado: **11 Nov 2011, 19:58**

Vale. Creo que está entendido. A ver si lo puedo aplicar...

Publicado: **14 Nov 2011, 10:15**

La función Assign ¿qué diferencias/ventajas tiene sobre $a=un valor.?

A ver si me he explicado bien. Assign normalmente no es necesario, si sabes el nombre de la variable es infinitamente mejor usar el formato
$a = "un valor"

en vez de
Assign("a", "un valor")

Assign sí es interesante cuando el nombre de la variable es... variable

Assign($nombre_de_variable, "un valor")
El valor también podría ser variable, naturalmente.

Eso es lo que tenemos en el caso del multilenguaje, los nombres los tomamos del archivo de idiomas, son las claves de las cadenas traducibles.
Como decía en el comentario anterior, para que sea totalmente cómodo manejarlas (y quitar de enmedio el Eval) es necesario declararlas explícitamente, pero eso no quiere decir que vayamos a usar Assign directamente sobre nombres concretos de variable. De hecho cuando decía que se podía aprovechar la declaración para definir la variable con la cadena en el idioma por defecto, no estaba diciendo que se usara Assign, sino que se asignara directamente.
El Assign es para el bucle que lee las cadenas desde el archivo de idiomas.

Publicado: **14 Nov 2011, 21:25**

Pues he modificado un poco las pruebas que había hecho, con las indicaciones aportadas, y el resultado está en el archivo que subo.

PruebasIdioma_20111114_2115.zip: Código.au3 y archivos.txt de idioma.; (2.89 KiB) Descargado 113 veces

Al no definirse las variables directamente, al ejecutar Au3Check devuelve multitud de WARNINGs así como un ERROR con $tForm1, aunque permite ejecutarse el código.

Saludos.

EDITO: Ayer subí el archivo rápido, y no comenté que, además de los WARNINGs de Au3Check, es curioso que, al cambiar de idioma en el COMBO1, funciona todo correctamente (los cambios de textos) excepto el $Label1 que, aunque cambie a español el Combo, se mantiene el texto en inglés. He probado a devolver por MsgBox el contenido y éste sí lo devuelve en español,... ¿?

Publicado: **15 Nov 2011, 10:21**

Claro, eso ya lo he comentado, tienes que leerte más detenidamente el rollo que he soltado

Si no declaras las variables te dará warnings y puede que algún error dependiendo de cómo se usen las variables. Si no se declaran y se crean directamente con Assign() entonces tienes que usar Eval() para leerlas.
Para que no ocurra eso hay que declararlas explícitamente, entonces se pueden usar sin Eval().

Por cierto, has estructurado el código de una forma extrañísima, con funciones partiendo el código principal y bastantes includes en medio del código...
Lo normal es poner los includes y otras directivas al principio (en realidad da igual donde los pongas porque los lee enteros estén donde estén, incluso dentro de un condicional que no se vaya a ejecutar), luego el código principal, y finalmente las funciones. No es obligatorio pero aumenta mucho la legibilidad.

Otro por cierto

, las matrices $aRecordsD y $aRecordsU ya no hacen falta, quítalas y simplificas bastante el código (en el momento de asignar las variables puedes usar directamente $array.

Sobre los errores...
.- No puedes actualizar $Form1 con GUICtrlSetData porque no es un control. Para cambiar el título tienes que usar... WinSetTitle(), que raro, ¿no hay un GuiSetTitle?
.- El problema de $label1 es que se llaman igual el control y su texto, cámbialo como has hecho con los demás a $tLabel1 (con la "t") y no colisionará.

Publicado: **15 Nov 2011, 13:31**

Como siempre, ¡gracias por la explicación!

La estructuración del código es porque es una prueba y he ido escribiendo conforme se me ocurría (perdón). Lo que pasa es que empiezas con un simple input, un array, un msgbox,.... y al final te lías y acabas haciendo un mini-programa

Echo un vistazo a las notas e intento aplicarlas.

Por cierto, lo del $array, tienes toda la razón, pero ya sabes que de La Puerta del Sol a La Puerta del Sol, se puede ir pasando por Burgos

Publicado: **15 Nov 2011, 14:06**

He "aseado" un poco el código, ya que parece que estamos ante un posible código-útil

He unificado la carga de idioma defecto y usado en una única función CargaIdioma($ArchIdioma)

Código: Seleccionar todo

; ------------------------------------------------------------------------------------
; Uso de idiomas utilizando ideas del foro Autoit.es (Ximorro, Jamaro Nov-2011)
; ------------------------------------------------------------------------------------
; http://www.emesn.com/autoitforum/viewtopic.php?p=12225#p12138
; http://www.emesn.com/autoitforum/viewtopic.php?f=12&t=2938&p=12124&hilit=idioma#p12057
; ------------------------------------------------------------------------------------

; Includes
#include <file.au3>
#include <array.au3>
#include <ButtonConstants.au3>
#include <ComboConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <TabConstants.au3>
#include <WindowsConstants.au3>


Global $Form1, $Tab1, $TabSheet1, $TabSheet2, $TabSheet3, $TabSheet4, $Button1, $Button2, $Button3, $Button4, $Combo1,$Label1,$Label2
Global $tForm1, $tTabSheet1, $tTabSheet2, $tTabSheet3, $tTabSheet4, $tButton1, $tButton2, $tButton3, $tButton4, $tLabel1
Global $mensaje, $Titulo, $error1, $textolargo, $Nombre, $Apellido, $Profesion

; -------------------- INICIO CARGA DE IDIOMAS --------------------
; Se define los archivos de idioma.
Global $ArchIdiomaPpal=@ScriptDir &"\"&"leng_sp.txt"	; Archivo de idioma que se utiliza por defecto, en caso de no existir alguna definición en el idioma seleccionado
Global $ArchIdiomaUsado=@ScriptDir &"\"&"leng_en.txt"		; Archivo de idioma seleccionado
Global $aRecords			; datos leidos del archivo de idioma

; Se carga los idiomas Defecto y Usado. De esta manera el idioma "usado" sustituye al "defecto" en el
CargaIdioma($ArchIdiomaPpal)
CargaIdioma($ArchIdiomaUsado)
; -------------------- FIN CARGA DE IDIOMAS --------------------



#Region ### START Koda GUI section ### Form=C:\Documents and Settings\Usuario\Mis documentos\Javier\AutoIt_Archivos\_XMLDomWrapper\MiValenbisi\PruebasIdioma\Prueba_Idioma.kxf
	$Form1 = GUICreate("Form1", 624, 450, 192, 114)
	$Tab1 = GUICtrlCreateTab(40, 30, 541, 381)
	$TabSheet1 = GUICtrlCreateTabItem("TabSheet1")
	$Button1 = GUICtrlCreateButton("Button1", 180, 260, 261, 61)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	$Label1 = GUICtrlCreateLabel("Label1", 100, 90, 436, 36)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	$Label2 = GUICtrlCreateLabel("Label2", 100, 140, 436, 36)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	$TabSheet2 = GUICtrlCreateTabItem("TabSheet2")
	$Button2 = GUICtrlCreateButton("Button2", 200, 270, 221, 61)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	$TabSheet3 = GUICtrlCreateTabItem("TabSheet3")
	$Button3 = GUICtrlCreateButton("Button3", 190, 280, 221, 61)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	$TabSheet4 = GUICtrlCreateTabItem("TabSheet4")
	$Button4 = GUICtrlCreateButton("Button4", 210, 290, 201, 51)
	GUICtrlSetFont(-1, 8, 400, 0, "Arial")
	GUICtrlCreateTabItem("")
	$Combo1 = GUICtrlCreateCombo("", 440, 0, 131, 25, BitOR($CBS_DROPDOWN,$CBS_AUTOHSCROLL))
	GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###


; --- Modificación del GUI ---

	GUICtrlSetData($Combo1, "leng_en.txt|leng_sp.txt", "leng_en.txt")	; Valores de los idiomas en el combo
	ActualizaTextos()	; Se deja el GUI con los nombres creados en KODA y con esta función se actualiza los textos.

; --- Fin Modificación del GUI ---

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $Button1, $Button2, $Button3, $Button4
			Exit
		Case $Combo1
			$ArchIdiomaUsado=@ScriptDir &"\"&GUICtrlRead($Combo1)
			ConsoleWrite(@ScriptLineNumber & " - " & "El lenguaje usado actual es: " & $ArchIdiomaUsado & @CRLF & @CRLF)
			CargaIdioma($ArchIdiomaUsado)
			GUISetState(@SW_SHOW)
			ActualizaTextos()
	EndSwitch
WEnd


Func ActualizaTextos()
	WinSetTitle($Form1,"",$tForm1)	; El nombre de la ventana no se puede cambiar con GuiCtrlSetData
	GUICtrlSetData($TabSheet1,$tTabSheet1)
	GUICtrlSetData($Button1,StringFormat($tButton1,$tTabSheet1))
	GUICtrlSetData($Label1,StringFormat($mensaje,$Titulo,$tLabel1,$error1))
	GUICtrlSetData($Label2,StringFormat($textolargo,$Nombre,$Apellido,$Profesion))
	GUICtrlSetData($TabSheet2,$tTabSheet2)
	GUICtrlSetData($Button2,StringFormat($tButton2,$tTabSheet2))
	GUICtrlSetData($TabSheet3,$tTabSheet3)
	GUICtrlSetData($Button3,StringFormat($tButton3,$tTabSheet3))
	GUICtrlSetData($TabSheet4,$tTabSheet4)
	GUICtrlSetData($Button4,StringFormat($tButton4,$tTabSheet4))
EndFunc

Func CargaIdioma($ArchIdioma)
	; Lee el archivo de texto guardándolo en una matriz
		If Not _FileReadToArray($ArchIdioma,$aRecords) Then
		   MsgBox(4096,"Error", " Error leyendo archivo a Matriz       error:" & @error)
		   Exit
		EndIf
		;_ArrayDisplay($aRecordsUsado,@ScriptLineNumber &" Elementos leidos")

	; Separa los datos leidos del archivo clave=texto
		For $x=1 to UBound($aRecords)-1
			$array=StringSplit($aRecords[$x],"=")
			Assign($array[1],$array[2],2)	; Crea la variable de clave/valor
				ConsoleWrite(@ScriptLineNumber & " - " & $array[1] & " - " & @tab & $array[2] & @crlf)
		Next
		;_ArrayDisplay($aRecordsU,@ScriptLineNumber &" Elementos separados")

EndFunc

He seguido dejando sin definir las variables, por lo que sigue apareciendo los WARNING... (EDITADO y ya puesto)
Supongo que la única manera es creando con Global o Dim TODAS las variables, no pudiéndose hacer automáticamente conforme lo lea del archivo de idioma....

Publicado: **16 Nov 2011, 09:31**

¡Pues claro que es un código útil! Es representativo como lo son el de archivo INI, matrices o el de diccionario. Son diferentes maneras de hacerlo, cada uno que coja la que más le guste, ahora no se puede decir que no hemos puesto soluciones.

La verdad es que este método me gusta, el único inconveniente es que hay que tener mucho cuidado con que las claves no coincidan con otros nombres de variables (antes era muy cómodo llamar a la clave de $label1 como label1, pero ahora no se puede porque generarían la misma variable). Pero el hecho de manejar luego las claves como simples variables es una gozada, y además más rápido que eso no hay nada, ni un diccionario programado en ensamblador

La idea fue mía y el código tuyo, ¿créditos compartidos?

Es mejor declarar las variables con Global como has hecho, no hay que usar Dim, eso existe por razones históricas y los desarrolladores recomiendan usar siempre Global o Local, según corresponda.

Una cosa: declara las variables antes de las llamadas a CargaIdioma(). AutoIt lo pasa pero no debería, las estás usando antes de declararlas...
Ah, y ya no hace falta el tercer parámetro de Assign, pues las estamos declarando explícitamente.

¿A qué es fácil hacer así el código?
Además pensando de esta manera puedes crear interfaces multilingües muy fácilmente aunque en principio no quieras hacerla. Simplemente debes tener todos los textos en variables, y en un futuro si quieres hacerlo multilingüe las reasignas con Assign de esta manera y no hay que cambiar NADA del código original, sólo añadir el código que reasigna las variables con el nuevo lenguaje.

La otra mejora que decía es poner ya los valores por defecto a las variables en el código, lo que los ingleses llaman "hard coded". En plan:
Global $Titulo = "Mi GUI sobre idiomas"
Global $tLabel1 = "Mi etiqueta"
Global $error1 = "Cliente no encontrado"

Esto tiene la ventaja de que no hay que leer dos idiomas al principio, sólo uno si hay que cambiarlo. Y lo más importante, que funcionará incluso aunque falte el archivo de idioma por defecto.
Además sería la manera de hacerlo si no vamos a hacerlo multilingüe en principio, pero queremos facilitarnos la vida si en un futuro lo queremos traducir, como digo sólo habrá que añadir el código que lee los archivos alternativos de idiomas y modificar las variables con Assign (bueno, y si queremos no hacerlo sólo al principio y cambiar un GUI ya abierto hay que currárselo más, como has hecho tú, pero sigue siendo añadir código, el programa original no hay que tocarlo).

Que por cierto, eso de cambiar el GUI una vez abierto es una currada que has hecho que no suelen hacer ni los profesionales, si os fijáis muchas veces cuando cambias el idioma te dicen que los cambios se realizarán cuando cierres y vuelvas a abrir el programa.

Publicado: **16 Nov 2011, 10:38**

Al principio hacía mención a los hilos del foro, pero ya están puestos explícitamente los apodos

Ya está modificado, con la reubicación de las variables en su correcto lugar.

La verdad es que a mí me parece una manera muy sencilla de utilizar los idiomas, y, efectivamente, es fácil "internacionalizar" cualquier programa que tengamos ahora.
El siguiente paso era, como comentas, declarar directamente las variables con su valor en el lenguaje por defecto. Sería un problema perder el archivo de idioma. De echo, en MiBiciPública, todos los valores por defecto están directamente en el código y automáticamente genera un INI en caso de que éste no exista.

Que por cierto, eso de cambiar el GUI una vez abierto es una currada que has hecho que no suelen hacer ni los profesionales, si os fijáis muchas veces cuando cambias el idioma te dicen que los cambios se realizarán cuando cierres y vuelvas a abrir el programa.

Me pareció sencillo y práctico. Tras utilizar KODA en otros programas, y tener que ir modificando luego parte del código generado, pensé que mejor dejarlo como lo da KODA y luego asignar los valores y textos de los controles tras la creación del GUI.

¡Saludos!

Publicado: **17 Nov 2011, 09:51**

Es una lástima que KODA no permita poner variables de AutoIT en la generación del GUI, por ejemplo para esto de los textos.
Yo suelo usar KODA para crear el GUI inicial, pero luego siempre acabo retocándolo a mano, y una vez hago eso ya no vuelvo a KODA porque normalmente pierde cosas :-(

Precisamente ahora estoy haciendo un programa para hacer unas cosas en archivos DXF, tengo el GUI en KODA pero me hago una lista de las cosas que tendré que cambiar cuando ya tenga el GUI bastante claro, cuando haga esos cambios no podré volver a KODA... No es un GUI muy complicado y la lista ya es así de larga :-(

Código: Seleccionar todo

#cs
Modificar después de Koda:
.- Quitar StaticConstants.au3, EditConstants.au3, en realidad no se usan
.- Posición centrada de formulario (-1,-1 en coordenadas)
.- Quitar texto de ejemplo de $lblEntrada (será variable)
.- Quitar los $WS_GROUP de los botones
.- Añadir WS_EX_ACCEPTFILES al formulario y estado $GUI_DROPACCEPTED al editBox de entrada: GUICtrlSetState(-1, $GUI_DROPACCEPTED)
.- Negrita en los títulos de los grupos: GUICtrlSetFont(-1, 8, 800, 0, "MS Sans Serif") (¡si se pone en KODA afecta a todos los subcontroles!)
.- Quitar el GUICtrlCreateGroup("", -99, -99, 1, 1) del primer grupo (ya se cierra al crear el segundo)
.- Partir las líneas de creación de combos a algo más manejable.
.- Path de Windows con @WindowsDir en los iconos: @WindowsDir & "\System32\shell32.dll"
#ce

Pero una cosa sí os recomiendo. En este caso jamaro no se ha preocupado porque es un simple ejemplo, pero es bueno dar nombre a los controles que se van a referenciar. Es importantísimo para que otros sigan el código y para que vosotros mismos podáis modificarlo en el futuro sin estar investigando qué diablos era aquéllo de Input5, por ejemplo.

Si en vez de GUICtrlSetData($Input5, $resultado) encuentras GUICtrlSetData($InpNombreUsuario, $resultado) ¿a que está más claro y no hace falta irse a la creación del GUI para investigar qué ContolInput era ese?
Lo mismo si no sabes cuál era el botón $Button8, si se llama $btnAyuda o $btnCerrar está claro, ¿verdad?

Pues con KODA se pueden cambiar los nombres de los controles, no hace falta dejar el nombre por defecto. Se trata de cambiar la propiedad Name. Si ahí en un botón pones por ejemplo btnAbreOpciones (sin el carácter dólar), al generar el código KODA pondrá:
$btnAbreOpciones = GuiCreateButton(...)

Además podemos quitar el nombre para los controles que no se van a referenciar, por ejemplo para los label que no se van a modificar, sólo se crean con su texto inicial y no se vuelve a tocar. En estos casos borramos lo que pone en propiedad Name (KODA habrá puesto algo tipo Label2). Entonces el nombre está vacío pero KODA le da un nombre interno tipo <Label[2]> que podemos ver arriba en el Object Inspector o en en el Object TreeView. Para estos casos KODA no crea variable en el código generado, que es lo que queremos, es decir, no crea una variable $label2 que no vamos a usar nunca con:
$label2 = GuiCtrlCreateLabel(...)
sino que directamente crea el control sin referencia:
GuiCtrlCreateLabel(...)

Hala, si no sabíais que se podían hacer estas cosas en KODA ya lo sabéis. Y cuando hagáis GUIs, da igual que sea con KODA o a mano, poned nombres significativos a las cosas, os facilitarán la vida en el futuro, lo digo por experiencia.
Y la misma regla se aplica a las demás variables y nombres de funciones, por cierto. Si en un programa que hiciste el año pasado ves _Func1($var1) habrá que investigar qué hace, si ves _PidePassword($usuario) seguramente recuerdes para qué la hiciste

Publicado: **17 Nov 2011, 11:01**

Efectivamente, se trataba de un ejemplo rápido. De echo, ni siquiera los textos del ejemplo de los idiomas tiene mucho sentido

De todos modos, siempre está bien, recordar "buenas maneras" de organizar el código.

Autoit.ES

[SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación

Re: [SOLUCIONADO]Varios idiomas en una aplicación