Re: alt+F not working after calling pg_dump

>> Any idea how to make Alt key to work in my application
>> immediately after calling pg_dump ?
>
> What parameters do you pass to CreateProcess()?

I use modified Ed Rauh API_APP class. Relevant part of of the calling code:

* This API call does the work. The parameters are as follows:
* lpszModuleName - ptr-> file name of module to execute. Since we aren't
launching .CPLs, do not use
* lpszCommandLine - ptr-> command to execute, as passed in method
* lpSecurityAttributesProcess - ptr-> SECURITY_ATTRIBUTES structure for
Process. Pass a null pointer
* lpSecurityAttributesThread - ptr-> SECURITY_ATTRIBUTES structure for
first thread. Pass a null pointer
* bInheritHandles - whether or not chlid inherits parent handles. Since
no SECURITY_ATTRIBUTES passed, default to FALSE
* dwCreateFlags - Process Creation Mode flag set. we use the default mode
at normal priority, ie 0
* lpvEnvironment - ptr-> a set of environment strings as if a MULTI_SZ.
We don't set, so pass a null pointer
* lpszStartupDir - ptr-> the starting directory. If none provided to
method, pass a null pointer
* lpStartInfo - ptr-> a STARTUPINFO structure. We use one structure
member at times.
* lpProcessInfo - ptr-> a PROCESS_INFORMATION structure, used to return
PID/PHANDLE detail. We use one member

DECLARE SHORT CreateProcess IN WIN32API AS CrPr ;
STRING lpszModuleName, ;
STRING @lpszCommandLine, ;
STRING lpSecurityAttributesProcess, ;
STRING lpSecurityAttributesThread, ;
SHORT bInheritHandles, ;
INTEGER dwCreateFlags, ;
STRING @lpvEnvironment, ;
STRING lpszStartupDir, ;
STRING @lpStartInfo, ;
STRING @lpProcessInfo

* Make default Structures for the CreateProcess call
*
* ProcessInfo - 4 bytes, a Process handle, a Thread Handle, a (DWORD)
ProcessId and a (DWORD) ThreadID
* we save the Process handle and return it to caller in
tnReturnProcessHandle

cProcessInfo = REPL(CHR(0),16)

* StartUpInfo is a 68 byte long complex structure; we either have 68 bytes
with a cb member (byte 1) 68
* or with cb of 68, dwFlag low order byte (byte 45) of 1, and low order
byte wShowWindow (byte 49) set to
* the SW_ value appropriate for the Window Mode desired.

* Use default of application
cStartUpInfo = CHR(68) + REPL(CHR(0),67)

LOCAL cstr

cstr= 'PGPASSWORD=xxx' +CHR(0)+ ;
'HOMEPATH='+GETENV('HOMEPATH') +CHR(0)+ ;
'SystemDrive='+GETENV('SystemDrive')+CHR(0)+ ;
'SystemRoot='+GETENV('SystemRoot')+CHR(0)+ ;
'USERDOMAIN='+GETENV('USERDOMAIN')+CHR(0)+ ;
'USERNAME='+GETENV('USERNAME')+CHR(0)+ ;
'USERPROFILE='+GETENV('USERPROFILE')+CHR(0)+ ;
'windir'+GETENV('windir')+CHR(0)+ CHR(0)

lResult = CrPr( 0, ;
cCommandLine, ;
0, 0, 0, 0, @cstr, ;
uFromDir, ;
@cStartUpInfo, ;
@cProcessInfo)

> I think you're bit by the general windows behaviour that a new process
> started by default will take focus away from your app, and it does not
> necessarily return it when it quits.

I'm not sure that this is the reason because:

1. I changed commandline parameter to c:\wind98\system32\chcp.com . In
this case, Alt+F works.
2. Other keys like Enter, Ctrl+K works in my application.
3. After calling pg_dump I tried BringWindowToFront procedure below as
described in
http://www.tek-tips.com/faqs.cfm?fid=4262
This does not fix the problem.

> I don't *think* it's pg_dump
> specific. It'd be interesting to know both about flags above, and also
> what happens if you just call a bat-file that does nothing and then
> exits.

Specifiing empty .bat file directly as CreateProcess() command line causes
Createprocess to return error.
I tried to run chcp.com (randomly seleted windows console app which does not
wait for user input).
After chcp.com finishes , Alt+F works.

Andrus.

* http://www.tek-tips.com/faqs.cfm?fid=4262
* Force Window to Front (not blink in taskbar)

* You may have noticed that when you try and bring your application's
* window to the front using API calls (SetForeGroundWindow and
* BringWindowToTop) that it just blinks down in the taskbar. This
* applies to Windows 2000 and later Microsoft OS's (see MS
* Documentation below). Well, if you would rather have your
* applicaiton's window truly come to the front (and I'm sure you do)
* then here's a VFP workaround using API calls.

* MS Documentation for SetForegroundWindow reads as follows:
* "Windows NT 5.0 and later: An application cannot force a window to the
* foreground while the user is working with another window. Instead,
* SetForegroundWindow will activate the window (see SetActiveWindow)
* and call the FlashWindowEx function to notify the user."
* ...and it appears that the same is true for BringWindowToTop.

* The only way Windows 2000 and Windows XP let you bring your
* application's window up to the front is if the thread it is running on
* is the thread of the foreground window at the time. So, you have to
* attach the thread of your application to the thread of the foreground
* window and then bring your application's window to the front. After
* that you need to detach your thread (this all only happens if the user
* has another application's window as the foreground active window).
* It looks like a lot, but really we are just tricking Windows into
* thinking that our application window is part of the foreground
* application so that it will let us bring our window up to the front
* rather than having it just blink in the taskbar. The key to this
* whole thing is the AttachThreadInput API calls.

DECLARE Long FindWindow In Win32API String, String

LOCAL nHWND, ccaption
ccaption = _screen.caption
_screen.caption = SYS(2015)
nHWND = FindWindow(Null,_screen.caption)
_screen.Caption = m.ccaption

If nHWND >0
ForceForegroundWindow(nHWND)
ENDIF
RETURN

PROCEDURE ForceForegroundWindow(lnHWND)

LOCAL nForeThread, nAppThread
DECLARE Long BringWindowToTop In Win32API Long
DECLARE Long ShowWindow In Win32API Long, Long

DECLARE INTEGER GetCurrentThreadId;
IN kernel32

DECLARE INTEGER GetWindowThreadProcessId IN user32;
INTEGER hWnd,;
INTEGER @ lpdwProcId

DECLARE INTEGER GetCurrentThreadId;
IN kernel32

DECLARE INTEGER AttachThreadInput IN user32 ;
INTEGER idAttach, ;
INTEGER idAttachTo, ;
INTEGER fAttach

DECLARE INTEGER GetForegroundWindow IN user32

nForeThread = GetWindowThreadProcessId(GetForegroundWindow(), 0)
nAppThread = GetCurrentThreadId()

IF nForeThread != nAppThread
* ? 'Different threads'

AttachThreadInput(nForeThread, nAppThread, .T.)
BringWindowToTop(lnHWND)
ShowWindow(lnHWND,3)
AttachThreadInput(nForeThread, nAppThread, .F.)
ELSE
* ? 'same threads'
BringWindowToTop(lnHWND)
ShowWindow(lnHWND,3)
ENDIF
ENDPROC