File Associations?

[Scott Morrow]

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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution