ShellExecute vs Threading 101

[Mike Doty]

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()."

[Michael Mattias]

> 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.

[Mike Doty]

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

[Jim Padgett]

Not really..

It is a separate process, where threads are part of the originating process.

[Mike Doty]

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

[Michael Mattias]

>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.

[Mike Doty]

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.

[Michael Mattias]

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 (http://www.providerpaymentpartner.com) 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.

MCM

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.

[Cliff Nichols]

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 opinion...do 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)

[Michael Mattias]

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.

[Scott Slater]

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.