The forms designer window properties includes a flag to set a window to be a dialog box (this besides the other dialog box flag that sets a border option). There are two different function to call a window, Start_Window and Dialog_Box. There are different functions to end a window, End_Dialog and End_Window, as well as the option of just closing the window.

What are the implications of failing to be consistent in the matching of the window setup option and the choice of functions used to open and close the window? How do various mismatches affect the memory and heap management?

The dialog checkbox in the form properties is explained here.

Dialog_Box and End_Dialog are simply wrappers around Start_Window and End_WIndow that allow you to organize your code so it you can get a returned value in a linear fashion.

Calling Dialog_box and then end_window means you won't get a value back from your dialog_box call

Calling Start_Window and End_Dialog will simply close the window.

End_Window simple terminates a window (via Utility DESTROY) and frees the window common area- it won't for instance run any record unlocking or savewarn processing as that's done from the system CLOSE event which in turn calls End_Window().

These functions do not impact on Memory or heap management negatively unless you kill a window via a direct Utility DESTROY in which case you'd end up with an "orphaned" window common area which could still be manually freed (though why you would do this is beyond me…)

Regards

Carl

And when common is "freed" does that merely set the common variables to null, or does it reset the common heap pointer as well? We are having a problem with common areas being cleared but other mysterious forces and I'm trying to track it down.

View this thread on the Works forum...