No announcement yet.

ShellExecute vs Threading 101

  • Filter
  • Time
  • Show
Clear All
new posts

  • ShellExecute vs Threading 101

    When is ShellExecute more appropriate than using a thread?
    Please do not discuss TCP programs which definitely benefit.

    A program can be broken down into subprograms.
    Common DLL' can be shared by the subprograms.
    Interprocess communication can also be used.
    Printing can be done by simply shelling to a print subprogram
    and the user can continue on. Threading issues are no longer an issue.

    Writing smaller subprograms can eliminate redistributing code.
    It also encourages writing DLL's to do it once and reuse it.
    Other programmers can add subprograms without worrying about
    breaking other code. Writing smaller programs are easier to maintain, and faster to compile.
    Before threading consider "Pid??? = Shell()."

  • #2
    > When is ShellExecute more appropriate than using a thread?

    ShellExecute is not an alternative to multiple threads.

    ShellExecute launches a new process; you may or may not choose to monitor the progress of that process.

    With multiple threads your program executes entirely within the context of the original process.

    ShellExecute can be used if you don't need the results of some operation, and you don't care when it completes.. but that's also true of multiple threads of execution within a single process.

    Of course, if you are redistributing this application, now you have to distribute and install the additional program file. That should not be a big deal but I know it can be a 'matter of concern' for some.
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      If another process gets the same thing done, it is an alternative to creating a thread.


      • #4
        Not really..

        It is a separate process, where threads are part of the originating process.
        Warped by the rain, Driven by the snow...


        • #5
          This was intended to discuss when to use ShellExecute instead of a thread.


          • #6
            >Writing smaller programs are easier to maintain

            The individual programs, yes; however I've always thought a complete application was easier to maintain when ALL the code was in ONE program.

            Different strokes for different folks.

            > and faster to compile.

            Oh, come on. The largest module I compile (about 80K lines) takes ten-twelve seconds, tops. Typical programs (call it 5K-10K lines) compile so fast I can't expel a flatus whilst waiting.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]


            • #7
              The largest program I compile takes under 1-second.
              I used to write big programs, but it is not an advantage.

              What if you want to add a feature for only 1 person?
              You might have to update everybody.
              Writing smaller modular programs and placing code in common
              DLL's makes life much easier and promotes writing DLL's.

              I agree, use a style which works for you.
              I wouldn't mind a PB runtime or toolbox to reuse even more code.
              Last edited by Mike Doty; 27 Dec 2008, 10:42 AM.


              • #8
                What if you want to add a feature for only 1 person?
                You might have to update everybody.
                That's a marketing/support decision. When I made the decision to create 'package' software, I made it all the way: Nobody gets tailored versions of anything; when I add a new feature, everybody (on maintenance) gets it at the same time.

                With the PPPS ( the primary outputs are print reports; from experience I knew that users and prospects alike would forever be comparing "what we get now" versus "what we used to get" and I'd be pressured to create tailored versions. So what I did was design the software so I could add custom reports which would "plug in" to the system.. that is, Suzy can have her own favorite report without a tailored version of the basic software..

                This also allows Suzy to upgrade the base software without having to pay to re-insert her "modifications" - a terrific feature for anyone who has ever had tailored software and had experienced the case where you can't upgrade to a new version without re-modifiying the software at potentially considerable expense.

                Yes, it's done by using DLLs. Your custom report is just a function in a separate DLL; if the DLL is installed, it works.

                And yes, it does require the willingness to say 'no' to an order.


                PS: In deference to the thread topic, I suppose I could have done this with a child process instead of an in-process DLL function. But using a DLL was so much simpler... had I made it an EXE, there would be a lot of replicated code and then I WOULD be looking at re-modifying programs just to send out an update.
                Last edited by Michael Mattias; 27 Dec 2008, 11:09 AM.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]


                • #9
                  I get this all the time too, that certain users want their program to look THEIR way...and no one elses. (impossible to do unless you have a database of custom programs for each user, that may have only minor differences from each other)

                  Currently my main program on a slow computer compiles over 104K lines at about 208K lines per minute in 30 seconds (typical math)

                  DESIGN of a program MUST take Fundamental priority if you are to maintain a program over years of progress, fundamental changes, minor changes, multiple customers wanting their look vs your original design, etc, etc, etc.....

                  I too have tried the route of multiple DLL's (each for its purpose) but after time, they can be corrupted by compiing 1 version for 1 customer, and slightly different for another customer.

                  Threading or (opening multiple "Mini-Programs") in this case only gains you time on multiple processes going on at the same time, but then you have to control the results of each, know when to wait, and when to go, etc...etc....etc..... (Not to mention inter-communication between each)

                  Then I tried multiple INC files in 1 big program (You as the user gets the same program looking your way, and I as the programmer only have to update once per multiple user changes)

                  In my NOT use threads or "mini-programs" with the exception of processes that either take a long time, and you do not want the other processes to wait until the 1st is done, or if your process is dependant on some external device to complete and alert you that some "Event" has occured so you need to act on it. (much faster than polling to see if an event has happened)

                  Outside of that....I see no need for threads, "mini-programs", ShellExecute, or OTHER......

                  Keep it all internal, and you will find your mind much healthier wealthieer, and wise (without losing as much sleep as I have over the years of "What happened and how did I break it???" concept)

                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "


                  • #10
                    Once you make the decision you WILL support tailored versions, you have to do that "all the way," too: your design has to allow for it.

                    Trying to do either "tailored versions" or "package only with plug-ins" only partway is a stone loser.

                    Come to think of it, doing anything in life only partway is a stone loser.
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]


                    • #11
                      I use an approach like Michael. My primary ap is distributed to the customer "as is", and custom additions are in the form of a DLL given to a specific customer which the primary ap recognizes. The DLL functionality can be inserted several different places in the program depending on what its intended use is, and this is determined by a function call in the DLL itself.

                      If your application is modular, then DLLs are good if you re-use many of the same functions and procedures. If you have a single main module, then having everything in that module would make more sense. It is something that would differ depending on the ap. I think managing a modular ap would be a little more difficult, so a good design early on is key.
                      Scott Slater
                      Summit Computer Networks, Inc.