Preventing multiple instances of a program from running

The use of a mutex does appear to be more robust and may well be the best and simplest way forward to resolve this issue.

At the same time, Bill's investigation has revealed the more general limitations of using %mi and %nc.

The addition of a new ClearWin+ function (akin to CLEARWIN_OPTION@) could provide a simpler alternative to using %mi and %nc whilst also providing additional options for the ClearWin+ programmer.

More details to follow shortly....

Paul, thanks for the 'tease'. Looking forward to it!

Here is a sample that illustrates a new library routine called clearwin_param@. It can be used to set the default class, icon and cursor and is called before any other ClearWin+ routine. The cursor relates to the background client area and not the controls.

winapp
program main
use clrwin
call clearwin_param@('class',    'Myclass')
call clearwin_param@('icon',     'myicon')
call clearwin_param@('cursor',   'mycursor')
iw = winio@('%ww%cnTesting the app...%ff%nl%cn%6bb[Close]')
end program main
resources
myicon   ICON   sl.ico
mycursor CURSOR cursor.cur

A temporary interface (pending a new clearwin.ins etc.) is

C_EXTERNAL CLEARWIN_PARAM@ '__clearwin_param'(INSTRING,INSTRING)

My follow-up. This is all working great!

Thanks, Paul, for adding these features! They really do help a great deal!

My original purpose is to not allow two instances of a specific program (there are 4 separate programs) unless the user specifically allows it. Each separate program is assigned its own name. This is used as the input to a routine that 'mangles' the name, adding a 5 digit random number. For example, 'CMaster' (a base name) might be turned into 'CMaster61857'. This class name is set as the default class name for all windows I create.

For the main (first) window, I manually set its name to the base name ('CMaster'). The %nc command works fine to override the config_params@() default setting. It is on this base class name that I look for another instance BEFORE I create the first window in my program. Stated another way, I don't create any windows before I go checking for a window with this class name. This lets me look for another instance before I ask the question, and the user can pick whether to allow multiple occurrences or not.

In my first (main) window, I capture and save the handle to the window to be used when terminating the program. This is important. If I were to cycle through all windows with this class name, I would terminate other running instances of this program! Not what is intended!

When the program is ready to be terminated, there is some housekeeping to be completed, but mainly, any open windows should be closed. Because the class name of all windows of this instance of the program are uniquely named (except the first, main window), I can use a loop that finds windows by class name (no caption) and destroys them. The main window is closed specifically by the handle that was saved when it was created.

This works really well.

If I want to add the capability of using the caption of the main window (which contains unique information about the data being operated on) to further refine the condition of multiple occurrences to only those operating on the same data, I can do this as well!

Jalih, Do you have your parallel library for 64bit FTN95? I used 32bit one before, and it worked flawlessly, but not anymore, i completely switched to 64bit