>>Hi,
>>
>>I have the following code in my application that creates a window in which a report is previewed. Here is the code:
>>

>>DEFINE WINDOW RepWindow ;
>>   FROM 1, 1 TO 20, 20 ;
>>   TITLE cReportTitle SYSTEM 
>>
>>ZOOM Window RepWindow  Max
>>
>>WAIT CLEAR 
>>
>>REPORT FORM (cReportFrxName) TO PRINTER PROMPT  PREVIEW WINDOW RepWindow
>>
>>RELEASE WINDOW RepWindow	
>>

>>
>>While user is previewing the report (at the line REPORT FORM above), a code in another place of the application scans all open windows, as such:
>>

>>lnForms = _screen.formcount
>>	 
>>FOR i = lnForms to 1 STEP -1
>>
>>     *-- try to release this form:
>>     _screen.Forms(i).Release
>>
>>ENDFOR
>>

>>
>>But the _screen.formcount does not seem to include the form created with the DEFINE WINDOW (above).
>>
>>How can I either include the form created with DEFINE WINDOW in the _screen.formcount? Or how can I check if this form created with DEFINE WINDOW exists?
>>
>>TIA
>
>Cetin's suggestion to use WEXISTS() almost work. That is, the code detects that the window exists. But when the code calls to release the window (RELEASE WINDOW RepWindow) the window does not go away. That is, if the Window is open and shows a Report Preview, RELEASE it does not affect it.
>Therefore, my question is, how do you close the Window programmatically? Or, when a user is previewing a FRX file and the Report Preview toolbar shows the icon to Close the Preview, what command is fired? If I knew this command, I would call it programatically.

Have you tried executing code like the following?

for I=1 to wchild()
   ? wchild(m.i-1)
endfor

If you're trying this in the IDE, it might help to add NOWAIT clause to the REPORT statement so you'll have access to the command window.

You've probably noticed already that windows created using "legacy" DEFINE WINDOW command don't behave quite the same as "regular" forms -- and code that plays mix-and-match with the older legacy styles and newer styles will likely result in maddening situations where you get into the "almost-but-not-quite" situations where you get it working about 95% the way you want, but that last 5% becomes elusive, and you spend days wracking your brain on something that should seem like an easy thing to fix.