Is there a easy and bullet proof way to check if i have the same program running when i start a program? As i don't want the posibility to have the same program running multiple times. Could mess up things.
struct Task *mytask=FindTask("blu_manager"); if ((mytask!=0) && (mytask!=FindTask(0)))
This only works if the program has been started from the Workbench. If it's started from shell, the task name will be "Shell Process", so that FindTask will fail and your program can be started twice.
The usual way to prevent a program from being started twice is to create a public message port or a public semaphore after you have checked that it does not already exist.
To achieve this, you may consider registering your program as an application (through application.library) if it makes sense for the kind of program you are working on. Then you have an option to allow only one instance of your app, so if you launch it twice the first instance will be brought to front.
Edit: just saw the name of your program, maybe a commodity would be more suitable if it runs in the background as a kind of service.
This only works if the program has been started from the Workbench. If it's started from shell, the task name will be "Shell Process", so that FindTask will fail and your program can be started twice.
In addition, the user could rename the program (I frequently do that for programs with long names) and it wouldn't find itself even if started from WorkBench. Of the options presented so far, I think your suggestion of a public semaphore would be the simplest and most effective.
To achieve this, you may consider registering your program as an application (through application.library) if it makes sense for the kind of program you are working on. Then you have an option to allow only one instance of your app, so if you launch it twice the first instance will be brought to front.
Will that work if the user renames the program and/or has copies in several places? I have multiple copies of several programs with different names so I can start them with different sets of prefs. For example, I have Snoopy with prefs set to look for library openings only, Snoopy1 with the usual settings and Snoopy2 with all the possible options set in the prefs.
How about creating an arexx port,and check for that port when the program starts? In that way you'd know if it's running allready??? If this is a possibility? Never touched arexx before..
Yes, that's what NetSurf does. Other options (already mentioned) are registering as an application (via application.library) or as a commodity (through commodities.library) - really you should be doing this anyway, as it will either be an application or a commodity you are writing.
As for the other question, for images you need to use requester.class or TimedDosRequester from dos.library.
Will that work if the user renames the program and/or has copies in several places? I have multiple copies of several programs with different names so I can start them with different sets of prefs. For example, I have Snoopy with prefs set to look for library openings only, Snoopy1 with the usual settings and Snoopy2 with all the possible options set in the prefs.
The default behaviour with application.library is to provide a string and an URL when registering your app, then application.library will use them as an id regardless of the name of the executable. However, I think there are options to obtain the name of your app from the wb startup message so what you describe could be possible.
How about creating an arexx port,and check for that port when the program starts? In that way you'd know if it's running allready??? If this is a possibility? Never touched arexx before..
If you were planning on adding some ARexx commands to your application that might be a good idea. However, an ARexx port is just an extension of standard Exec message ports so it would be simpler to add an Exec message port. I suppose the advantage of a messge port over a semaphore is that you could also send a message telling your already running app to bring it's window to the front or something. If your only goal is to prevent 2 copies of the app from running then something like this might work:
struct MsgPort *myport; if (myport = FindPort("MyTestMsgPort")) return(RETURN_OK); // or clean up and then exit
Yes, that's what NetSurf does. Other options (already mentioned) are registering as an application (via application.library) or as a commodity (through commodities.library) - really you should be doing this anyway, as it will either be an application or a commodity you are writing
Just don't have application library stuff unwanted icons in my AmiDock or tools in my WorkBench Tools menu with no configuration option to turn off that behavior. I delete any programs that do that. Personally, I'm not to fond of application.library because it can force unwanted changes on me. That's just me though; others may like it.
I wasn't planning to add any arexx commands. The example works excelllent. Thank you very much.
Quote:
xenic wrote: @Antique If you were planning on adding some ARexx commands to your application that might be a good idea. However, an ARexx port is just an extension of standard Exec message ports so it would be simpler to add an Exec message port. I suppose the advantage of a messge port over a semaphore is that you could also send a message telling your already running app to bring it's window to the front or something. If your only goal is to prevent 2 copies of the app from running then something like this might work:
struct MsgPort *myport; if (myport = FindPort("MyTestMsgPort")) return(RETURN_OK); // or clean up and then exit
Just don't have application library stuff unwanted icons in my AmiDock or tools in my WorkBench Tools menu with no configuration option to turn off that behavior. I delete any programs that do that. Personally, I'm not to fond of application.library because it can force unwanted changes on me.
Registering a program with application.library does not add any icons in either AmiDock or the Workbench screen, unless the programmer tells the program to do so. The library itself does not force any changes on you.
Changes to my Amidock layout by adding icons for one. As Trixie points out, it's the programmer who is doing it; not necessarily application.library.
@trixie Quote:
Registering a program with application.library does not add any icons in either AmiDock or the Workbench screen, unless the programmer tells the program to do so. The library itself does not force any changes on you.
It is the programmers doing but application.library doesn't have any prefs to control what programs can do. I'm also under the impression that the author is no longer working on Amiga software. I'm somewhat suspicious about using non-opensource libraries that aren't integrated into the OS. If Hyperion doesn't own the code and it never gets updated then we end up with the same situalion we are in with ARexx & original Amiga speech system. Should programmers be using a system software component that may not be updated along with the rest of the OS? If Hyperion gets the code & can update it (like with some prefs) then I might be willing to try it in my little programs. Otherwise I'm steering clear of it.
These are all valid points. Changes are being made to application.library so I guess the OS developers have access to the source code, otherwise they wouldn't be able to update it.
But it would really be nice to hear that from the developers.
These are all valid points. Changes are being made to application.library so I guess the OS developers have access to the source code, otherwise they wouldn't be able to update it.
But it would really be nice to hear that from the developers.
That would be reassuring. If it is updated it might be nice to update the preferences definition (included in the XML prefs files) to point to a file that actually exists instead of http://www.amiga.com/DTDs/PrefsObjects-1.0.dtd. That URL also makes me wonder if there might not be some copyright issues when it comes to the XML preferences format. If you look at the application.library author's WEB site you will see a number of AmigaDE (or whatever it's called now) projects; which makes me wonder if he has some contractual obligations to Amiga Inc. which might prevent him from disclosing the application.library sources or performing further work on OS4 projects.