Visual Basic Foro
Programación => Visual Basic 6 => Mensaje iniciado por: cobein en Mayo 29, 2012, 05:23:30 pm
-
Hola, esto mas que una pregunta es para despotricar un poco con respecto a los decimales, como todo saben dependiendo de la configuracion regional se utilizan dintintos simbolos para separar los decimales (normalmente la coma o el punto y viceversa para los miles) bueno hoy haciendo un programa me tope con una situacion muy molesta la cual origino este post. El VB utiliza el simbolo predeterminado del sistema (en este caso la coma), ahora me encontre con que el mysql me devuelve los valores con un PUNTO (la base utiliza columnas del tipo varchar porque hay valores mixtos), bueno esto no parece ser un problema puedo reemplazar este punto con una coma y listo o mejor aun, reemplazar lo que me devuelve la base de datos con el simbolo predeterminado del sistema! (todo esto es necesario porque necesito realizar computos) .
Hasta ahi genial, una conversion y listo.... Pongo a correr el programa y ahi me encuentro con una sorpresa que me encabrono, algunos de estos valores se procesan posteriormente utilizando VBScript y adivinen que? el VBScript usa PUNTOS para separar los decimales (ignorando completamente la configuracion del sistema) asi que.. a pasar los separadores de lo que sea a PUNTO! increible, la verdad este tipo de cosas que hace hervir la sangre y mejor ni empiezo a hablar de las fechas.. dd/mm/aa ... mm/dd/aa .. aa/mm/dd
En fin, ahora tengo una linda coleccion de funciones para reemplazar un caracter que deveria ser unico y transparente a nivel programacion.
Saludos
-
si este tema es terrible, lo de las fechas ayer me hizo perder 3 horas donde trabajo, porque un webservice usa la configuracion de windows, pero el IIS usa otra, usa la del framework del asp.net, al final lo solucione con un archivo de configuracion que tienen para ahi decirle que configuracion usar, pero te hace renegar horas al pedo, lo del punto tambien, por ejemplo si tenes un webservice y usas punto, despues cuando lo ejecutas en el IIS usa la coma en ves del punto y tenes que reemplazarla sino tiran error los inserts, o sea en diferentes lugares usa diferentes cosas, siempre este tema fue penoso para los programadores.
la solucion siempre esta, o sea es algo que se puede solucionar, como vos decis haciendo funciones que reemplazen y listo, pero no deberia ser asi, como puede ser que 2 productos del mismo fabricante funcionen diferente en el mismo sistema, si yo defino en el sistema el punto, porque carajo el IIS usa la coma.
-
Me adhiero a su molestia muchachos!! siempre hay que renegar con este tema del formato!!!!
-
Pongo mi adhesión en esta causa, es muuuuuuuuuuy molesto el asunto, sobre todo y como mencionó Cobein, de que el VB trata de una forma, y el S.O. de otra.
Si alguien tiene una solución, digamos un poco Ortodoxa, o tal vez una metodología aunque sea lógica de como tratar el asunto, se agradecerá.
Besos a todos ;)
-
A mi me pasó algo similar con un cliente y concluyo que hasta cierto punto la solución pasa por una decisión política.
Habían dos personas, el clienta A y el cliente B, el cliente A tenia mi sistema y el B tenia otro sistema. El cliente A compro la empresa del cliente B. Toda el personal de la empresa B estaba muy acostumbrado a su sistema y su forma de trabajo, pues cuando yo llegué y ya que soy medio peleandero y patea tableros le puse a mi cliente en la posición de decidir si:
1.- Migramos la data del sistema B para implementar alli mi sistema (eso implicaba mas venta de licencias)
2.- Obligar al programador a que cambie varias cosas como moneda de valorizado, el famoso formato de fecha ya que el usaba para todo MM/DD/YYYY cuando siempre ha sido mejor usar YYYY/MM/DD, la coma por el punto ya que usaba la configuración regional de windows...y windows configurado como Español(España) cuando estamos en Perú!!!, uso de mayúsculas y minúsculas y otras lindesas mas.
3.- Delegar este problema nombrando a un jefe de sistema para que el concilie y consolide toda esta vaina.
4.- Trabajar con un nuevo soft que actue como consolidador (de consolidado no de consolador), osea se conecte a mi BD y saque cierta info, se conecte a la BD del B y saque cierta info, la procese y la muestre "sumada"... esto por cierto le salia mas caro.
Por supuesto que me fue fácil convencerlo porque a pesar de mis engreimientos el me aceptó todo mas que nada porque me sé sus cochinadas y se las protejo (shhhh) y lo que logré en los casi primeros 6 meses fue standarizar la info mientras obligaba al personal del B a practicar con mi soft paralelamente y en ese ínterin les demostraba a ellos que el mio era mejor (manipulación total).
A lo que quiero llegar es que efectivamente es como un nabo en el trasero encontrarse dentro de un mismo entorno con estos pequeños detalles que generan grandes molestias y si está en poder de uno tratar de uniformizar todo (no a las Torres de Babel), sino no nos fuera posible... caballero no mas a crear funciones de conversión.
A la fecha el sistema del B ya no existe, todos los usuarios conocen 1 solo sistema y la BD en ambas tiendas es una sola porque geográficamente están separadas por 200 metros y no había ningún problema en tender red local entra ambas, el cliente se siente dios sentado en su oficina viendo gráficas de varios temas por cada tienda... bueno creo que me estoy saliendo del tema.. alli lo dejo.
Saludos
-
Bien, siguiendo con esto... Hoy me tope con Val, normalmente al utilizar un valor cargado en un textbox utilizo Val para evitar errores pero hoy me di cuenta que val solo reconoce como separador de decimales a el PUNTO siendo que el sistema utiliza la coma.
Esto obviamente provoca problemas, si utilizo val("2,2") me devuelve 2 y si utilizo CDbl("2,2") obtengo 2,2 ahora mi problema es que no quiero utilizar CDbl porque si hay algun caracter invalido da error (no es flexible como Val) asi que a hacer OTRA funcion!!
Saludos
-
HOLA!!!
Genial! , vamos a armar un Val Alternativo, hoy me pongo a ver eso.
GRACIAS POR LEER!!!
-
Bien aca hice un modulo para arreglar el problemita que tengo con VAL.
'---------------------------------------------------------------------------------------
' Module : mVal
' Author : Cobein - cobein27@gmail.com
' Date : 07/06/2012
' Purpose : Fix issue using VAL on a system with comma as a decimal separator.
' Native VAL will be overridden by this function
'---------------------------------------------------------------------------------------
Option Explicit
Private Const LOCALE_SDECIMAL As Long = &HE
Private Declare Function GetLocaleInfo Lib "kernel32" Alias "GetLocaleInfoA" (ByVal Locale As Long, ByVal LCType As Long, ByVal lpLCData As String, ByVal cchData As Long) As Long
Private Declare Function GetThreadLocale Lib "kernel32" () As Long
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)
Private m_sSeparator As String
Private m_bInitialized As Boolean
Private Sub Init()
m_sSeparator = GetDecimalSeparator
m_bInitialized = True
End Sub
Public Function Val(sVal As String) As Double
If Not m_bInitialized Then Init
Val = VBA.Conversion.Val(Replace(sVal, m_sSeparator, "."))
End Function
Private Function GetDecimalSeparator() As String
Dim sBuff As String
Dim lLen As Long
sBuff = Space$(260)
GetDecimalSeparator = "."
lLen = GetLocaleInfo(GetThreadLocale, LOCALE_SDECIMAL, sBuff, 260)
If Not lLen = 0 Then GetDecimalSeparator = Left$(sBuff, lLen - 1)
End Function
-
HOLA!!!
:P muy buena, yo me estaba liando con bytes y select cases XD
GRACIAS POR LEER!!!