Paul, I think I have found the underlying cause of this problem. Why removing the reference to the routine allows it to (mostly) work, is still a mystery.
I created my own routine to perform both the SET_BROWSE_FOR_FOLDER_INITIAL@() the browse for folder function long ago. It turns out, there were problems with the arguments to the library functions. They were type'd correctly, but not 'formed' properly.
My routine is supposed to take the path and run the SET_BROWSE_FOR_FOLDER_INITIAL@(). The window handle is also passed to the routine, but there seems to be a potential issue here (see below). The browse_for_folder1@() is run using the logical result to see if the user had selected.
The initial search folder (in some instances) was formed from concatenation of a trim() of a the path string, then a CHAR(0). What this did was to arbitrarily limit the response by the user to the number of characters up to the NULL character. If you chose a folder with a longer name, I get a Floating Point Stack fault. This may have been part of my initial problem report (of long ago).
In the example I was running, the initial string was long enough to accept the new selection once the selection could be made.
While the browse_for_folder1@() function can take a zero for a window callback, I had set a local variable to what I thought would be the active window handle (call back). However, the actual return value from CLEARWIN_INFO@('CALLBACK_WINDOW') was the handle of the window I had just exited. Therefore, the handle was invalid. This appeared to cause other problems that I had not yet posted about. I added a function call to ISWINDOW() in the routine to verify the validity of the handle, and use a zero if the handle is not valid.
I re-enabled the ALLOCATE in the 'bypased' routine, re-ran my test and had no problems encountered whatsoever.
I have scanned my other code for similar //CHAR(0) occurrences to make sure this doesn't happen again.
So the 'bypassed' routine occurred BEFORE the call to my function.