Adiós, HWND, adiós
Nish es uno de los gurús de MFC, C++/CLI, y siempre dice cosas interesantes. Como la que acaba de poner en su blog. Brevemente nos dice que en el nuevo Avalon los controles de ventana hijos dejarán de tener su handle, por lo que será imposible hacer como hasta ahora: cuando una característica no está disponible dentro del .NET Framework, si es una ventana (recordemos que en Windows la mayoría de elementos son ventanas), buscamos/obtenemos su handle y le enviamos el mensaje correspondiente.
Pero eso ya no va a ser posible en Avalon. O sea, que si quieres implementar una características que sí tiene un control nativo de Windows y no el .NET, pues te jodes, porque no vas a poder hacerlo. En otras palabras, los controles Avalon no tienen nada que ver con el funcionamiento por mensajes de Windows.
¿Esto es bueno? ¿Es malo? Pues en mi opinión, depende. Es bueno porque poco a poco nos vamos apartando del aparatoso e ineficiente sistema de paso de mensajes, que genera unas aplicaciones un tanto estrambóticas (ya me gustaría a mi echarle un vistazo al bucle de mensajes de, por ejemplo, Word). Es malo porque no veo cómo va a ser sustituido. ¿Por hilos? ¿Y cómo van a interactuar esos hilos? ¿Mediante semáforos, secciones críticas? Lo veo complicado, pero bueno, ellos sabrán qué se hacen.
Ahora, eso sí, espero que las funcionalidades sean las mismas que con los controles nativos. Me refiero a subclasificación, capturar mensajes y variar comportamiento, etc., porque si no es así me veo a todos los programas con el mismo aspecto, sin poder hacer variación alguna…
Podría haber un motivo oculto para hacer esto así, y es el hecho de potenciar a los vendedores de componentes. Actualmente es relativamente fácil añadir a un list box, por ejemplo, pequeños iconcitos al texto: captura su WM_PAINT y dibuja lo que te de la gana. Pero si un componente viene prefijado y tu quieres una variación, pues te toca pasar por caja. Espero que no, que se puedan subclasificar -heredar- y todo eso.
Voy a poner un ejemplo sufrido en carnes propias con el .NET 1.1 y el hecho de que no cubra todo lo que hasta ahora se puede hacer de forma nativa. En uno de mis programas OpenSource, zxFortunes, necesitaba tener un icono en la barra de notificación. Existe para ello un componente dentro del .NET, llamado TrayIcon. Pero este elemento es un juguete en comparación con las posibilidades del equivalente nativo. Pues bien, pensando que al final, debajo de todo, debía estar el control nativo, busqué y busqué la forma de llegar a él y habilitar sus características… Fue del todo imposible. Ni con interop, ni insertando una dll en el espacio de direcciones que hiciera de puente, nada, fue totalmente imposible.
Imaginemos, pues, un mundo en el que todo estuviera limitado de esta forma… Pues ese es el mundo al que nos está abocando Microsoft y su “maravilloso” .NET. Sinceramente espero equivocarme.
Imaginemos, pues, un mundo en el que todo estuviera limitado de esta forma… Pues ese es el mundo al que nos está abocando Microsoft y su “maravilloso” .NET. Sinceramente espero equivocarme.
Pues EMO te equivocas. Prefiero dejar que la parte nativa la manejen cosas más cercanas al S.O. que cualquier programa. De hecho, y paradójicamente, esta práctica por la que aboga Microsoft hace más fácil la portabilidad hacia otros sistemas operativos distintos a Windows, por ejemplo Linux (gracias a Mono.
Comment by knocte — April 8, 2006 @ 12:06 pm
Me has malinterpretado. Te pongo un ejemplo: ¿Quieres manejar el soporte del programador de tareas? Pues te toca hacerlo mediante interop accediendo al código nativom porque el NET no lleva nada de eso. Otro: ¿Ventanas emergentes estilo XP en un icono en la barra de notificación? Pues con el .NET es imposible, te toca hacerlo de forma nativa.
Me refiero justo a eso, que mientras el .NET no cubra por completo la API de Win32 se queda en un mero juguete… Yo no quiero que todas las aplicaciones sean iguales, azulitas y políticamente correctas… Ese es el problema… y el temor.
Comment by rfog — April 8, 2006 @ 2:53 pm
knocte, estas completamente equivocado, la separacion en capas de un sistema operativo desaparece cuando uno es un desarollador, en este caso y dependiendo de lo que programes, vas a querer interactuar con el SO de distintas maneras y en distintos niveles, si tu programa funciona dentro de una sandbox como java y otros interpretes pues te diria que sirven para algunas cosas y otras no, personalmente me gusta programar en un lenguaje donde sienta que no hay limites y donde puedo llegar hasta donde quiero.
Por otro lado no creo que MS piense en la portabilidad como un factor prioritario ni mucho menos, es mas sabemos que poco portable es el codigo entre una plataforma de windows a otra, ni hablar de linux, adios wine y todo eso con vindows vista, y el proyecto mono ni existe, para los que programan en java esta la ilucion pero de esa gentusa mejor ni hablar, son.
En definitiva MS esta empujando a los programadores por el camino que ellos quieren, es muy loco pero incluso la gente que programaba en visual basic esta enojada con .net busquen en el google “dot.not” y vean a lo que me refiero, sin duda los chicos de VB podian hacer mucho con so viejo sistema hora cosa del pasado, me niego a aprender C# es una abominacion igual que .net
Lo asombroso del tema es que la tecnologia COM nacio para ayudar a los programadores de C++ a esportar sus clases en forma de libreria, algo un poco mejor que las viejas .lib y dll.
Ahora los pasaron por arriba, que triste.
Se termino lo que se daba a otra cosa, vamos a salir a caminar y apaguemos la computadora por un rato por que todo esto me hace doler la cabeza.
Comment by Benjamin — December 27, 2006 @ 1:21 pm