Modal sin ser Modal

[francisco prieto]

Grupo,

El dia de hoy tuve un inconveniente. Tengo un sistema que adquirí recientemente y el 100% de los forms son de tipo modal.

Eso me trae un sinnúmero de inconvenientes, uno de los cuales es que:

un formulario modal (llamemosle A) llama a otro formulario modal (llamemosle B). El formulario modal B ya he probado de ponerlo con OnTop y sin OnTop... sea como sea a veces ese formulario B queda por detras del formulario A, bloqueando de esta forma el sistema, ya que no hay modo de acceder a el.

Para darle al cliente una solución temporal, como este formulario B es bastante pequeño lo ubico del otro lado de la pantalla y nunca es tapado, pero digamos que es una solución atada con alambre.

En San Google encontré una alternativa interesante que quería compartir.

http://www.rcs-solutions.com/blog/2010/07/21/AlternativeToModalVFPForms.aspx

La solución definitiva a esto es que el 100% de los formularios sean no modales y con ese link creo que se lograría, claro que es algo laborioso porque debo modificar cada llamada a los formularios.

Saludos,

Pancho

Córdoba

Argentina

[Rh Yac]

Quizas tambien, que  SOLO sean modales las forms de "ayudas" o "busquedas".

________________________________
Rene Yacyna
Córdoba - Argentina.
03546 15455857

[francisco prieto]

Si, pero fijate que con esa tecnica ya ninguna tiene que ser modal...

Saludos,

Pancho

Córdoba

Argentina

[Rh Yac]

Si si, es asi, salvo que no este llamando a ningun otro Form.

________________________________
Rene Yacyna
Córdoba - Argentina.
03546 15455857

[Germán Fabricio Valdez]

y si en el evento deactivate pones thisform.release() y que lo vuelva a llamar el cliente presionando el boton

yo nunca vi que un modal se pomga detras de otro modal

[francisco prieto]

German,

Pude reproducir la situacion, muy rara por cierto... pero pude y me parece patético, pero bueno...

Tu solución no la puedo implementar porque en general no sucede, es decir algo extraño sucede y pasa pero no pasa siempre...

Vere mañana con las pruebas del cliente a ver si logro zafar con esa atadura de alambre.

Saludos y gracias,

Pancho

Córdoba

Argentina

[ZeRoberto]

El problema es porque tiene la propiedad Desktop = .T.

[francisco prieto]

Umm, eso lo sospeche, pero no lo probé. Es un buen dato ZeRoberto.

A ver, todo debería ser Desktop=.F. ? o solo la que me aparece al fondo?

Espero tus comentarios.

Pancho

Córdoba

Argentina

[ZeRoberto]

Es un problema cuando se usa DeskTop = .T. y hasta ahora no encontre una solucion, el problema sucede cuando el cliente da un click en el mismo formulario antes de que cargue el segundo formulario, tambien sucede cuando regresas a la aplicacion mediante ALT+TAB

[Fidel Charny]

Otro dato (además del Desktop = .T.)
El formulario B quedará detrás del formulario A si en el conjunto de instrucciones que instancian el form B hay un SetFocus() al form A.
También he visto que algunos programadores colocan un SetFocus dentro del Init del form (o en  métodos llamados desde el Init).
El SetFocus que no pueda evitarse en la instanciación (porque depende de un parámetro, por ejemplo, o de un escenario que pueda cambiar por otro motivo), debería colocarse en el Activate del form, generalmente con una bandera para que no se repita, para que pueda resolverse adecudamente: el form va primero al enfoque natural (primer objeto Enabled=.T. que pueda recibir foco siguiendo el orden de TabIndex) y luego cumple con el SetFocus del Activate (que en este caso es lanzado por el método Show).

Fijate además en la recomendación de la ayuda:

You should not use the Desktop property when you create Single Document Interface (SDI) applications in which you might want to hide the Visual FoxPro desktop window (_SCREEN). Instead, set the ShowWindow Property setting to 2 to create a top-level form.

[francisco prieto]

Gracias Fidel,

Si bien el sistema (que vuelvo a aclarar compre y no programe) esta compilado en VFP9 internamente su programacion es en general foxpro 2.6 y sus reportes son prg (de modo que hay mucho trabajo por delante)

En esta primera etapa debo apagar incendios. Luego reprogramaré todo, pero entre todos estos incendios esta este problema. SDI no hay y tampoco (raramente) hay fomsets.

Saludos,

Pancho

Córdoba

Argentina

[Fidel Charny]

Hola Pancho!
Me parece que para vos será más fácil hacerlo todo de nuevo. Ja, Ja !!
No sé si tendrá scx o es todo prg. Si tiene scx no te olvides de Foxbin2prg!

[francisco prieto]

Fidel,

Ya le incorpore el control de versiones hace mas de un mes y por lo tanto ya usa el Foxbin2prg.

Lo mas grave es que debo apagar los incendios y paralelamente pasar los reportes y pantallas prg a scx y frx.

Tambien voy a hacer una version en FreePascal, pero eso es harina de otro costal :D

El sistema a pesar de estos vejestorios es bastante completo... hasta la contabilidad resuelve mediante asientos...

Saludos,

Pancho

Córdoba

Argentina

[ZeRoberto]

No lo he probado pero prueba poniendo esto

BlockInput(.T.)

Do Form frmModalB.Scx

Y luego en el evento Load del Formulario frmModalB

Procedure Load()

    BlockInput(.F.)

EndProc

Procedure BLockInput(tlState)

   Declare Integer BlockInput In user32.dll As BlockInputEx Long

   BlockInputEx(tlState)

   Clear Dlls "BlockInputEx"

Return

[francisco prieto]

Gracias ZeRoberto,

Como tengo el problema concreto y tengo el cliente que siempre le da lo voy a probar asi nos sacamos la duda si eso funciona o no.

Saludos,

Pancho

Córdoba

Argentina

[francisco prieto]

Bueno, confirmo, eso no funciona. El problema continua.

Saludos,

Pancho

Córdoba

Argentina

[Victor Espina]

Francisco, creo que la cosa viene por lo que dice Fidel:  en alguna parte antes de que el formulario B tome el foco, alguien esta transfiriendo el foco de nuevo al formulario A.  Quizas en el Deactivate del form A?     Cuando lei tu post original mi primer pensamiento fue:  antes de ponerse a cambiar TODOS los formularios para que sean no modales, mejor y mas eficiente seria concentrarse en entender porque pasa el problema puntual en primer lugar y asi intentar conseguir una solucion.  Hacer un cambio de ese tamano (cambiar de modal a no modal) solo lograria introducir decenas de bugs potenciales, en el esfuerzo por corregir solo uno :)

Victor

[francisco prieto]

Victor,

Ya he probado muchas cosas y todo apunta a tener que rehacer el código...

En este momento estoy probando la solucion de este link para el caso puntual del formulario que da error...

http://www.rcs-solutions.com/blog/2010/07/21/AlternativeToModalVFPForms.aspx

Hasta ahora ninguna de las soluciones resolvio el problema y si bien voy a rehacer el sistema completo, tengo que apagar el incendio en mas de 20 clientes...

Saludos,

Pancho

Córdoba

Argentina

[Fidel Charny]

Hola Pancho
No sé como tienes las llamadas a los form desde otros forms. Te comento un truco que veo que uso  en un caso en el que no quiero que el operador haga otra cosa que resolver el tema:
Thisform.Enabled = .F.
DO FORM miForm_Modal WITH loquesea
Thisform.Enabled = .T.

También se puede implementar en el formulario convocado, pasando como parámetro la referencia de objeto del form que llama
DO FORM MiForm_Modal with thisform

* Init del Modal
LPARAMETERS toForm
toForm.Enabled = .F.
ADDPROPERTY(thisform,"oForm",toForm)

* Unload del Modal
IF VARTYPE(this.oform)="O"
        this.oform.Enabled = .T.
ENDIF
This.oform = null

Yo siempre sospecho del uso de SetFocus. Me resulta mala idea la aparición de SetFocus en el Init del form. Y complican la cosa los SetFocus en los eventos LostFocus.

Tengo un form con Text1, text2 y command1, donde en el lostfocus de text1 hay un Setfocus al text2 y viceversa (o sea algo ridículo).
Nunca paso el cusor por el text2, pero fijate que el text2.lostfocus ocurre y ocurre después del click en el Command1 (con sus instrucciones). Y este suceso, obedece al redireccionamiento del lostFocus de text1 (que tiene el tabindex=1).
   0.000897,,form1.text1.lostfocus,1,c:\theodore\zform.sct,1
   1.692176,,form1.command1.click,1,c:\theodore\zform.sct,1
   0.000441,,form1.text2.lostfocus,1,c:\theodore\zform.sct,1
   0.000109,,form1.unload,1,c:\theodore\zform.sct,1

[Mario López]

Pancho: buenas, en mi caso algunas veces uso forms “cuasi modales”:

• en consulta/modificación/borrado de comprobantes, tengo un form que me permite filtrar los comprobantes y un form subordinado que me muestra y deja editar los datos de un comprobante específico
• en todos los forms que tienen datos codificados (código de artículo, etc), el subform de búsqueda de códigos no deja volver al form anterior hasta seleccionar un código o cancelar la búsqueda

Digo “cuasi modales” porque en vez de hacer el sub-formulario modal mantengo una referencia al formulario llamador en el mismo (ej ThisForm.ParentForm) y deshabilito toda la cadena de This.ParentForm, This.ParentForm.ParentForm, .... con .Enabled = .F.. En el Destroy del sub-formulario se vuelven a habilitar los mismos.

Esto tiene la ventaja que el usuario puede abrir nuevas opciones de menú (por ejemplo, agregar un artículo con la pantalla de facturación abierta) pero le obliga a seleccionar una acción en las subpantallas específicamente para seguir operando en las pantallas principales (borrar un comprobante, seleccionar un artículo, cerrar la subpantalla, etc). Así tampoco los usuarios se marean con pantallas abiertas por error, lo que me pasaba mucho en el caso de pantallas totalmente no modales: los usuarios abrían la selección de comprobantes, hacían doble click varias veces en un comprobante abriendo varias subpantallas del mismo, etc.

HTH
Mario

---

[francisco prieto]

Como dije al principio, no es un código que haya realizado, sino que herede por haber comprado un sistema con su cartera de clientes.

Los clientes en general están muy resignados a que los errores del sistema (el cual se queda colgado por las constantes llamadas a formularios modales) no tiene solución y debo lidiar con esa desconfianza.

Si por mi fuera cambiaría todo de raíz, pero no puedo hacerlo, sin invertir mucho tiempo y arriesgarme a tener considerables bugs. Los cambios deben ser progresivos y es bastante frustrante hacer una pequeña mejora y ver como se cae todo el edificio...

Sin ir mas lejos, en el sistema se crea un txt por cada reporte que es un prg y el mismo se enviaba así a un formato XLS el cual si bien se veía, no se podía trabajar como XLS... hice tan solo el cambio de hacer un copy to XLS y encontré que eso no es suficiente pues el origen de los datos no esta en la tabla activa sino que se arma al vuelo a partir de variables y valores hardcodeados...

Ahora para solucionar el brete, tengo que recorrer cada prg, armar un cursor, cargarle los registros que irían al reporte y finalmente hacer el copy to XLS... se puede si... anda si... pero es bastante laborioso corregirlo.

Saludos y gracias por los aportes.

Pancho

Córdoba

Argentina

[Carlos Miguel FARIAS]

Me parece que compraste un sistema con una cartera de clientes y un bolsa de gatos de código.

En algunos casos, cuando en un formulario necesitaba llamar otro modal para que el usuario seleccionara algo, o entrara parámetros de búsqueda, si el formulario llamado era pequeño (menor que el invocante) en lugar de crear un formulario, metía todo en un contenedor que se hacía visible por encima del resto del formulario (dentro de los límites del principal, por lógica) y luego que el usuario seleccionaba o cargaba lo necesario, lo ocultaba.

Esto me eliminaba además la necesidad de volver a abrir tablas, indices y cuando apuntaba o posicionaba en el contenedor simil form, quedaba así en el resto del form, parecido a un formset.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, disfruten que solo les queda el resto de vuestras vidas

[francisco prieto]

Y hablando de la bolsa de gatos... me cruce con lo siguiente...

En el programa se hace

Do Form F_STPRINT With OL_PM

Resulta que si no se le pone Name como parámetro a do form, el VFP crea una variable de objeto con el mismo nombre del formulario, como dice en este link

https://msdn.microsoft.com/es-es/library/cc450817(v=vs.71).aspx

Es decir se crea en este caso la variable F_STPRINT.... pero lo que no dice ahí es que si el formulario es modal, F_STPRINT es publica, en cambio si el formulario es Modeless F_STPRINT es local...

Pues bien el programador de esto se agarro de este alcance y ejecuta métodos del formulario F_STPRINT desde otros métodos distintos al método que llamo al formulario...

(Este pienso que es el origen del problema de los cuelgues de la pantalla de impresión)

Para arreglar este menjunje tuve que crear una propiedad en el formulario y hacer lo siguiente:

Do Form F_STPRINT With OL_PM Name Thisform.FormPrint
Bindevent(Thisform.FormPrint, "Destroy", Thisform, "FinImpresion")

Con esto logro que el formulario F_STPRINT funcione Modeless y para llamar a métodos de este formulario desde otro métodos hago:

Thisform.FormPrint.M_ENDPAGE()

Lo complejo es que tengo que modificar prácticamente todas las pantallas...

Saludos,

Pancho

Córdoba

Argentina

[Fidel Charny]

No entendí Pancho.
De acuerdo con lo que expones, el Bindevent() está funcionando solamente porque el formulario es Modeless (Windowtype=0). Si no fuera así, la ejecución del código se detendría hasta que se ejecute el Unload del form modal.
(Particularmente para el caso de enlazar el evento Destroy, tienes que asegurarte que ese evento tenga al menos un asterisco como código, de lo contrario no funcionará.)

Yo pensaría que la variable de objeto es PRIVATE en todos los casos. Lo que ocurre, en realidad, es que al llamar un formulario modeless, el procedure o método que lo llama continúa hasta terminar, con lo que la variable se extingue. Mientras que si llamas a un formulario modal, se crea una suspensión y el método terminará cuando el modal se cierre, por lo que las variables PRIVATE pueden ser conocidas por cualquier dependiente de ese método, entre ellos, el formulario modal instanciado, para el que funcionará como pública.

Un formulario (salvo el caso de ShowWindow=2 que ignora el valor de WindowType) puede ser ejecutado como modal o modeless en tiempo de ejecución antes de que se ejecute el método show.
Por ejemplo, si ejecuto esto desde la linea de comandos, se crea una variable pública con el nombre del form
DO Form zensayo5 NOSHOW
zensayo5.Show(1)        && acá le digo que se muestre como formulario Modal.

DO Form zensayo5 NOSHOW
zensayo5.Show(0)        && acá le digo que se muestre como Modeless
Después de la primera ejecución del métodos show, no puedo cambiar el valor de la propiedad WindowType del form.

También puedo poner un parámetro en el Init del form que configure el valor de WindowType.

En resumen, la propiedad WindowType no resulta alterada por la sentencia DO FORM. Si no hay otra cosa en el init, o en el parámetro del método Show() cuando el do form se ejecuta con NOSHOW, dependerá del valor asignado en el diseñador de formularios (por defecto es cero).

Aunque signifique "reventar" la encapsulación, Visual Fox permite ejecutar cualquier cosa de cualquier formulario instanciado, aunque no esté activo, con solo conocer su referencia de objeto.

[francisco prieto]

Entonces con tu explicación... la variable que se crea es de tipo privada siempre, lo que ocurre es que al mostrarse como modeless su alcance se termina después de la instrucción Do form, con lo cual si desde el formulario llamado quiero usar esa variable dará error porque ya no existe...

En cambio si el formulario es llamado como Modal como la instrucción Do Form no finalizó puedo operar con dicha variable.

Con eso que explicas del método Show, la moraleja es...

SIEMPRE programa tus forms como Modeless, pues cuando necesitas que trabajen como modal simplemente haz esto:

Do form XXX NOSHOW

XXX.Show(1)

Muchisimas gracias por el aporte.

Saludos,

Pancho

Córdoba

Argentina

[mapner]

Pancho, buena tuya el mencionar que DO FORM (sin nombre NAME) crea una variable con el mismo nombre del formulario y mala de VFP ya que estaría "pisando" una variable previamente creada con el mismo nombre y eso puede ocasionar efectos no deseados

ejemplo:

m.Cliente = 1 && variable Cliente conteniendo el número 1

...

...

DO FORM CLIENTE.SCX  && pisa el contenido anterior de la variable m.Cliente con el objeto formulario creado

al destruir el formulario la variable m.Cliente queda con contenido NULL

Más allá de lo bueno que es VFP, en este caso han implementado una pésima práctica que es no respetar el contenido de variables previamente definidas.

Saludos 

[Fidel Charny]

Hola Pancho
Una pequeña corrección: no es la instrucción DO FORM la que no finaliza. Es el procedimiento/evento/método que contiene la instrucción DO FORM que se queda a la espera del cierre del formulario Modal. Por esa razón, es posible escribir (para un formulario modal)
DO FORM MiModal with loquesea to lxRespuesta
? lxRespuesta

[francisco prieto]

Ummm...

Aunque esta vez no se dio ese caso estaría bien lo siguiente
DO FORM MiAunNoModal with loquesea to lxRespuesta noshow

MiAunNoModal.Show(1) && Ahora es modal

?lxRespuesta

Saludos,

Pancho

Córdoba

Argentina

[mapner]

Si de hecho las llamadas a modal lo uso de esa manera ... DO FORM MiForm NOSHOW NAME oFrm LINKED 

A su vez en el formulario modal no hago Release sino Hide para que cuando retorne a la rutina llamadora se puedan obtener datos de propiedades del tipo oVar.Propiedad1, oVar.Propiedad2 etc.., 
ej.

Local oFrm

DO Form MiForm NOSHOW NAME oFrm LINKED 

oFrm.Show(1)

IF oFrm.lOk

MESSAGEBOX(oFrm.cMensajeRet)

ENDIF

oFrm = NULL

<div title="MDH:UGFuY2hvOiBidWVuYXMsIGVuIG1pIGNhc28gYWxndW5hcyB2ZWNlcyB1c28gZm9ybXMgImN1YXNp IG1vZGFsZXMiOjxicj48YnI+LSBlbiBjb25zdWx0YS9tb2RpZmljYWNpw7NuL2JvcnJhZG8gZGUg Y29tcHJvYmFudGVzLCB0ZW5nbyB1biBmb3JtIHF1ZSBtZSBwZXJtaXRlIGZpbHRyYXIgbG9zIGNv bXByb2JhbnRlcyB5IHVuIGZvcm0gc3Vib3JkaW5hZG8gcXVlIG1lIG11ZXN0cmEgeSBkZWphIGVk aXRhciBsb3MgZGF0b3MgZGUgdW4gY29tcHJvYmFudGUgZXNwZWPDrWZpY288YnI+LSBlbiB0b2Rv cyBsb3MgZm9ybXMgcXVlIHRpZW5lbiBkYXRvcyBjb2RpZmljYWRvcyAoY8OzZGlnbyBkZSBhcnTD rWN1bG8sIGV0YyksIGVsIHN1YmZvcm0gZGUgYsO6c3F1ZWRhIGRlIGPDs2RpZ29zIG5vIGRlamEg dm9sdmVyIGFsIGZvcm0gYW50ZXJpb3IgaGFzdGEgc2VsZWNjaW9uYXIgdW4gY8OzZGlnbyBvIGNh bmNlbGFyIGxhIGLDunNxdWVkYTxicj48YnI+RGlnbyAiY3Vhc2kgbW9kYWxlcyIgcG9ycXVlIGVu IHZleiBkZSBoYWNlciBlbCBzdWItZm9ybXVsYXJpbyBtb2RhbCBtYW50ZW5nbyB1bmEgcmVmZXJl bmNpYSBhbCBmb3JtdWxhcmlvIGxsYW1hZG9yIGVuIGVsIG1pc21vIChlaiBgVGhpc0Zvcm0uUGFy ZW50Rm9ybWApIHkgZGVzaGFiaWxpdG8gdG9kYSBsYSBjYWRlbmEgZGUgYFRoaXMuUGFyZW50Rm9y bSwgVGhpcy5QYXJlbnRGb3JtLlBhcmVudEZvcm0sIC4uLi5gIGNvbiBgLkVuYWJsZWQgPSAuRi5g LiBFbiBlbCBgRGVzdHJveWAgZGVsIHN1Yi1mb3JtdWxhcmlvIHNlIHZ1ZWx2ZW4gYSBoYWJpbGl0 YXIgbG9zIG1pc21vcy48YnI+PGJyPkVzdG8gdGllbmUgbGEgdmVudGFqYSBxdWUgZWwgdXN1YXJp byBwdWVkZSBhYnJpciBudWV2YXMgb3BjaW9uZXMgZGUgbWVuw7ogKHBvciBlamVtcGxvLCBhZ3Jl Z2FyIHVuIGFydMOtY3VsbyBjb24gbGEgcGFudGFsbGEgZGUgZmFjdHVyYWNpw7NuIGFiaWVydGEp IHBlcm8gbGUgb2JsaWdhIGEgc2VsZWNjaW9uYXIgdW5hIGFjY2nDs24gZW4gbGFzIHN1YnBhbnRh bGxhcyBlc3BlY8OtZmljYW1lbnRlIHBhcmEgc2VndWlyIG9wZXJhbmRvIGVuIGxhcyBwYW50YWxs YXMgcHJpbmNpcGFsZXMgKGJvcnJhciB1biBjb21wcm9iYW50ZSwgc2VsZWNjaW9uYXIgdW4gYXJ0 w61jdWxvLCBjZXJyYXIgbGEgc3VicGFudGFsbGEsIGV0YykuIEFzw60gdGFtcG9jbyBsb3MgdXN1 YXJpb3Mgc2UgbWFyZWFuIGNvbiBwYW50YWxsYXMgYWJpZXJ0YXMgcG9yIGVycm9yLCBsbyBxdWUg bWUgcGFzYWJhIG11Y2hvIGVuIGVsIGNhc28gZGUgcGFudGFsbGFzIHRvdGFsbWVudGUgbm8gbW9k YWxlczogbG9zIHVzdWFyaW9zIGFicsOtYW4gbGEgc2VsZWNjacOzbiBkZSBjb21wcm9iYW50ZXMs IGhhY8OtYW4gZG9ibGUgY2xpY2sgdmFyaWFzIHZlY2VzIGVuIHVuIGNvbXByb2JhbnRlIGFicmll bmRvIHZhcmlhcyBzdWJwYW50YWxsYXMgZGVsIG1pc21vLCBldGMuPGJyPjxicj5IVEg8YnI+TWFy aW88YnI+PGJyPi0tLTxicj48YnI+PGJyPjxicj5FbCBtacOpcmNvbGVzLCAxNiBkZSBub3ZpZW1i cmUgZGUgMjAxNiwgOTo1MDozOSAoVVRDLTMpLCBWaWN0b3IgRXNwaW5hICBlc2NyaWJpw7M6PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwO21hcmdpbi1sZWZ0 OiAwLjhleDtib3JkZXItbGVmdDogMXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OiAxZXg7Ij48 ZGl2IGRpcj0ibHRyIj5GcmFuY2lzY28sIGNyZW8gcXVlIGxhIGNvc2EgdmllbmUgcG9yIGxvIHF1 ZSBkaWNlIEZpZGVsOiAmbmJzcDtlbiBhbGd1bmEgcGFydGUgYW50ZXMgZGUgcXVlIGVsIGZvcm11 bGFyaW8gQiB0b21lIGVsIGZvY28sIGFsZ3VpZW4gZXN0YSB0cmFuc2ZpcmllbmRvIGVsIGZvY28g ZGUgbnVldm8gYWwgZm9ybXVsYXJpbyBBLiAmbmJzcDtRdWl6YXMgZW4gZWwgRGVhY3RpdmF0ZSBk ZWwgZm9ybSBBPyAmbmJzcDsgJm5ic3A7IEN1YW5kbyBsZWkgdHUgcG9zdCBvcmlnaW5hbCBtaSBw cmltZXIgcGVuc2FtaWVudG8gZnVlOiAmbmJzcDthbnRlcyBkZSBwb25lcnNlIGEgY2FtYmlhciBU T0RPUyBsb3MgZm9ybXVsYXJpb3MgcGFyYSBxdWUgc2VhbiBubyBtb2RhbGVzLCBtZWpvciB5IG1h cyBlZmljaWVudGUgc2VyaWEgY29uY2VudHJhcnNlIGVuIGVudGVuZGVyIHBvcnF1ZSBwYXNhIGVs IHByb2JsZW1hIHB1bnR1YWwgZW4gcHJpbWVyIGx1Z2FyIHkgYXNpIGludGVudGFyIGNvbnNlZ3Vp ciB1bmEgc29sdWNpb24uICZuYnNwO0hhY2VyIHVuIGNhbWJpbyBkZSBlc2UgdGFtYW5vIChjYW1i aWFyIGRlIG1vZGFsIGEgbm8gbW9kYWwpIHNvbG8gbG9ncmFyaWEgaW50cm9kdWNpciBkZWNlbmFz IGRlIGJ1Z3MgcG90ZW5jaWFsZXMsIGVuIGVsIGVzZnVlcnpvIHBvciBjb3JyZWdpciBzb2xvIHVu byA6KTxkaXY+PGJyPjwvZGl2PjxkaXY+VmljdG9yPC9kaXY+PGRpdj48YnI+PGJyPkVsIG1pw6ly Y29sZXMsIDE2IGRlIG5vdmllbWJyZSBkZSAyMDE2LCA3OjM1OjQ2IChVVEMtMyksIGZyYW5jaXNj byBwcmlldG8gZXNjcmliacOzOjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowO21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxkaXY+PGRpdj48 ZGl2PjxkaXY+QnVlbm8sIGNvbmZpcm1vLCBlc28gbm8gZnVuY2lvbmEuIEVsIHByb2JsZW1hIGNv bnRpbnVhLjxicj48YnI+PC9kaXY+U2FsdWRvcyw8YnI+PGJyPjwvZGl2PlBhbmNobzxicj48L2Rp dj5Dw7NyZG9iYTxicj48L2Rpdj5BcmdlbnRpbmE8YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIj5FbCBtYXIuLCAxIG5vdi4gMjAxNiBhIGxhcyA2OjU5 LCBmcmFuY2lzY28gcHJpZXRv

[Fidel Charny]

No Pancho. De esa forma no funciona, porque al instanciarse el form testea si es modal o no, y eso ocurre, según puedo entender, en el Init del form antes de que le puedas mandar el método show.
En cambio si funciona un parámetro

*<Form.Init>
LPARAMETERS tnWindowType
* Si se omite el parámetro vale el definido en el diseñador
IF VARTYPE(tnWindowType) = "N" AND BETWEEN(tnWindowType,0,1)
    this.WindowType = tnWindowType
ENDIF

DO FORM frm_NormMod WITH 1 to lxRespuesta.

No tiene mayor sentido, pero también funciona
DO FORM frm_NormMod WITH 1 NOSHOW to lxRespuesta
frm_NormMod.Show(1).

En cambio no tiene ningún sentido
DO FORM frm_NormMod with 1 NOSHOW to lxRespuesta
frm_NormMod.Show(0).
El formulario se instancia en realidad como Modeless y devolverá el valor, pero es de utilidad solo desde la ventana de comandos (ja, ja).