A ver que os parece

[Casimiro Noteví]

Aunque eso también variará dependiendo de la zona/región/país, por ejemplo, el código postal o el teléfono no será igual en España, Perú o USA... supongo.

[[oscarac]]

me parece una buena idea...
siempre y cuando consideremos cuestiones inherentes a nuestra region o zona

[[José Luis Garcí]]

Pienso mejor en hacer un tipo estándar, porque podemos encontrarnos en un país y tener que mandar cartas, documentos etc a otros, pensar si el más largo de todos tiene 10 de ancho, no e mejor dejarlo a diez, que tener uno de 5 para España y de repente un cliente a mandar mercancía en XXXX y allí su equivalente tiene 10 de tamaño o cualquier otro campo. Por poner otro ejemplo yo vivo en Gran Canaria, que pertenece a España, por todo el país el impuesto es el IVA, exceptuando en mis islas que es el IGIC, la mayoría de los programas de la península suelen venir con el campo IVA, mientras que los programadores que conozco en la isla solemos usar un campo en la configuración que llamamos impuestos y donde ponemos el nombre de este, de esta manera sirve para las islas Canarias, para la península y para cualquier país, pero claro sólo en el impuesto, que pasara, con otros muchos campos???

[[newtron]]

El tema es que la configuración del campo dependerá muy mucho de la aplicación y el sector al que esté dirigida. En el ejemplo de los códigos postales ciertamente cambiarán en los distintos paises y lo suyo es que tuvieran una longitud suficiente para cubrir todas las posibilidades pero en mi caso en particular la gran mayoría de mis clientes usan códigos postales nacionales y ¿qué hago? ponerselo limitado a 5 dígitos y con una consulta de los mismos para que no se equivoquen. Si lo pusiera a 10 dígitos por si tuvieran (caso improblable) que necesitarlo me chillarían porque se equivocarían en la longitud del mismo y me dirían que se lo pusiera a 5 que es lo que usan.

El tema es peliagudo en ese sentido.

Saludos

[[José Luis Garcí]]

hola newtron, tienes toda la razón, no te discuto que la tengas, pero ahí es donde tenemos que entrar nosotros, debemos controlar esa situación, como, pues es una manera fácil si el país es España, limitamos la entrada dentro del onchange de su respectivo edit no permitiendo mas de 5 o 6 caracteres (si incluyes el punto o no) y en el onkeypress controlando si es un numero o el punto. Aprovecho y te lo planteo de la manera contraría, que diría el cliente si tuviese que mandar correspondencia a otro país con un alfanumérico de 10 dígitos, quien tendría que modificarlo a posteriorí, intenta verlo de eta manera

[[newtron]]

Cierto, si se diera esa circunstancia tendría un problema. Por ese motivo mi programa está preparado para hacer modificaciones particulares de los campos sin tocar el código del programa y mediante ficheros ini. Me explico. Siempre que llamo a un formulario en el formcreate se lee un fichero de texto asociado a ese formulario y en el que se pueden modificar las propiedades del campo, el tamaño, color, longitud, tipo (cadena, entero, fecha...), etc. De esta manera consigo que el cliente tenga una versión personalizada del programa sin que le afecten nuevas actualizaciones del ejecutable. Puedo cambiar las propiedades de los campos, eliminarlos, insertar nuevos, etc. en definitiva, crear una pantalla totalmente a medida sin tocar una linea de código. Igual esta idea le puede venir bien a alguien para sus programas.

Saludos

[Casimiro Noteví]

¿Y eso cómo lo solucionas en la BD?, quiero decir qué si hacen falta más campos o cambiarles el tipo, etc. ¿creas la BD una vez definidos los campos en el .ini?