>I'm using a .chm file in my foxpro 7.0 app. On most machines it works just fine, but on some machines the .chm file starts behind the app when the user presses F1.
>Can anyone help?

This may be due to how you call the .chm file and the operating system your on. For example, if you are on Windows 2000 and are making the call to the .chm through shellexec from a top level library from a 'disconnected' part of the program (perhaps COM related...) the way Windows 2000 handles 'setting active' the window the help created is based on which process currently has 'control' and whether or not the window help got created in is 'related'/'trusted'/'a child' of that thread.

I need a breath after saying that....

Using the Windows API you can even grab the hWnd of the help window and call SetActiveWindow or SetForegroundWindow and it will make no difference if the calling 'thread' was not the one currently focused in the foreground.

The solution is to explicitly set the new 'thread' with the AttachThreadInput API instruction. This binds the new thread to the currently active one (you have to supply the hWnd of both I believe) after which you can SetForegroundWindow and undo the connection. You might also have to ShowWindow twice (hidden the first time then restore the second - don't ask why??? but it works).

I would try just the SetforegroundWindow API first - if that isn't enough put in the 2 ShowWindow API calls (hidden then restore) - and lastly do the AttachThreadInput if the situation is still not resolved.

Hope this helps...