What happens to a VB app when/if timers start to stack up or overlap 1

[SBendBuckeye]

Hello All,

I inherited a VB 6.0 app with several different timers on the main form. Users complain of inconsistent updates but I have not been able to reproduce the problem.

My background is more VBA than VB, so please bear with me. Would I be better off spawning some of the timers off as separate exes so they ran on their own thread? Obviously this would only work if the timers could run asyncronously.

I have already done the above with an enhancement that reacts to Outlook email messages. It runs on its own timer and processes incoming messages every 10 seconds. The main app kicks if off during load processing and then uses the PostMessage API to tell it to shut itself down when it is unloading.

For purposes of our discussion, let's say the main app has 4 timers, 1 firing every 6 seconds, 1 every 30 seconds, 1 every 10 seconds and 1 every 15 seconds and all of them can process asyncronously. What would be the advantages and disadvantages of splitting them into separate exes and having the main app kick them off and then shut them down as opposed to handling them all all itself.

Thanks for any ideas and/or suggestions!

Have a great day!

j2consulting@yahoo.com

 

[Dashley]

SbendBuckey

One big disadvange I think would be the mount of time and overhead it takes to call the exe up kill it and recall it every 6/10/15 seconds. Outlook was never that fast loading in general.

Dan

 

[SBendBuckeye]

Sorry, I did not communicate clearly. They would be separate VB projects which would each run independently of each other. So they are started once and then run until told to shut down by the main app when it closes.

In the case of the Outlook piece I referenced, it contains a module level Outlook Application variable and uses automation to control it. When the timer fires it tries to get an existing instance using GetObject and then creates one using CreateObject if it needs to do so.



Have a great day!

j2consulting@yahoo.com

 

[LegoPiece]

1. STACKED TIMER APPROACH

PROS
* All data is shared within a single app
* Simpler to control application through single interface
* No API calls

CONS
* Spaghetti Code
* Without proper memory management, stacking timers can cause freeze-ups and missed reads (this is purely through experience).
* Complex Fault Isolation. Tracing the source of an error becomes more cryptic since everything's lumped together

2. MULTI-PROCESSING APPROACH

PROS
* Modular Code
* Direct fault/error identification and isolation
* Efficient execution through simpler, seggregated tasks

CONS
* Data sharing difficult without proper IPC (API calls req.)
* Mechanism required to manage improper shutdown of exes

--------------------
3. MY TWO CENTS

Use ActiveX Exes. These are out-of-process components which run in their own thread and have mechanisms for Asynchronous notification. On top of this, they have very clean class-based interfaces with events and can run form-lessly. They absolutely saved me from possible trade show disaster, when confronted with a multi-robot application, controlling and monitoring 5 real-time lab devices. If ActiveX Exes can handle that, then Outlook will be a snip!

Peace
Lego

"People have accused us of releasing the same album 16 times - that's simply not true. We've released the same album 17 times!" - Angus Young, AC/DC

 

[SBendBuckeye]

Thanks LP,

This app is something I support part time and its strictly a low budget operation so I'll probably need to go with your 2nd option above. Thanks for mentioning improper shutdown, I had overlooked that in my testing.

Here is how I have implemented it thus far:

1. Parent exe spawns chile exe using WinExec API
2. Child exe opens a hidden form
3. Parent finds and saves child hWnd using FindWindow API
4. During Parent shut down, it shuts down child exe using PostMessage API

Am I missing an obvious better way to do this? My background is more VBA than VB. Thanks for responding.

Have a great day!

j2consulting@yahoo.com

 

[LegoPiece]

Hey SBB,

I've not used the approach you described above to implement a multi-process scenario, however if it works then I can't personally think of an 'obvious' better way to do this. There are different ways to skin a cat (I hate that term, being a proud cat owner), and the way I'd implement a similar architecture wouldn't really save any more time or grievience so go for it! I'd be glad to give you more info on the method I adopt if you like, however if and when you get time after this - definitely check out ActiveX EXEs + see if they can work for you in future.

Peace
Lego

"People have accused us of releasing the same album 16 times - that's simply not true. We've released the same album 17 times!" - Angus Young, AC/DC