Hi dragan,

Interesting story, but not quite it.

The CTRL+S does not stop the application. The already openen forms proceed to work as normal. Even forms without init code in any off its contained will start without a problem.

However, when it contains any init-code, it will stop the load of the form. Only a key hit will display it, without or without an error.

Walter,




>>Hi aleksey,
>>
>>I've got a weird bug that took us a lot of time to track down.
>>
>>Clients reported that forms where hanging. On a DO FORM, it do load the form, but never got visible. Even activating the form via the Windows menu did not work. Apearantly the init was not fired because the forms did not have the translated captions (assigned in the init)
>>
>>We did not have a clue why this was happening as it was very difficult to reproduce. After a few days on of our members got it reproducable in our product.
>>
>>It seemed it was related to using CTRL+S. In our case we are using this shortcut on a menu to save records. To our surprise, when using another shortcut (CTRL+T) for saving, it became clear the CTRL+S, though not doing anything in our software (No shortcut on a menu and no ON KEY LABEL), still did cause started forms not to appear.
>>
>>
>>I drew the conclusion that it must be a VFP bug and tried the following.
>>1. On a form select a commandbutton or a page (of a pageframe)
>>2. Press CTRL+S (note that it was not doing anything as I did not use the shortcut in my software)
>>3. Try to start another form from the menu. The form would not appear.
>>4. Hit any key and the form will popup. In one of my products it generates an error "Feature not avialable on a line that is just a simple stringhandling command
>>
>>I could not reproduce this on another product and tried to find out the difference between the two. It turned out to be that SET STATUS BAR OFF did enable the bug.
>>
>>Now of course I want to use a 3rd party statusbar, but cannot because of this obscure bug. Can anyone confirm this bug to happen in their case ?
>>
>>I can confirm that in our case the bug is happening in:
>>-VFP8 SP1, VFP9SP1
>>-Windows XP, Windows 2000, Windows 2003 Server
>
>Let's call it "unintended behavior". On many older systems (CP/M, VT52 and VT100 terminals and their emulations, and probably DOS itself while in some phases of booting, maybe some *ixes as well) ctrl+S would suspend the output to console, and a repeated ctrl+s would resume. It was very useful for debugging boot sequences or generally any text which would whizz off the screen and wouldn't know how to come back (phenomenon commonly known as scrolling :).
>
>Now I'm not sure, but it could be that Ctrl+s would suspend the output to console in Fox, and if the status bar is waiting for that output (hidden, probably, but also probably still out there), and it was suspended, it would wait for it indefinitely. See if a repeated ctrl+s fixes it; if it does, then I may have had a grain of a hint.