WPF o Windows Forms

"Rolando" escribió en el mensaje
news:

En mi caso yo digo que es cierto, uno puede ganarse la vida desarrollando
aplicaciones de escritorio usando .NET pero (y quizas de eso era que
hablaba Jose), .NET no es todavia una verdadera herramienta RAD que
permita hacer sistemas rapidamente. Da trabajo terminar un sistema en .Net
y mas que todo aprenderlo. Es costoso el desarrollo en .NET.

Exacto, de eso hablaba. Imagina yo vengo del mundo de PowerBuilder y Visual
Foxpro donde el tema en los sistemas windows las cosas eran mucho mas
simples de implementar y en menos tiempo.
No digo con eso que C# sea malo.

Ya. Y sobre los requisitos de los equipos hay alguna diferencia respecto a
las aplicaciones WF ?

Jesus, gracias por las aclaraciones, ya me va interesando mas esto del WPF.

"Jesús López" escribió en el
mensaje news:eeeB%

Pero, WPF me deja hacer una aplicacion de escritorio tipica, ejemplo una
de Stock y pedidos ?

Sí, con WPF puedes hacer una aplicación de escritorio típica y no tan
típica.

Que ventaja me da hacerla por WPF en vez del Windows Forms tradicional?

Que con WPF puedes hacer un interfaz de usuario mucho más rica y
proporcionar una mejor experiencia al usuario. A parte de otras muchas
cosas como por ejemplo que el DataBinding es muchísimo mejor en WPF que en
Windows Forms.

Estuve buscando foros de wpf pero no encuentro en la lista del Windows
Mail (msnews). Sabeis de algun foro?

No hay foros msnews en español de WPF, pero los hay foros web en inglés:

http://forums.microsoft.com/MSDN/Sh...px?ForumID9&SiteID=1

De todas formas, puede usarse perfectamente este mismo foro para preguntas
de WPF.

Saludos:

Jesús López
www.solidq.com

Lo que me imaginaba. Será entonces casi igual de rápido que los recursos
nativos compilados, y digo *casi* porque evidentemente el .NET es algo más
lento que el Win32, pero por nada más.

"Jesús López" wrote in message
news:ORFq%

El XAML se compila en BAML, una versión binaria del XAML. Cuando
despliegas tu aplicaciones no incluyes los ficheros XAML y el BAML está
incrustado como recursos en el propio ensamblado. En definitiva, puedes
olvidarte de la lentitud del XML.

Saludos:

Jesús López
www.solidq.com

"Jesús López" wrote in message
news:e%

No puedo estar de acuerdo contigo.

Windows Forms es bueno, y WPF es aún mejor. Cualquiera de las dos
tecnologías te permiten sobradamente escribir aplicaciones de escritorio
con las que ganarte la vida.

Coñe, es que si no fuera así... mal íbamos a ir.

Respecto a lo de que WF es bueno... disiento un poco: es meramente
aceptable, y la prueba la tienes cuando en el IDE se te desbaratan todos los
controles o intentas salirte de lo que MS ha previsto. ¿Has probado a
insertar por programa una toolbar en una posición concreta cargada de disco,
y a crear controles a mano fuera de IntializeComponents? Ni se colocan donde
dices, ni con la forma que quieres, por lo menos antes del SP1 del 2.0, los
splitters unas veces se colocan donde quieres (por código, no en el diseño
original), otras no. Añade que el "Sender" en los eventos de los controles
compuestos es la propia ficha y no el subcontrol que lo genera, el tema del
evento de doble click que nunca se dispara en la mayoría de controles...

De WPF no puedo decir nada porque apenas lo he visto por encima... pero no
me extrañaría que tuviera pifias (uy, perdón, "features") del mismo estilo.

Saludos:

Jesús López
www.soldiq.com

Respecto a lo de que WF es bueno... disiento un poco: es meramente
aceptable, y la prueba la tienes cuando en el IDE se te desbaratan todos
los controles o intentas salirte de lo que MS ha previsto. ¿Has probado a
insertar por programa una toolbar en una posición concreta cargada de
disco, y a crear controles a mano fuera de IntializeComponents? Ni se
colocan donde dices, ni con la forma que quieres, por lo menos antes del
SP1 del 2.0, los

Ni se puede personalizar ese pintado procedimental que tiene el IDE. Ni
cambiar el orden de inicializacion de los objetos, etc. etc.
Recientemente yo puse un mensaje respecto a un caso parecido. Por suerte me
ayudaron diciendo lo de la prop. DesignMode para poder ignorar por codigo
esos terribles errores que da el IDE que te impiden ver un control
visualmente en el tiempo de diseño. Espero que WPF tenga mejoras al
respecto porque WF deja mucho que desear en cuanto a lo rigido del codigo
auto-generado. Por lo que se ve eso no lo van a arreglar para WF porque de
ser asi lo habrian hecho en la nueva version 2008 y por lo visto sigue
igual.