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