![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Dec 13, 2020 3:23 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
wahorger
![](http://cjdsoftware.com/wp-content/uploads/2016/06/cjd-color-avatar.png)
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Dec 13, 2020 3:30 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
wahorger
![](http://cjdsoftware.com/wp-content/uploads/2016/06/cjd-color-avatar.png)
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Dec 13, 2020 4:18 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Sun Dec 13, 2020 6:28 pm Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
wahorger
![](http://cjdsoftware.com/wp-content/uploads/2016/06/cjd-color-avatar.png)
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Dec 13, 2020 8:30 pm Post subject: |
|
|
Thanks for the hint! Saves me a lot of work! |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7926 Location: Salford, UK
|
Posted: Mon Dec 14, 2020 11:15 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
wahorger
![](http://cjdsoftware.com/wp-content/uploads/2016/06/cjd-color-avatar.png)
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Dec 14, 2020 4:24 pm Post subject: |
|
|
Paul, thanks for the "tease". Looking forward to it! |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7926 Location: Salford, UK
|
Posted: Mon Dec 14, 2020 5:59 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
wahorger
![](http://cjdsoftware.com/wp-content/uploads/2016/06/cjd-color-avatar.png)
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Feb 04, 2021 7:00 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Nov 02, 2022 6:07 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|