alt+F not working after calling pg_dump

I call pg_dump to create backup copies from my application
using Windows
CreateProcess() API call.

After pg_dump finishes, Alt+F ( to open File menu) and other
Alt key combinations in my application stop working.

If I use Alt+Tab to switch to other application and then back
to my application, Alt+F normal behaviour is restored.

The command which I use to backup database is

C:\Program Files\PostgreSQL\8.0\bin\pg_dump.exe -Z9 -b -v -f
"c:\my document\myfile.backup" -F c -h myserver -U postgres mydb

I pass password to pg_dump using environment variable PGPASSWORD

I pass only some Windows environment variables to pg_dump,
maybe some critical is missing.

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 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 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.

//Magnus

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

.. and also
what happens if you just call a bat-file that does nothing and then
exits.

After running bat file containing single line exit Alt+F key works.
After running bat file containg 3 lines

set pgpassword=x
C:\PROGRA~1\POSTGR~1\8.0\PGADMI~1\pg_dump.exe -Z9 -b -v -f "I:\051027 DEMO
backup.backup" -F c -h andrus -U postgres mydb
exit

Alt+F does not work.

So it seems that pg_dump.exe code causes Alt+F not working.

Andrus.