Problema en re-ubicar objetos en Visual Studio

No se si esto les ha pasado pero a mi me dio un gran dolor de cabeza la semana pasada y consumió 2 días enteros de mi tiempo hasta que por fin pude dar con la solución. Así que en caso estés creando/adicionando de manera dinámica objetos (controles) en algún 'User Control' que estés empleando el cual a su vez esta contenido dentro de un 'Tab Control', quizás hayas experimentado el mismo extraño comportamiento con la GUI (Interfaz gráfica de usuario) que estas programando.

Síntoma: Los objetos son creados y ubicados como esperabas, pero si escoges (haces click) en una lengueta diferente y luego regresas a donde estabas los objetos puede que se hallen ahora en una ubicación completamente distinta o hasta fuera de la vista del 'User Control'.

Causa: Parece que al adicionar controles (objetos) directamente a una clase del tipo 'User Control' no permite que los eventos para configurar los tamaños de los mismos se reporten correctamente, así la ubicación de estos controles es errada, o en otros palabras, estos controles no aparece en el lugar esperado a como estaba originalmente.

Solución: Adicionar un simple panel o una tabla (no he intentado con otros contenedores) como base inicial en el 'User Control', luego a este panel o tabla le adicionas dinámicamente los controles (objetos). Con esto puedes usar las propiedades de 'docking' y 'anchor' para ubicar los controles en cualquier parte y esta ubicación no cambiara como ocurrió antes.

Este problemita parece que no esta documentado en ninguna parte, o al menos yo no lo pude ubicar por mas búsquedas que hice. Encontré un problema similar reportado en Experts Exchange y con la lectura en detalle del articulo referido en TechRepublic puse en practica la solución sugerida. Aun así, debo comentar que encontrar este similar problema tomo mucho tiempo, por lo que pongo aquí este post para ayuda de todos los programadores dispersados a lo largo y ancho del mundo de habla hispana evitando asi situaciones como las de la imagen (je! je!), y para que en caso me vuelva a suceder sepa donde encontrar la solución. La memoria puede ser muy volátil! ja! ja! ja!

MonoDevelop versus Visual Studio

La comunidad Linux esta dividida por culpa de Mono, la razón es que Mono es el proyecto que intenta migrar el framework .Net de Microsoft a Linux en sus distintos sabores y colores. El detalle esta que Mono se alimenta de Microsoft y hasta el momento el gigante ha colaborado desinteresadamente con esta iniciativa que lleva también el apoyo de Novell. El punto es que hace casi 2 meses que la ultima versión de MonoDevelop ha sido lanzada y este IDE es ahora casi tan amigable como el mismísimo Visual Studio que uso a diario.

Entonces, ¿cual es el problema? dicen los mas aguerridos detractores de Mono - según cuenta TechNewsWorld - que en algún momento Microsoft sacara a relucir el tema de licencias y todo aquel que este usando Mono en su Linux estará obligado a pagar o sera demandado. También dicen que es el fin del software libre, que nadie debería confiar en lo que sea que tenga relación con Microsoft y los "vendidos" de Novell pues ellos son "anti sistema" desde el punto de vista del software libre. Pero la verdad es que Visual Studio es una gran herramienta y el framework .Net ha hecho que desarrollar aplicaciones sea una tarea mucho mas sencilla que antes, al menos en el mundo Windows.

¿Porque entonces es malo tomar una buena idea aunque sea de Microsoft y aplicarla al mundo Linux? Simplemente argumentar que es un tema económico me parece un poco jalado de los pelos, ¿acaso las compañías de código abierto no necesitan generar dinero también para seguir operando? ¿O es que quienes desarrollan Ubuntu, openSuse, y demás versiones de Linux no tienen también que ganarse el pan de cada día? En mi poca experiencia no he visto ninguna herramienta en Linux que haga el trabajo de crear aplicaciones de una manera tan amigable como lo hace el Visual Studio en el entorno Windows. Claro, algunas se acercan pero la verdad es que aun les falta un buen trecho.

En todo caso esta nueva versión de MonoDevelop trae nuevas características, las cuales las puedes leer aquí, pero la mas importante desde mi punto de vista como desarrollador es que ahora su GUI soporta debugging de manera total, tanto con MDB (Mono Debugger) como con el estandar GDB de GNU. En otras palabras, ahora puedes poner breakpoints dentro del mismo IDE e ir ejecutando la aplicación linea por linea, inspeccionar y evaluar expresiones, y mucho mas. Así, si tienes algún problema con la ejecución de tu aplicación fácilmente puedes identificar el origen. Y aunque MonoDevelop solo esta disponible para Linux y Mac OS X, ya hay un equipo en el proyecto Mono que amenaza con llevarlo a Windows. ¿Sera que Microsoft dejara que Mono compita con su Visual Studio? ¿O esperara ver que tanto éxito tiene para finalmente decidir sacar las garras?

TestStand versus Visual Studio .NET

Por algun tiempo hemos estado evaluando TestStand y comparandolo con Visual Studio .NET, tanto asi que ha desatado apasionadas discusiones entre los defensores de uno y del otro. Seria largo, complicado y redundante listar las caracteristicas de uno y del otro aqui, pero un developer amigo mio lo resumio de la siguiente manera...

"TestStand certainly offers a great deal of flexibility in its test executive. My primary question whether to adopt TestStand would be the cost/benefit as it applies to this department. For the type of tests our department produces, my opinion is that TestStand offers less value. Our tests are simple, high-volume and designed NOT to be configurable by the operators.

Adopting TestStand across our test projects would entail ramp up time and I don't think that this effort would payoff much more than we could already accomplish in the .NET environment. I have a project that is close to deployment for most of our test systems. The primary goal of this is maintenance reduction. To that end, the project architecture is modular and easily configurable. Because I was able to build this without being encumbered by our legacy projects, I was free to apply good software design. This project will essentially function as TestStand Lite.

A couple of project features relevant to this subject:

1. Configurable test lists for each UUT (unit under test) type, loaded at runtime. Allows easy modification of tests or test sequence without code changes to the host executable. Similar function as plug-ins.
2. The tests and instrument classes are compiled to .dlls and are no longer coupled to the operator GUI. Code changes to these libraries need not concern themselves with the code controlling the main form or even individual station controls.

An attractive feature of TestStand that deserves review:

AutoSchedule feature: (I'm going to skip an explanation of AutoScheduling vs. basic parallel station model. National Instruments has a .pdf that shows a very nice illustration to compare this to other station models) While certainly not impossible in a pure .NET project, implementing this feature in .NET would be a time sink. However, AutoScheduling is most advantageous when you have the combination of large number of stations (or large number of resources requiring locks) and resources which are locked for long durations. In a multi-station model, we already see large gains in the basic parallel station implementation. My guess, without running any numbers, is that we would see a measurable but not significant gain using the TestStand AutoSchedule feature.

For our department, I see TestStand useful for bench-top development. Such projects would benefit from the flexibility that TestStand brings."

Espero esto les sirva de partida para su propia evaluacion.

Gracias por leer.