moneda

Hola leonardo. No respondistes mi pregunta. Porque siendo un textbox tan
usado no lo exponen? Porque debemos perder tiempo programando? ¿Es acaso un
textbox numerico con 2 decimales diferente en pais A con el pais B? A eso me
refiero.
Por lo demas estoy de acuerdo contigo en las bondades de .net pero es
increible que para algo tan universal sea programado por nosotros. A eso me
refiero.
Saludos

"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:%

"Jose" escribió en el mensaje
news:

Hola Leonardo. Porque si es algo tan básico de usar en las aplicaciones
que desarrollamos microsoft no sacó ese control como en visual foxpro y
solo ajustar la mascara de separador de miles e indicandole que es
numerico con 2 decimales.
Hay que programar practicamente todo. Eso es lo que critico. Imagino que
hay muchisimos programadores preguntandose lo mismo. En vez de perder
tiempo programando ese control pues algo como el numericupdown pero
funcional al usuario. Funcional al usuario significa que el usuario
ingrese la cifra y separe automaticamente miles,millares etc Ademas si el
usuario pulsa el . decimal o la , decimal pues el cursor se mueva a la
parte decimal. Asi como en vfp. Si conoces de vfp sabes lo que te digo
sino te invito a que veas ese objeto en vfp.
¿No crees que se debe programar en cosas mas particulaes y específicas
para ahorrar tiempo?
Quizas por eso y otras razones la gente no cambia tan facilmente a .net
Un abrazo y espero tus comentarios.

Hola.

Por fin entiendo de que va tu pregunta.

Me parece que la cosa iba por algo como "@x, y GET z using f" :-)

Cada quien tiene su propia historia, y la historia condiciona el punto de
vista: en 1982 tuve mi primera exposicion a lo que despues seria xBase,
con dBaseII para CP/M. Y no me gustó. Y no me gustó por razones totalmente
opuestas a las que te llevan a criticar a VB.NET: tenía demasiadas cosas
"hechas", y era dificil adaptarlas a mi manera de hacer las cosas con
CBasic o Pascal. Para esa epoca, las capacidades de xBase eran las mas
elementales. Luego siguió la evolución con dBaseIII, Clipper y FoxPro, que
convirtió a xBase en un lenguaje de desarrollo profesional de altas
prestaciones. Pero para ese entonces, yo ya estaba "sumergido" en C y en
la programación a muy bajo nivel, de manera que nunca me pude interesar en
Fox, mas alla de reconocer su desarrollo en terminos formales.

Son muchas las cosas que .NET no trae: el Masked Edit Box, que estaba en
VB6 (y que nunca me convenció), no esta mas y una deformacion monstruosa
del DataGrid pretende reemplazar tambien al viejo y fiel MSFlexGrid.
Gracias a Dios, MS estuvo un tiempo regalando una coleccion de controles
de Component One, que traia un grid mas parecido al FlexGRid original, y
ese es el que uso para trabajar con Net.

Dependiendo de como conciba uno la programacion, NET puede ser
inmensamente atractivo o espantosamente repugnante. Aunque FoxPro, al
igual que el viejo VB6, tienen un soporte limitado para el desarrollo
orientado a objetos, la mayor parte de los desarrolladores en esos
lenguajes no utilizan esas caracteristicas. De manera que el hecho de
poder disponer de herencia, el uso de delegados y ahora los genéricos de
2005 no los entusiasman tanto como a quienes hemos dedicado los ultimos
años a tratar de establecer una metodología de desarrollo orientado a
objetos basados en VB6, por ejemplo. Aunque me molestan -igual que a todos
quienes migramos de cualquier otro lenguaje- la falta de ciertos recursos
que venian dados en mi lenguaje de origen, y aunque todavia no supero el
rechazo a la sobrecarga que implica la ruptura de capsulas funcionales en
tres o cuatro componentes (presentacion, contenido, estilos, seguimiento
["currency"]) separados, la riqueza de recursos constructivos de cualquier
lenguaje .Net es tan grande que despues de realizar el primer proyecto
sueño con algun dia implementar todas mis aplicaciones en la nueva
plataforma (aunque todavia no se como voy a lograr la mitad de las cosas
que tengo hechas en VB6).

Creo que el problema de la baja frecuencia de adopción tiene mas que ver
con la falta de confianza del publico en general hacia Microsoft. Los
programas desarrollados en COBOL a mediados de los sesenta, siguen
compilando sin cambios en cualquier compilador de hoy en dia. Igual pasa
con Java, C, FORTRAN o cualquier otro lenguaje utilizado profesionalmente.
Incluso un programa escrito en "C" clasico, debería compilar en C++
siempre que el autor haya tomado ciertas precauciones minimas, que de paso
se recomendaban en el libro de Kernighan y Ritchie. Microsoft tiene la
desafortunada costumbre de "menear la mata" cada tantos años, provocando
una revolución que deja fuera del mercado a un número considerable de
profesionales. La no compatibilidad de VB.NET con VB6, y la falta de una
herramienta de migracion efectiva, hizo que muchisimos desarrolladores
profesionales en VB, incluyendo muchos MVP (que, por supuesto, ya no lo
son), pasaran de VB a Java o Delphi. Productos de la competencia, como
RealBasic -que genera igualmente codigo para las Mac- tuvieron un auge
impresionante hace un par de años.

Pero no creo que los desarrolladores que condicionen su adopcion de las
nuevas tecnologías a la existencia o no de un text box especializado para
la lectura de números le preocupen para nada a Microsoft. Si no son
capaces de escribirlo en unas pocsa horas, no merecen ser tomados en
cuenta: quienes determinan si un lenguaje es o no adoptado son los buenos
programadores, y ningun buen programador se para ante esa nimiedad.

Salud!

"Jose" escribió en el mensaje
news:%

Hola leonardo. No respondistes mi pregunta. Porque siendo un textbox tan
usado no lo exponen? Porque debemos perder tiempo programando? ¿Es acaso
un textbox numerico con 2 decimales diferente en pais A con el pais B? A
eso me refiero.
Por lo demas estoy de acuerdo contigo en las bondades de .net pero es
increible que para algo tan universal sea programado por nosotros. A eso
me refiero.

Hola.

Imagino que dado el nivel de abstracción con el que el lenguaje fue
diseñado, implementar una especializacion del TextBox fue considerado
innecesario.

De todos los lenguajes que conozco, solo xBase tiene el @..GET..USING. ¿Por
qué no lo tienen FORTRAN, o "C" o COBOL?

Igual podrias preguntarte por qué no implementaron un motor de inferencias
como el que sirve de base a PROLOG, o la posibilidad de insertar codigo de
ensamblador en linea, como el que tenian casi todos los lenguajes de
Borland.

Tengo un control para la lectura de numeros, que se comporta de una manera
aceptable para la mayoría de los usuarios. Pero igual tu lo encontrarias
deficiente, y te gustaria que funcionara de otra manera. Imagino que alguien
en MS trabajó varias semanas desarrollando y probando el Masked Edit Control
que venia con VB6. Y a mi jamás me convenció, y preferí desarrollar mis
propios controles.

No respondí tu pregunta porque no tengo una respuesta. Y no tengo una
respuesta por la sencilla razón de que no me parece que la cuestion tenga
mayor importancia. Me irritó la (a mi juicio) porquería que hicieron con ese
engendro del datagrid, pero encontré una solución, más adaptada a mi estilo
de trabajo: problema resuelto.

A estas alturas, hay decenas de paquetes de controles disponibles para
VB.NET: desde los mas caros y sofisticados de Infragistics, Component One o
Farpoint hasta los gratuitos, igualmente de muy alta calidad.

Cuando diseñé mi primer sistema administrativo, incluí mas de ciento
cincuenta reportes intrinsecos en el paquete. El que me da de comer ahora
solo incluye alrededor de treinta. ¿Por qué? Por la simple razon de que la
mayoria de los cambios solicitados por los clientes del primer sistema se
referían a esos reportes: que no necesito está columna, o que le falta esta,
o que quiero agrupar por semanas, o que necesito conocer los saldos vencidos
de 90 a 120 dias. ¿Y qué hice? Simplemente le agregué un generador de
reportes, y cada quien que se haga los reportes que quiera sin estar
molestando. Al final, la mayoria de los reportes acabo haciendolos yo mismo,
o alguno de los distribuidores o tecnicos de soporte, pero no se pueden
quejar, porque la posibilidad de satisfacer sus necesidades esta en sus
manos, y si no la usan, tienen que pagar por ella. A estas alturas, el
paquete de distribución incluye más de mil reportes preelaborados, y cada
cliente puede tomar lo que le guste y descartar el resto.

Sinceramente, no creo que la omision de un control para la lectura de
numeros figure entre los fallos que puedan achacarse a .NET. Es una
deficiencia que se resuelve en no mas de un dia de trabajo: tal vez un poco
mas, si nunca has desarrollado un control de usuario. Pero se espera que un
buen programador en VB sepa como desarrollar controles de usuario, y la
experiencia de realizar el primero es un activo valiosisimo.

Salud!

Estoy de acuerdo Leonardo. Si ese datagrid es lo peor. Bueno si sabes de
sites con controles gratis te lo agradezco.
Es bueno contar con amistades como tu.
Un abrazo.

"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Jose" escribió en el mensaje
news:%

Hola leonardo. No respondistes mi pregunta. Porque siendo un textbox tan
usado no lo exponen? Porque debemos perder tiempo programando? ¿Es acaso
un textbox numerico con 2 decimales diferente en pais A con el pais B? A
eso me refiero.
Por lo demas estoy de acuerdo contigo en las bondades de .net pero es
increible que para algo tan universal sea programado por nosotros. A eso
me refiero.

Hola.

Imagino que dado el nivel de abstracción con el que el lenguaje fue
diseñado, implementar una especializacion del TextBox fue considerado
innecesario.

De todos los lenguajes que conozco, solo xBase tiene el @..GET..USING.
¿Por qué no lo tienen FORTRAN, o "C" o COBOL?

Igual podrias preguntarte por qué no implementaron un motor de inferencias
como el que sirve de base a PROLOG, o la posibilidad de insertar codigo de
ensamblador en linea, como el que tenian casi todos los lenguajes de
Borland.

Tengo un control para la lectura de numeros, que se comporta de una manera
aceptable para la mayoría de los usuarios. Pero igual tu lo encontrarias
deficiente, y te gustaria que funcionara de otra manera. Imagino que
alguien en MS trabajó varias semanas desarrollando y probando el Masked
Edit Control que venia con VB6. Y a mi jamás me convenció, y preferí
desarrollar mis propios controles.

No respondí tu pregunta porque no tengo una respuesta. Y no tengo una
respuesta por la sencilla razón de que no me parece que la cuestion tenga
mayor importancia. Me irritó la (a mi juicio) porquería que hicieron con
ese engendro del datagrid, pero encontré una solución, más adaptada a mi
estilo de trabajo: problema resuelto.

A estas alturas, hay decenas de paquetes de controles disponibles para
VB.NET: desde los mas caros y sofisticados de Infragistics, Component One
o Farpoint hasta los gratuitos, igualmente de muy alta calidad.

Cuando diseñé mi primer sistema administrativo, incluí mas de ciento
cincuenta reportes intrinsecos en el paquete. El que me da de comer ahora
solo incluye alrededor de treinta. ¿Por qué? Por la simple razon de que la
mayoria de los cambios solicitados por los clientes del primer sistema se
referían a esos reportes: que no necesito está columna, o que le falta
esta, o que quiero agrupar por semanas, o que necesito conocer los saldos
vencidos de 90 a 120 dias. ¿Y qué hice? Simplemente le agregué un
generador de reportes, y cada quien que se haga los reportes que quiera
sin estar molestando. Al final, la mayoria de los reportes acabo
haciendolos yo mismo, o alguno de los distribuidores o tecnicos de
soporte, pero no se pueden quejar, porque la posibilidad de satisfacer sus
necesidades esta en sus manos, y si no la usan, tienen que pagar por ella.
A estas alturas, el paquete de distribución incluye más de mil reportes
preelaborados, y cada cliente puede tomar lo que le guste y descartar el
resto.

Sinceramente, no creo que la omision de un control para la lectura de
numeros figure entre los fallos que puedan achacarse a .NET. Es una
deficiencia que se resuelve en no mas de un dia de trabajo: tal vez un
poco mas, si nunca has desarrollado un control de usuario. Pero se espera
que un buen programador en VB sepa como desarrollar controles de usuario,
y la experiencia de realizar el primero es un activo valiosisimo.

Salud!

"Jose" escribió en el mensaje
news:el1L$

Estoy de acuerdo Leonardo. Si ese datagrid es lo peor. Bueno si sabes de
sites con controles gratis te lo agradezco.
Es bueno contar con amistades como tu.

Hola.

Internet está llena de paginas que ofrecen controles gratuitos. Prueba a
introducir "Components NET" (sin las comillas) en Google, y comienza a
pasearte por ahi. En mi experiencia, si comparas el tiempo dedicado a
comparar diferentes controles, descargar el que te gustó, instalarlo y
aprender a usarlo -eso si no tiene fallos o torceduras que tengas que
encontrar o corregir- contra el tiempo y el esfuerzo que te lleva escribir
tu propio control, especialmente cuando se trata de controles simples como
el que nos ocupa, siempre es mejor hacerse uno sus propios controles.

Y los controles de usuarios deben ser simples (es mejor hacerlos uno mismo)
o especializados (no existen versiones disponibles, porque responden a un
requerimiento de nuestra aplicacion).

No creo que el DataGrid sea "lo peor". A mi, personalmente, no me gusta para
nada porque nunca pude aprender a sacar provecho de los controles enlazados
a datos. Y es innegable que el esfuerzo para aprender a usarla es muy
superior al de cualquiera de las versiones anteriores de cuadrículas
escritas por MS. Pero tambien es mucho mas flexible y poderosa que todas sus
predecesoras. Te sugiero que en vez de estar de acuerdo conmigo -que soy un
viejo esclerótico y recalcitrante- te propongas aprender a usarla bien:
probablemente te sirva mucho mas hacer eso que escuchar mi mala -y
parcializada- opinión (tengo que aprender a no hablar tanto).

Salud!

Aquí hay un "Numeric Edit Control" que a lo mejor te sirve, en cualquier
caso podría ser un buen punto de partida:

http://www.codeproject.com/cs/miscctrl/numedit.asp

Saludos:

Jesús López



"Jose" escribió en el mensaje
news:el1L$

Estoy de acuerdo Leonardo. Si ese datagrid es lo peor. Bueno si sabes de
sites con controles gratis te lo agradezco.
Es bueno contar con amistades como tu.
Un abrazo.

"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r
g> escribió en el mensaje news:

"Jose" escribió en el mensaje
news:%

Hola leonardo. No respondistes mi pregunta. Porque siendo un textbox tan
usado no lo exponen? Porque debemos perder tiempo programando? ¿Es acaso
un textbox numerico con 2 decimales diferente en pais A con el pais B? A
eso me refiero.
Por lo demas estoy de acuerdo contigo en las bondades de .net pero es
increible que para algo tan universal sea programado por nosotros. A eso
me refiero.

Hola.

Imagino que dado el nivel de abstracción con el que el lenguaje fue
diseñado, implementar una especializacion del TextBox fue considerado
innecesario.

De todos los lenguajes que conozco, solo xBase tiene el @..GET..USING.
¿Por qué no lo tienen FORTRAN, o "C" o COBOL?

Igual podrias preguntarte por qué no implementaron un motor de
inferencias como el que sirve de base a PROLOG, o la posibilidad de
insertar codigo de ensamblador en linea, como el que tenian casi todos
los lenguajes de Borland.

Tengo un control para la lectura de numeros, que se comporta de una
manera aceptable para la mayoría de los usuarios. Pero igual tu lo
encontrarias deficiente, y te gustaria que funcionara de otra manera.
Imagino que alguien en MS trabajó varias semanas desarrollando y probando
el Masked Edit Control que venia con VB6. Y a mi jamás me convenció, y
preferí desarrollar mis propios controles.

No respondí tu pregunta porque no tengo una respuesta. Y no tengo una
respuesta por la sencilla razón de que no me parece que la cuestion tenga
mayor importancia. Me irritó la (a mi juicio) porquería que hicieron con
ese engendro del datagrid, pero encontré una solución, más adaptada a mi
estilo de trabajo: problema resuelto.

A estas alturas, hay decenas de paquetes de controles disponibles para
VB.NET: desde los mas caros y sofisticados de Infragistics, Component One
o Farpoint hasta los gratuitos, igualmente de muy alta calidad.

Cuando diseñé mi primer sistema administrativo, incluí mas de ciento
cincuenta reportes intrinsecos en el paquete. El que me da de comer ahora
solo incluye alrededor de treinta. ¿Por qué? Por la simple razon de que
la mayoria de los cambios solicitados por los clientes del primer sistema
se referían a esos reportes: que no necesito está columna, o que le falta
esta, o que quiero agrupar por semanas, o que necesito conocer los saldos
vencidos de 90 a 120 dias. ¿Y qué hice? Simplemente le agregué un
generador de reportes, y cada quien que se haga los reportes que quiera
sin estar molestando. Al final, la mayoria de los reportes acabo
haciendolos yo mismo, o alguno de los distribuidores o tecnicos de
soporte, pero no se pueden quejar, porque la posibilidad de satisfacer
sus necesidades esta en sus manos, y si no la usan, tienen que pagar por
ella. A estas alturas, el paquete de distribución incluye más de mil
reportes preelaborados, y cada cliente puede tomar lo que le guste y
descartar el resto.

Sinceramente, no creo que la omision de un control para la lectura de
numeros figure entre los fallos que puedan achacarse a .NET. Es una
deficiencia que se resuelve en no mas de un dia de trabajo: tal vez un
poco mas, si nunca has desarrollado un control de usuario. Pero se espera
que un buen programador en VB sepa como desarrollar controles de usuario,
y la experiencia de realizar el primero es un activo valiosisimo.

Salud!