Jürgen Welz
jwelz at hotmail.com
Fri Dec 2 10:18:05 CST 2005
Hey Marty: The form containing the file list box is modal so I was just passing the hWndAccessApp. We are running Win Server 2003 Standard Edition v 5.2 via dsl connection on Cisco VPN and Microsoft remote desktop software on diskless terminals. It is a terminal server type setup and users have no access to their desktop folder in the conventional sense and the security profiles prevent them from modifying things such as the startmenu or placing shortcuts or files on the desktop. I tried your GetDesktopWindow() example and it appears works in my profile, but then I have no problems launching the .Pee files in my profile after modifying the ShellEx code to call FindExecutableA, launch the application, Sleep for five seconds and then call itself again with the .Pee file. In the double click of the listbox, I use the Dir function to confirm the presence of the file even though the file list is generated by first polling the directories to handle the scenario where a folder of file is renamed since the list is populated. Since I've modified by Shell wrapper to call itself once recursively, I've had to test the passed string to determine whether it is a directory in order that it correctly opens folders with the test: If Len(Dir(strFile, vbDirectory)) Then... The code is not finalized but seems to have helped most users and it covers the bases it did before. I'll clean it up if and when the cause of the problem of launching of the .Pee files is determined. It was svelte before but right now it is a dirty bandaid. Stuart: The file associations are OK because, as mentioned, I call the FindExecutable API for Pee files so I can launch the MDI before opening the file. While this seems to have helped many users, it has not been a reliable resolution. For some people it works about 1/2 the time. Going straight to Explorer and double clicking the file seems to work about 80% of the time for certain users, and it generally works by the 2nd or third try. The reason I rewrote the ShellEx code is because opening these files works more frequently after the MDI is open, no matter whether it or a file is launched from Explorer or my Access code. What is curious is that the code may work for a certain user, he will close Access for lunch and when he comes back later, he is back to several attempts to open a file but then he can do something else for a while and Access will again work. There is a pretty clear improved consistency launching from Explorer over the ShellEx code and that strikes me as bizarre so my concern is that ShellExecute is not as good a replacement for the Explorer interface as I had once thought. One other piece of information, the application used a hardware key several years ago but now uses a licence manager to limit the number of instances of the application that can run concurrently to the number of licences paid. However, the problem manifests itself as inconsitently when we have a limited number or near the max instances open. When the max is exceeded, ShellEx will succeed, when it does, and the application will report that it cannot proceed and the user will shut it down. We have 4 Gigs of RAM on the server and my ldb checker has logged that the Access application generally has between 18 and 26 concurrent users. I am told by the IT department that their logs show numerous errors at the times when users fail to launch their .Pee files. The application that uses these files runs a Pervasive SQL engine that access 60 odd files in a folder below the .Pee file to load the data into the MDI application. One last comment, about a week after the 'upgrade' to the .Pee file application the RAM on our application server was doubled as a number of users were reporting frozen sessions when using some Rumba applications and the in house PowerBuilder/SQL Server application concurrently. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com > >Just a guess but are you doing >ShellExecute(frmMain.hWnd, "Open", sFileName, sParams, "", 1) > >It might be faster to open to the desktop window handle > >Private Declare Function GetDesktopWindow Lib "user32" () As Long >Dim Scr_hDC As Long >Scr_hDC = GetDesktopWindow() >StartDoc = ShellExecute(Scr_hDC, "Open", DocName, _ >"", "C:\Temp\", SW_SHOWNORMAL) > >See >http://support.microsoft.com/default.aspx?scid=kb;EN-US;q170918 > >You could also try tickling the file to be active intially with >If Dir(CompleteFilePath, vbDirectory + vbHidden + vbSystem + vbReadOnly >+ vbArchive) = "" Then >MsgBox """" & CompleteFilePath & """ cannot be found!", vbExclamation >end if > >Of course the .pee files, could also be incontinent ;)