Hola a todos. En un determinado campo quiero que el texto se introduzca en mayúsculas. He conseguido que esto suceda para caracteres normales, pero no para caracteres acentuados y la ñ. Para solventar ésto he creado el siguiente código:



El problema que me surge es que el valor de la posición que me da es: 1, 3, 5, 7, 11, ... Y no me proporciona el valor en mayúsculas con tilde.
Estoy trabajando con gambas 2.18 y Ubuntu 9.10. Gracias.

Hola

A mi me funciona esto y es más simple:



EDITO: Efectivamente no funciona para caracteres acentuados ni ñ....  

Seguiremos buscando un método más efectivo.


Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Buscando posibles soluciones al problema planteado he creado la siguiente función. Para calcular el index del valor en el array (intPosicion) ha que tener en cuenta que gambas (por lo que he deducido) contabiliza los caracteres con tilde como dos.



Saludos y Feliz Navidad.

Un poco tarde , pero ....:

Deberia quedarte así :



Yo lo probé , pero de la siguiente manera :

 
saludos

Hola

Citar:

Buscando posibles soluciones al problema planteado he creado la siguiente función. Para calcular el index del valor en el array (intPosicion) ha que tener en cuenta que gambas (por lo que he deducido) contabiliza los caracteres con tilde como dos.

gambas utiliza para los caracteres del código ASCII extendido el charset UTF-8. Este charset lo que hace es que a cada caracter no ascii le asigna dos bytes porque ocurre que ese código ascii extendido depende también de factores como el idioma y de hecho también se utilizan para traslación al chino o al árabe, etc.

gambas proporciona una solución para resolver este problema. La clase string.



Ahora con la clase string


 

Joder, no hay como saber....

Ojo con el ascii extendido. Esta clase string no es únicamente para este caso de mayúsculas/minúsculas. Es para cualquier operación de string corriente donde intervengan caracteres UTF-8.

Por ejemplo la función len te dará resultados incorrectos porque contará los bytes y el caracter UTF-8 ocupa dos. Habría que usar "string.len" para que diera resultados correctos.

Métodos de la clase string

Si no se tiene esto en cuenta te puedes encontrar con errores al hacer un left porque alguien metió un acento donde no se esperaba o al comparar dos strings que vea distintas cosas aparentemente iguales o cosas así. Cuidado con los strings procedentes de textboxes que puedan contener acentos o eñes.

 

Muy interesante esa clase String, la verdad, la de faena que te ahorra con el UTF8...
Se puede usar como base (p.e. el tema de string.len), siempre se ael juego de carácteres que sea, o solo para UTF-8 y para ASCII habría que usar len?

Hola
Verás el "problema" es que gambas utiliza UNICODE. Eso es algo muy bueno y avanzado. Habrás visto muchas veces que te dicen entre las ventajas de un nuevo programa que "ahora" es capaz de usar unicode. UTF-8 solo es una de las implementaciones de unicode. En particular la de 8 bits.

El problema a resolver es que cuando la informática se extendió hubo que buscar un sistema común para poder integrar alfabetos diversos y caracteres distintos. Se hizo una estandarización y se creó unicode que tiene su RFC correspondiente y describe un procedimiento común para todas las lenguas y se modificaron los estándares RFC para el correo electrónico para obligar a todo el mundo a utilizarlo.

Así que no es malo que gambas use unicode. Es bueno. Lo malo es que no todo es unicode y si comparas algo que es con algo que no es (aunque aparentemente sean iguales) tienes errores. Con el tiempo todo será unicode y ya no habrá ese problema.

Citar:

Se puede usar como base (p.e. el tema de string.len), siempre se ael juego de carácteres que sea, o solo para UTF-8 y para ASCII habría que usar len?

Unicode está basado como de costumbre en quienes mandan en estas cosas. Los primeros 128 códigos ASCII que son el código ascii puro y que es un invento americano no cambian para nada. Lo que varía es los 128 siguientes. La variación no supone únicamente cambio de caracteres (que depende del idioma local) sino de unos valores adicionales que informan de como se debe interpretar ese caracter. Por ejemplo el código ascii 200 en chino corresponde a una cosa y en hebreo a otra. En Español existe la Ñ y los acentos, ..., etc. Dije que en UTF-8 los caracteres del ascii extendido ocupan dos bytes. Eso es así para nosotros por lo general porque nosotros usamos caracteres latinos, pero los caracteres ideográficos (chinos, japoneses, coreanos, vietnamitas, ..., etc utilizan tres y creo que los de lenguas muertas (por razones científicas) y algún otro como el persa utiliza cuatro.

UTF-8 en la wikipedia

Respondiendo a tu pregunta: no paaa nada si usas siempre la clase string porque los 127 primeros caracteres son iguales en cualquier caso. Solo tienes que cuidar de que si quieres contar o comparar o lo que sea caracteres de los 128 siguientes uses la clase string. Lo que uses con los primeros 127 es indiferente porque son iguales.

 

Entonces, para ahorrarse sorpresas y tener que andar analizando si es ASCII o UTF-8, a usar la clase string!!!