Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Stop FPD26 app running twice in Windows

Status
Not open for further replies.

tilltek

Programmer
Mar 8, 2001
298
PH
I sometimes get a situation where a customer will ring me with a problem (various) caused by my FPD 2.6 system running more than once in a Windows dos box. One rang me and said she was getting an "out of memory" on a brand new machine. Turned out she was running my system 32 times. The screen saver was minimizing it so she'd start a new one.
I digress.
Is there something in FPD26, say a sys() or similar that will alert subsequent startups that the system is already running?
I want to avoid using the old dos trick of -if a file exists, quit - if not, make it - on shut down, delete it.
Ken F
 
There is no function within Foxpro to enable you to detect if the program is running already.

For one user I needed to create a Login screen and, once logged in, the program checked a table where an in-use flag was stored for each separate user. As implied, if the in-use flag was FALSE, upon successful program entry, the flag was set to TRUE. When the user Exited the program the in-use flag was again set to FALSE.

This method is far from fail-safe. If there should be an "ungraceful exit" or bug break, the flag is left erroneously set to TRUE. You can put a user over-ride in to allow knowledgable users to get in anyway after a verbose warning.

In spite of this not being a bombproof solution it dramatically reduced the occurances of duplicate program entries at this client's site.

Good Luck,
JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com
 
Tilltek,
A better way is to use a slightly different version of Jrbbldr's suggestion. Instead of a flag on the user's record in a table, lock that record instead, and leave it locked during the entier life of the session. Then, if you lose "Ungreacefully", the lock is removed by the OS automatically, so it prevents lots of tedious maintenance and mucking about. If the user tries to log on a second time with the same UserID, it will tell them that they are already logged in. (This is a message you must create, but you get the idea.)

Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Gentlemen, I think you may just have an answer between you.
I was going to use a dbf exclusive in 10, and leave it there in area 10, unused, for the whole session. A second session would try to use that same dbf exclusve, fail, and I could use that as the flag. Problem is, I have an app that, printed on A4 paper, runs to over 1000 pages. In that 1000 pages of code there are several (read "lots") of CLOSE DATABASES and I was dreading changing them to "USE in 3" "USE in 1" etc. so as to leave area 10 alone.
Will try this stuff tomorrow but I'm sure by looking at it that you're spot on.
Ken F

 
Hi tilltek,

What you want is quite easy to achieve.

Step:1 .. In your main.prg which starts you application.. ass the following as your first 5 lines.
**********************************************************
DEFINE WINDOW myApp FROM 1,1 to 5,5 NONE
ON ERROR DO myExit
MODI COMM C:\myAppl.txt WINDOW myApp NOWAIT
HIDE WINDOW myApp BOTTOM
ON ERROR && as you will follow your own ON ERROR routines
*********************************************************
Step:2 .. Then at the end of your same PRG, add the following.
*********************************************************
PROCEDURE myExit
WAIT WINDOW "Application is already running"
QUIT
*********************************************************

Step:3 .. Now create a text file "myAPp.txt" in the clients c:drive and save it. There is a need for only a single space in that file.. to avoid display of the content in the application screen.

Once the file is there, the application will open the file in read-write mode and lock it by itself. Next attempt cannot open that and so the error condition will logout the user. Simple trick. Isn't It?

This will take care of your requirement. I am making an FAQ on this :)
:) ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
 
Perhaps one should keep it as simple as possible...

Write a small routine that writes a small file to disk when the application starts for example: Running.now
Write a small routine that checks for the existence of this file as first thing in the main module and when found shuts down the application.
Also write a small routine to erase the file when the application shuts down normally as last routine in the main module.

The same can be applied to limit the number of users when using a multi user application, in that case you write a memvar to disk, when checked for existance the memvar will be increased up until your limit has been reached.
Those routines are all very simple to write.

Good luck.

Rob
 
* FindWindow()
getwind = regfn("FindWindow","CC","I")
* Set the first parameter of the call to getwind 0, null.
wclass=0
winname= [Screen Title Application]
apphand=callfn(getwind,wclass,winname)
*If the call was successful, stop processing.
IF apphand<>0
=dsp_msg(&quot;/o/l/b/t15&quot;,&quot;Previous instance of program is still running, please exit first.&quot;)
DO std_qt
ENDIF

You need foxtools.fll

 
dwd68071,
FoxTools and API calls aren't possible from FoxPro DOS (FPD) - even when running under Windows.

Rick
 
Here's the routine I use:

STORE 0 TO chk, tryit
IF FILE('C:\player.zzz')
tryit = FOPEN('C:\player.zzz', 2)
IF tryit < 0
WAIT WINDOW &quot;Program is already running! &quot;+;
&quot;Press a key to exit.&quot;
RETURN
ENDIF ( tryit < 0 )
ELSE
chk = FCREATE('c:\player.zzz')
ENDIF ( FILE('C:\player.zzz') )

Dave S.
 
Ramani, if you plan to make a FAQ, try this.

*----- Set the default folder
set default to c:\tilltek

*----- Setup a error handler just for this prg
on error do multierror

*----- Dump foxuser.dbf in this session
set resource off
use foxuser exclusive
set resource on

* Go on and run the app

return

*-----------------------------------------
procedure multierror
*
*----- If the error is FILE ACCESS DENIED
if error() = 1705

*----- Someone else has foxpro running
wait window &quot;NO CAN DO&quot;
quit

endif

return

I was putting together all the suggestions my question received when it sudenly dawned on me that there is one file that is open, and kept open, for the whole session, foxuser.dbf.
While any number of extra foxpro sessions can start, it is not possible for any of them to use foxuser.dbf exclusive without generating an error.

Ken F
 
There are a couple issues I have with using Foxuser.dbf as the test file. The first is, that some developers (like me) issue the statement SET RESOURCE OFF in the CONFIG.FP of the distributed app. So foxuser.dbf won't be open.

The other is that if you issue the statment:
USE FOXUSER AGAIN ALIAS SomeFile EXCLUSIVE
It will work just fine.

Just a couple points to ponder.
Dave S.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top