forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Preventing multiple instances of a program from running
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2241
Location: Yateley, Hants, UK

PostPosted: Sun Dec 13, 2020 3:23 pm    Post subject: Reply with quote

I have an application that prevents multiple invocations of an accessory but standalone app by broadcasting a message, which if answered appropriately prevents another launch. That method might be employed to stop a program loading for a second time. The facilities exist already in CW+

Bill says that this is to solve problems of two or more instances of a program trying to access the same file(s), and of course, that can be resolved by making each instance of a program use its own files. FTN95 has a routine to produce unique filenames for scratch files, for example.

Otherwise, one always has a choice between an MDI program or multiple instances of an SDI program if the user is to be allowed to operate on multiple datasets at the same time. I have always opted for the latter, largely because it does not require a fresh memory allocation for each MDI document – running multiple instances of an SDI program does it for you. Incidentally, I’m lost in admiration for those with the mental agility to program MDI ! Also, my personal experience of MDI apps is that sometimes I go to close off one window and accidentally shut off the lot – and that’s with commercial software where I would expect something better than a brief warning that is accepted with a mouse click ‘bounce’ ! I don’t do this so often with multiple SDI apps, particularly my own, as they usually display a nice big picture and that tells me better than anything else which one I want to shut down.

It does seem to me that if Paul was so minded, he might be better placed than anyone to create a routine to do Bill’s job: I suggest a name - FORBID_MULTIPLE_INSTANCES@

Eddie
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1003
Location: Morrison, CO, USA

PostPosted: Sun Dec 13, 2020 3:30 pm    Post subject: Reply with quote

Eddie, thanks for the comments.

I think the %nc command for inter-process communications would work well. It would force the user to have only one routine capable of talking with its partner.

As far as MDI vs SDI, I have done MDI before, and it was tricky, but not overly so.

I'm good with Paul's efforts on my behalf to understand what is going on, and directing me in alternate paths. Using the CLASSNAME is tricky regardless of any other constraints. I have a skeletal framework in place to try it out, but have run into another snag that is really troubling and befuddling me!
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1003
Location: Morrison, CO, USA

PostPosted: Sun Dec 13, 2020 4:18 pm    Post subject: Reply with quote

jalih,

Yes, you are are absolutely correct. Even I have started multiple instances with an aberrant "double click". And, the process I have in mind will likely not capture this.

I have been reading up on the mutex concept and it has relevance, for sure. From a quick check of the WIN32API interface, it would appear that all the MUTEX API calls are provided. Some of the others (like CoCreateGuid) are not in the standard library. Perhaps there are other ways to accomplish this same idea.

It's not that the users MUST NOT run multiple instances, just that they SHOULD NOT unless they know what they are doing. I had one user that had a dozen instances started because he misunderstood the concepts of a menu selection. His thought was once I go down a path, I cannot get back and do something else. So, you can see why there are problems!
Back to top
View user's profile Send private message Visit poster's website
jalih



Joined: 30 Jul 2012
Posts: 194

PostPosted: Sun Dec 13, 2020 6:28 pm    Post subject: Re: Reply with quote

wahorger wrote:
jalih,
I have been reading up on the mutex concept and it has relevance, for sure. From a quick check of the WIN32API interface, it would appear that all the MUTEX API calls are provided. Some of the others (like CoCreateGuid) are not in the standard library. Perhaps there are other ways to accomplish this same idea.


You can just use some null terminated string unique to your application as a name for mutex instead of using GUID as string. So, you only need OpenMutex() and CreateMutex() calls.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1003
Location: Morrison, CO, USA

PostPosted: Sun Dec 13, 2020 8:30 pm    Post subject: Reply with quote

Thanks for the hint! Saves me a lot of work!
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7086
Location: Salford, UK

PostPosted: Mon Dec 14, 2020 11:15 am    Post subject: Reply with quote

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....
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1003
Location: Morrison, CO, USA

PostPosted: Mon Dec 14, 2020 4:24 pm    Post subject: Reply with quote

Paul, thanks for the "tease". Looking forward to it!
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7086
Location: Salford, UK

PostPosted: Mon Dec 14, 2020 5:59 pm    Post subject: Reply with quote

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.

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

Code:

C_EXTERNAL CLEARWIN_PARAM@ '__clearwin_param'(INSTRING,INSTRING)
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1003
Location: Morrison, CO, USA

PostPosted: Thu Feb 04, 2021 7:00 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group