IVR with Magic Flow / News: Recent posts

I'm going to split the Tone Recognition object out from the WavePlayer project and make it its own project. Actually WavePlayer is an anomoly as it is really a WaveAudio object given it records etc.

Also, as soon as I test the multi-threading ThreadHelper and make sure it works, I'll post the IVR Server application. At that point the whole enchilada will be there.

Wayne

After much research, trial and effort I believe I have a replacement and new WavePlayer object. Turns out I had a bunch of global vars in vb modules rather than class instance variables. ThreadFactorys product in essence was creating my object (waveplayer, ivr client) etc on seperate threads and also treating them as if they were single use (making a copy of all the variables, even those in vbmodules). This worked fine but when I went to my vb.net com dll thread helper replacement, it exposed this flaw. ... read more

Well, my attempt at having the VB6 server app call a VB.Net assembly with a com-callable wrapper, which would then spawn the VB6 IVR Client apps on seperate threads to control each phone line has had limited success.

The VB.Net assembly appears to have the ability to instantiate the IVR Client VB6 Dll on a seperate thread, but my WavePlayer Dll just won't work right underneath the IVR Client dll once you create more than one thread. ... read more

As you know, VB6 isn't multi-threaded. I've been using HalfTime's ThreadFactory to spawn each IVR client (manages a phone line) on a seperate thread. Given I'm moving to open source, I'm trying to come up with an alternative.

That said I'm trying the following approach. I've created a VB.Net COM class that accepts a class name. It then instantiates the class on a seperate thread and returns the object reference via an event. This appears to work just fine but the problem then became, VB6 doesn't allow control arrays with events and given you want to control say 48 lines, you do not want to have 48 individual controls, but rather a control array.... read more

I've uploaded everything but the IVR Client dll project, and the IVR Server application. I should be able to do that by end of week. Following that I'll being to post the documentation I have to date and explain more about the architecture and how call flows and projects are stored within the access database.

One of the issues I have is that I made seperate versions of the TAPI and Wave/Tone Rec controls long ago. One set was used within the IVR app and the other set was used more generically given I was trying to sell stuff. Now I need to migrate back to a single version which is where some time is being spent. I still need to migrate the phonebazooka.com website to reflect these changes. If you download stuff from their, they do NOT have the project source and normalized controls there yet. The intent is to also make the source available there, and to migrate the examples of how to use the tapi control and wave controls to here as well.... read more

I've uploaded the TAPI, Wave/Tone Recognition, and Timer projects. Next will be the IVR client project which consumes the aforementioned. Post that I'll upload the IVR server app which spawns one to many IVR client apps to serve each phone line.

Unfortunately I didn't get at far as I had hoped this weekend. I'll upload the client hopefully by Wednesday.

Wayne

4/6/2006 - I'll be removing the copy protection and moving all the current source code over to SourceForge this weekend (4/8/2006).

A brief overview of the architecture and what will be available;

The IVR consists of a main GUI app which allows you to create call flows and assign them to projects as well as start the IVR projects to monitor phone lines (an exe), a client application which contains all the necessary functionality to support a phone line (a dll that the main app spawns one to many of), a TAPI dll that the client app consumes, and a Wave dll that the client app consumes. There are other small pieces but these are the main 'chunks'.... read more