[AccessD] ShellExecuteA

Hi Jurgen,

Taking a complete stab in the dark here, but since you mentioned this is a 
locked down terminal services environment, is it possible there are user 
permission issues on the upgraded application?

Stuart

-----Original Message-----
From: "Jürgen Welz" <jwelz at hotmail.com>
To: accessd at databaseadvisors.com
Date: Fri, 02 Dec 2005 09:18:05 -0700
Subject: Re: [AccessD] ShellExecuteA

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