Estancado en la progman

Desde hace ya mucho tiempo acostumbro llamarla "progman" a la programación. progman.exe es un archivo de Microsoft, pero no recuerdo si era de Windows u Office (creo que la última), y me encariñé con él desde que iba a cursos de computación hace años; después, cuando estaba la aprendiendo programación, vi o recordé el nombre de ese archivo nuevamente y asimilé su parecido con la palabra "programación" y desde entonces, cuando necesito escribir o decir la palabra programación sin perder tiempo, simplemente digo "progman".

Y con respecto a la progman.exe... estoy estancado en ella ¡!

Anteriormente he comentado que estoy realizando dos proyectos en Visual Basic; el primero es el NekroEditor: un editor de códigos con sintaxis básicas, y el otro es el NekroConmutador, un simulador de conmutadores: metes dos valores: '1' y '0', si tiene la propiedad Operador en 'And', devuelve False, si tiene 'Or', True; 'Xor', True; 'Eqv', False; 'Imp' = False.

Aunque el primero pretende ser una aplicación del tipo WordPad o Notepad2 y el otro un simple ActiveX con tres cuadritos (Valor1, Valor2 y Valor1 [...Xor...] Valor2), ambos están resultando más complejos de lo que en un principio imaginé.

El NekroEditor me hizo pasar por varios sufrimientos, corajes y alegrías, y creo que "hizo" subestima lo que implica la oración. Mis problemas con él son estos:

Uno: Ejecuten el bloc de notas, tecléen cualquier cosa y vayan a Edición / Buscar; mientras esté la ventana como activa, el cuadro de diálogo se encontrará en primera posición, pero esto es relativo, ya que si nos pasamos a otra ventana, el cuadro de diálogo de oculta junto con notepad.exe, y de otra forma queda TopMost. He intentado cambiar propiedades y escribir sentencias a mi frmBuscar.frm pero, además de que no me sale, creo que esa no es la solución.

He usado una API (no recuerdo cuál) para ponerla hasta el frente pero mi frmBuscar adquiere la importancia del Administrador de Tareas cuando le das Opciones / Siempre visible. Se me ha ocurrido que lo que necesito es una API que me combierta mi frmBuscar en una ventana hija de frmMain.frm, luego le aplicaría la API que no me acuerdo su nombre y, al pasarle TOPMOST a un argumento, quedaría siempre visible pero dentro del marco de mi aplicación.

La mayoría de este plan se me acabó de ocurrir en estos momentos, pero considero que, antes de eso, tengo que resolver los problemas que describo abajo.

Dos: Ya creé mi barra de menús con las APIs InsertMenuItem, CreateMenu y algunas otras, junto con una función que hice. El problema viene cuando quiero que la barra quede tatuada en mi programa: logro que aparezca y que se puedan seleccionar los menús, pero surge un inconveniente que acabo de descubrir hoy en la mañana: mi RichTextBox.

Estando haciendo cualquier cosa, la barra sigue intacta y visible, el problema viene cuando el RichTextBox cursa el evento _LostFocus(): escribo, y al darle la tecla TAB el foco pasa a un Command1_() que tengo para hacer experimentos, y, al perder el foco el RichTextBox, la barra de menús desaparece. Al decir "desaparece" me refiero a que se quita de la aplicación, no es que se oculte, sino que se quita de tal forma que la API GetMenu(hWnd) devolvería '0'.

La solución parcial que utilizé fue que en el evento _LostFocus() se llamara a SetMenu(hWnd, hMenú), pero, además de ser algo no propio de un código eficiente, no evitaba que mi barra se desapareciera y lo hacía ver poco presentable: al presionar la tecla TAB, desaparecía la barra de menús, pero en 1/4 de segundo volvía a aparecer: se podía apreciar cómo mi RichTextBox y mi CommmandButton se ponían más arriba y luego corrían otra vez para abajo cuando aparecía la barra de menús: un espectáculo realmente patético y penoso.

Hice unos experimentos y comprobé que la causa era el efecto RichTextBox_LostFocus(), puesto que con cambiar el área de trabajo a un TextBox, ya no pasaba esto, ni con otro control; también intenté cambiando la propiedad Multiline tanto al Textbox como al Rich pero ni así: tiene que ser cuando un RICH PIERDE EL FOCO. Mas, pese a que esto pueda ser por compatibilidad de control (hay que agregar una dependencia para el RichTextBox) creo que es porque algo le falta a mí menú, y es que si creo la barra de menús con el Editor de Menús de Visual Basic, la barra permanece fija y sin moverse aunque le de a TAB estando en el RichTextBox

¿Qué es lo que le falta? No creo que unos repetitivos DrawMenuBar o SetMenu lo arreglen, aunque estén ordenados estratégicamente.

También he intentado con SetClassLong cambiándole el valor de GCL_MENUNAME a hMenú, que es mi barra de menús, pero sólo consigo que Visual Basic genere un error y luego "deba cerrarse".

Tres: Tenía un problema para crear entradas de registro pero lo solucioné como hace 2 días.

Cuatro: Esto es en el NekroConmutador: Me da flojera describirlos porque son en cuanto al diseño y tendría que explicar cómo va gran parte de mi Conmutador.

Pero no estoy sólo en esos ámbitos, sino también practico haciendo proyectos pequeños aparte y experimentos de esos que no se guardan. Por ejemplo, estoy haciendo una aplicacioncita para jugar con las ventanas: con EnumWindows() y EnumChildWindows() saco los hWnd de todas las ventanas (no sé si los listbox y textbox y otros controles se consideren como ventanas porque no los extrae) y de ahí hago lo que quiero, que es practicar APIs: le cambio el nombre a las ventanas ajenas, les cambio la barra de menús y otras cosas. De hecho voy a practicar un rato con ellas porque ya me aburrió el NekroEditor, luego quizá me desconecte y juegue Mythology o mi emulador de Mario y al final leeré parte de una revista y mientras duerma sentiré remordimiento de no haber hecho la tarea.

Hora en que termino de escribir esto: 6:00