BAT substitute



  • Yes, "BAT" as in DOS batch file. Put on your propeller hats, we're going oldschool...

    My job is as the back-end programmer on a team that produces computer-based training in Flash. One of the things we need to do from our courseware is view PDFs. Unfortunately, Flash in its modern incarnation has some ludicrously paranoid restrictions on its external launch functionality: You can only execute programs residing in a predefined "safe" subfolder from the main application, and it forbids passing arguments. Yikes. So to view PDFs, I have to create a unique batch file for each one of them containing essentially:

    @start ..\readings\oneofmany.pdf
    @exit

    This works, but it's an ugly hack that flashes a command prompt on the screen for a moment every time a PDF starts up. So this is my question--

    How hard would it be to create a tiny self-contained executable that examines its own filename, temporarily enables Command Extensions, and uses the built-in Start function to launch the indicated file, all without opening any intermediary windows? So for example, "mydocument.pdf.exe" would open "mydocument.pdf".

    I can't imagine this being very difficult to implement, but unfortunately I don't have access to any tools that can manage even "Hello World" without a multi-megabyte run-time library. That, and I haven't touched Win32 programming in years.



  • Why externally launch at all? Why not just link to the PDF and let the browser/plugin/OS settings deal with it?



  • You could do something in VB6 - It would take about two lines of code, and the runtime has been included in Windows since Windows 95.  It's old tech, but it still works.  All your code would have to do would be to add a module, set it as startup, and have the following code:

    Sub Main()
        Shell """C:\Program Files\adobe\Reader 8.0\Reader\AcroRd32.exe"" " & App.Path & App.EXEName
    End Sub



  • @Whiskey Tango Foxtrot? Over. said:

    Why externally launch at all? Why not just link to the PDF and let the browser/plugin/OS settings deal with it?

    When deployed on the web, that's just what it does. However, it's also distributed on CD in "projector" (executable) form. We used to simply put the web page on the CDs, but as of Flash Player 8, SWFs running from the local filesystem are blocked from communicating with their container page in any way. This made a lot of people angry, and has been widely regarded as a bad idea.

    VB and its ilk aren't an option, because I refuse to make any assumptions about what the end user already has installed on their system. This product is intended for people with highly variable levels of computer literacy, so it needs to be as plug-and-play as possible.

     



  • @Zylon said:

    When deployed on the web, that's just what it does. However, it's also distributed on CD in "projector" (executable) form. We used to simply put the web page on the CDs, but as of Flash Player 8, SWFs running from the local filesystem are blocked from communicating with their container page in any way. This made a lot of people angry, and has been widely regarded as a bad idea.

    Just a reminder: you're dealing with someone who's not terribly familiar with Flash -- I've avoided it successfully my whole career. That said, I still don't see why you can't link to the PDF and let the OS take care of it. A simple hyperlink of the style file://folder/file.pdf *definitely* works in any version of Windows 9x or greater that has Acrobat reader installed with the .pdf extension recognized (i.e. 99% of all Windows PCs out there), and should also work in *nix and OSX. I'm pretty sure that flash can at least get the path of its operating directory; all you have to do in that case is build the link. No need for batch files or scripting at all.



  • Um ... Windows Script Host?  It's already installed in Windows. 

    Create a file named test.vbs containing:

       set objShell = WScript.CreateObject("WScript.Shell")

       objShell.Run "cmd /k ping microsoft.com"

    Then double-click on test.vbs.

    There's more to it for what you want to do, but you can probably find a way for either Run or Exec to do what you want.

     

     



  • @Whiskey Tango Foxtrot? Over. said:

    Just a reminder: you're dealing with someone who's not terribly familiar with Flash -- I've avoided it successfully my whole career. That said, I still don't see why you can't link to the PDF and let the OS take care of it. A simple hyperlink of the style file://folder/file.pdf definitely works in any version of Windows 9x or greater that has Acrobat reader installed with the .pdf extension recognized (i.e. 99% of all Windows PCs out there), and should also work in *nix and OSX. I'm pretty sure that flash can at least get the path of its operating directory; all you have to do in that case is build the link. No need for batch files or scripting at all.

    Better yet, just use relative links from the flash file, then the links are the same whether it's online or offline.  I would hope that would work in flash.  It's been a key "feature" of HTML for, like ever :) 



  • @Zylon said:

    How hard would it be to create a tiny self-contained executable that examines its own filename, temporarily enables Command Extensions, and uses the built-in Start function to launch the indicated file, all without opening any intermediary windows? So for example, "mydocument.pdf.exe" would open "mydocument.pdf".

    I can't imagine this being very difficult to implement, but unfortunately I don't have access to any tools that can manage even "Hello World" without a multi-megabyte run-time library. That, and I haven't touched Win32 programming in years.

    This can be easily done with Delphi, and would be a stand-alone executable (no runtime needed). It's about a two-minute job, using the Windows Shell API:

    [code]
    FileToExecute := ChangeFileExt(ParamStr(0), '.PDF');
    ShellExecute(0, 'open', FileToExec, nil, nil, SW_NORMAL);
    Close;
    [/code]

    You wouldn't get the flash of the command window, and by setting [code]Application.ShowMainForm := False;[/code] in the project file, you wouldn't even get a flash of a button on the taskbar.


     



  • @KenW said:

    This can be easily done with Delphi, and would be a stand-alone executable (no runtime needed). It's about a two-minute job, using the Windows Shell API:

    [code]
    FileToExecute := ChangeFileExt(ParamStr(0), '.PDF');
    ShellExecute(0, 'open', FileToExec, nil, nil, SW_NORMAL);
    Close;
    [/code]

    You wouldn't get the flash of the command window, and by setting [code]Application.ShowMainForm := False;[/code] in the project file, you wouldn't even get a flash of a button on the taskbar.

    If you wanna go that far, then just do it in C.  The code is almost identical.  I wrote a small "start.exe" program to do more or less the same thing:

    #include <windows.h>

    int main(int argc, char** argv)
    {
        for(int i=1; i<argc; i++)
        {
        ShellExecute(NULL, NULL, argv[i], NULL, NULL, SW_SHOWNORMAL);
        }
        return 0;
    }

    to compile: cl.exe start.cpp /link shell32.lib



  • Don't forget -- you can't pass in parameters :).

    But can flash create an arbitrary (text) file in this directory? Then just have you executable read this file and launch stuff it points to. And in flash create this file with appropriate content before every launch.




  • #include <windows.h>

    int main(int argc, char** argv)
    {
        char* Dot1 = argv[0];
        char* Dot2;
        while(*Dot1!='.') Dot1++;
        Dot2 = Dot1+1;
        while(*Dot2!='.') Dot2++;
        *Dot2 = 0;
        ShellExecute(NULL, NULL, argv[0], NULL, NULL, SW_SHOWNORMAL);
        return 0;
    }

     

    Name the exe "whatever.pdf.exe" 


Log in to reply