locked
Launching EXE as part of a Dynamic Suite Composition RRS feed

  • Question

  • I have a situation where I have created a dynamic suite.  One of the child applications needs to launch when the parent/primary application is launched.  I can't seem to get it to work.  First, it seems to me that any OSD scripting does not run in any of the child applications when using dynamic suite composition--is that accurate?  I haven't been able to get an OSD scripts in the child application to run when the parent is launched.  So, I put the code to launch the child application in the OSD of the parent application like so:
    <SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="FALSE" PROTECT="TRUE">
    <SCRIPTBODY>
    Y:\\myapp\\VFS\\CSIDL_PROGRAM_FILES\\myapp\\mydir\\myapp.exe prepareViewer
    </SCRIPTBODY>
    </SCRIPT>
    As you can see, the child's exe does have a parameter that it needs to use of prepareViewer. 

    Can anyone tell me what I'm doing wrong here?  It just doesn't launch the child app from the parent app's OSD file.  I know I have the Dynamic Suite set up correctly in the parent OSD as it is able to access the child app later.  The problem is that if the child app isn't in the systray when the parent app calls it, it launches it, but the user has to click the button again to actually load the data from the parent app into the child.  If I have the child app running when the parent launches (or right after) this situation will be avoided and the data loads immediately as it should.

    Thanks!
    Wednesday, March 17, 2010 6:24 PM
    Moderator

Answers

  • Hi,

    " First, it seems to me that any OSD scripting does not run in any of the child applications when using dynamic suite composition--is that accurate?"

    Yes, this is by design. For a customer, colleagues of mine implemented a tool that scans all the dependencie's scripts/environment settings and applies them to the Target Package, but this can't be applied to every DSC - and it's not public.

    What you could try is to create a "launcher" (let's name that "launcher.cmd" that first launches childapp.exe and then later on launches parentapp.exe.
    The sript should be placed outside of the package or within the Parent Package.

    Then you don't call "ParentApp" with the "ChildApp" via OSD-Scripting. Rather you directly call Launcher.cmd

    Does that make sense?

    (right, you may use any other language to create the Launcher - and you remember that user's have to have the right to execute CMDs ...)


    Falko
    • Proposed as answer by znack Thursday, March 18, 2010 6:30 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Wednesday, March 17, 2010 7:07 PM
    Moderator
  • When you use DSC you are essentially just opening the SFT of the child app and making it visible to the parent app.  You are circumventing the child OSD altogther, so if you need ANYTHING from the child OSD (eg. variables, path statements, working directory, exe or parameters) then you will need to add these to the parent OSD.  I'm not sure I fully follow what is/isn't working for you now, but I would check that you have added the prepareViewer parameter to the parent OSD along with anything else that's missing from the child osd.  A 'laucher' as decribed by Falko is also a good option to give you more control over what happens and when.

    Danny

    • Proposed as answer by znack Friday, March 19, 2010 12:57 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Friday, March 19, 2010 12:42 PM
  • I don't know what happened, but my code above started working.  After it started working, I changed it to use <HREF> tags instead of <SCRIPTBODY> tags so that the command window wouldn't show up and it still launched.  I didn't changed anything.  Odd.

    Anyway, thanks for your assistance!

    • Proposed as answer by znack Friday, March 19, 2010 11:07 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Friday, March 19, 2010 7:36 PM
    Moderator

All replies

  • Hi,

    " First, it seems to me that any OSD scripting does not run in any of the child applications when using dynamic suite composition--is that accurate?"

    Yes, this is by design. For a customer, colleagues of mine implemented a tool that scans all the dependencie's scripts/environment settings and applies them to the Target Package, but this can't be applied to every DSC - and it's not public.

    What you could try is to create a "launcher" (let's name that "launcher.cmd" that first launches childapp.exe and then later on launches parentapp.exe.
    The sript should be placed outside of the package or within the Parent Package.

    Then you don't call "ParentApp" with the "ChildApp" via OSD-Scripting. Rather you directly call Launcher.cmd

    Does that make sense?

    (right, you may use any other language to create the Launcher - and you remember that user's have to have the right to execute CMDs ...)


    Falko
    • Proposed as answer by znack Thursday, March 18, 2010 6:30 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Wednesday, March 17, 2010 7:07 PM
    Moderator
  • So you are saying to create the cmd and put it in FILENAME in the OSD of the parent app as opposed to doing it like I did in my first post?  When they launch the parent app it launches the child first, then the parent.  Doing it that way, will the CMD have access to the child app's virtual folder on my Y:\ at the time it runs?  I'm not sure why my OSD script wouldn't work the way I listed it above since that code is in the parent app's OSD file unless it just doesn't have access to the child app's virtual environment until sometime later in the process.  I had tried Post-Launch timing as well, but it didn't make a difference.
    Wednesday, March 17, 2010 7:18 PM
    Moderator
  • When you use DSC you are essentially just opening the SFT of the child app and making it visible to the parent app.  You are circumventing the child OSD altogther, so if you need ANYTHING from the child OSD (eg. variables, path statements, working directory, exe or parameters) then you will need to add these to the parent OSD.  I'm not sure I fully follow what is/isn't working for you now, but I would check that you have added the prepareViewer parameter to the parent OSD along with anything else that's missing from the child osd.  A 'laucher' as decribed by Falko is also a good option to give you more control over what happens and when.

    Danny

    • Proposed as answer by znack Friday, March 19, 2010 12:57 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Friday, March 19, 2010 12:42 PM
  • I put
    <SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="FALSE" PROTECT="TRUE">
    <SCRIPTBODY>
    Y:\\myapp\\VFS\\CSIDL_PROGRAM_FILES\\myapp\\mydir\\myapp.exe prepareViewer
    </SCRIPTBODY>
    </SCRIPT>
    

    in the parent OSD file.  Myapp.exe is in the child application's virtual folder on y:.  I'm using DSC to link the child app that contains myapp.exe to the parent app that has the code above in its OSD file.  Is there no way to have myapp.exe pre-launch through the parent app's OSD file?  Is my syntax in the parent app wrong to launch the child app?

    That is good to know that the child app's OSD file gets circumvented altogether when using DSC, but I'm still not clear if it is possible to launch the child app's exe from the parent app.  If it is possible, what is wrong with my code above because it isn't working...

    Thanks for your assistance.

    Friday, March 19, 2010 2:37 PM
    Moderator
  • I don't know what happened, but my code above started working.  After it started working, I changed it to use <HREF> tags instead of <SCRIPTBODY> tags so that the command window wouldn't show up and it still launched.  I didn't changed anything.  Odd.

    Anyway, thanks for your assistance!

    • Proposed as answer by znack Friday, March 19, 2010 11:07 PM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:19 AM
    Friday, March 19, 2010 7:36 PM
    Moderator