Hello Scott This post has the scripting I use for "Relaunch" so that multiple instance of the app won't launch. I'm using it with a Splash-screen design as well. There are 2 script blocks, the first of which has to go at the stack level. The pile of comments indicates how insecure I was with the code. Below the "Relaunch" script is additional code I placed at the card level of the Splash-screen stack (I'm not sure it needs to be there) I'll post again about registry.
- Scott Morrow -- -- > In the main stack script of the Splash-screen (executable) and in fact can't be placed at the card level. ------------------------------------------------------------ ---- Begin Relaunch Block ------------------------------------- ------------------------------------------------------------ -- -- If the applications mainstack (not sent to the card) has a 'relaunch' handler, then Revolution will treat -- -- it as a 'single-instance' application. This means that if a second instance is launched -- -- the original instance will be sent a 'relaunch' message before the new instance starts up. on relaunch -- -- The parameters for relaunch are the command-line arguments passed when invoking the -- -- new instance. Revolution does the same processing of these as it does for the $n -- -- global variables. i.e. -- -- 1 ) It splits the command-line up into Words -- -- 2 ) Removes quotes bracketing any quoted argument -- -- 3 ) Replaces '\' with '/' -- put empty into tParamList repeat with tIndex = 1 to the paramCount -- get Log(" param(" & tIndex & ") = " & param(tIndex)) put param(tIndex) &CR after tParamList end repeat put token 1 to -1 of tParamList into tParamList -- -- Passing the relaunch message will cause the new instance to continue to load. -- if the hilite of btn "Pass Relaunch" then -- get Log("Passing Relaunch") -- pass relaunch -- end if -- -- Returning background will cause the existing instance to remain in the background -- -- and the new instance to quit. -- if the hilite of btn "Remain in Background" then -- get Log("Relaunch and Remaining in background") -- return "background" -- end if -- get Log("Relaunch Processed") -- -- Try to keep processing in the relaunch handler to a minimum as the new instance -- -- waits for a reply. In particular, you must not open any windows (especially modal -- -- dialogs) as this will cause an automatic pass. -- -- Therefore, it is best to do the main part of the processing after relaunch has -- -- sent back its acknowledgement. To do this we send a message to be executed as soon as -- -- the current handler stack resolves. -- send "processRelaunch param(1)" to me in 0 millisecs send "processRelaunch" && tParamList to cd 1 of me in 0 millisecs -- -- Returning empty will cause the existing instance to be brought to the front, and -- -- the new instance to quit. return empty end relaunch -- As described above, it is best to do all the processing of the relaunch *after* -- the relaunch message has been acknowledged. -- Here we just open an open-file dialog with the path passed to the command-line. -- -- Note that when a modal dialog is being displayed, you can still receive the 'relaunch' -- message. However, using messages as we have here will result in them being -- automatically queued. ------------------------------------------------------------ ---- End Relaunch Block --------------------------------------- ------------------------------------------------------------ -- --> Card Level of the Splash-screen stack -- this handler recieves a list of files that caught by the "Relaunch" handler in the stack script -- multiple instances of this Splash executable were not allowed to launch -- and the file paths were passed along to the currently running instance of the Splash executable -- were we can open them -- this handler is nearly the same as the esOpenAppleEventDoc handler on processRelaunch tFilesPathsToOpen if tFilesPathsToOpen <> empty then -- there was a relaunch message handled by the stack script repeat for each line tNewDataPath in tFilesPathsToOpen -- could be multiple files VerifyClassFile tNewDataPath -- Mr. Rossi can ignore this line, I'm just verifying a file before trying to open it send "PreOpenStack" to stack tNewDataPath end repeat end if end processRelaunch On Mar 2, 2010, at 10:48 PM, Scott Rossi wrote: > Recently, I wrote: > >>> For documents launching multiple instances see < relaunch > in the >>> dictionary >>> where there is a note to look at an example stack. >> >> In my stack, the relaunch message is apparently not being called for some >> reason. I've tried placing it in the stack script and in a stack script >> behavior, and still nothing is happening. Still trying to figure out what's >> going on. > > Is it possible that the relaunch message is failing for me because I'm using > a splash/data arrangement for my standalone? My splash executable launches > a data stack and then closes the launching stack. Could this be why any > subsequent launches of the EXE don't trigger the relaunch handler? > > Regards, > > Scott Rossi > Creative Director > Tactile Media, UX Design > > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution