VB6 applications

[cprichard]

I'd like to see if anyone has developed sourcecode to expose methods in a VB6 application to HAL, and successfully achieved results with giving the application commands using HAL.

I just ordered Microsoft's SDK 5.1 for speech recognition which has VB6 examples. It will be a few days before I get into it.

Part of doing it is planning the application so that an Active-X component can be made to expose methods to other applications such as HAL. A specifically HAL-enabled application would then be developed for users willing to pay the extra charge for putting HAL on their system. Microsoft is supporting development without HAL, but it seems that HAL might already possess all desired capabillities except the actual interface.

Going toward using the Microsoft SDK I'm guessing there is much to learn from the logic employed in HAL's brain.

At this stage I'm shaping my effort, doing research to get a perspective necessary for development. I have an E-mail application that will benefit from speech recognition. It would be great if users would find it more fun to chat a little with their computers in addition to using HAL to render my application useful. Developing the objects will be a template for further use of HAL.

Right now it looks like I need to study the SDK to determine what is needed to adapt HAL to giving my application commands via Active-X or OLE. It might be possible to create a driver in Windows to intercept HAL's system commands. This would require that each command given to an application contain a keyword, or be prefaced with a vebal command that tells HAL to listen for MY APPLICATION directives.

In a month I hope to have the necessary information. All help is appreciated.

-C

[cprichard]

So,, thus far I've determined that I want to have HAL open my application and PREFACE a list of keywords with contextual designations or meaning. In initializing, HAL then interrogates my application to get the protocol for each prefaced application function name. Simple command like SEND and CIPHER are easy because there is no added verbage as input or output except to indicate that the message was sent. Then HAL can parse the dialog looking for complete commands in the input buffer, checking against the structures given by the application when initialized. Hal does not presently do this.

Then HAL must send a parsed command to my application as expected input. Windows handles this.

If the source code of HAL is available or a DLL has been developed for HAL that returns TEXT, then its much like the ancient problem of putting a wedge into the Commodore 64 keyboard input routine. Except that its not DOS anymore. Its Windows receiving keyboard input to HAL, or more preferably returning TEXT that has been recognized by a speech-recognition application working with HAL.

I like to think it would be good to establish a kind of protocol that will allow HAL to interface with all HAL-enabled Windows applications. The GOOD PROTOCOL would permit all developers to use the same object in HAL to extend capabillities for passing commands to opened applications.

What is needed is a dynamic feature to permit definition of PREFACED KEYWORDS for HAL enabled applications. HAL will need to aquire the list of prefaced words (easy) and the set of expected parameters with each application COMMAND or ARGUMENT. A protocol is needed for passing the information to HAL in each instance so that HAL can dynamically acquire the set of definitions.

HAL first reads the set of prefaced words.

It then processes those words that have been prefaced as commands by inquiring to the application whether there is associated other verbage and what kind of interaction is initiated with each command. I need to categorize the possible different COMMAND exchanges and determine a pattern to see if its possible to just articulate in some manner the information in a delimited script of lines.

Studying HAL to see about DLL's and controls.

-C

[cprichard]

Ahaa,, all processing is done by the HalBrain.DLL

I have a nifty program somewhere that will give me all the external HalBrain functions. Most of them will be used in the editor.

I also have IDA disassembler to really take it appart.

The HalBrain.DLL is what parses all input. The BRAIN needs to be enhanced to allow application keywords to be created dynamically so that commands and their verbages can be passed from HAL to the application. Even to process HAL's responses to recognize them somehow as readied application input will require some special enhancements. The BRAIN EDITOR might make such a thing possible. with enough coaxing, HAL would begin to recognize COMMANDS and issue responses that are suitable as application input. This seems like a backdoor-like unscientific approach, even to HACKING a solution.

-C

[cprichard]

OK,, now I have a disassembled copy of the DLL. Not to VB source, but useable for my analysis to see what's going on in HAL's BRAIN.

Looks like he is a real criminal just bluffing us about having some kind of personality. But he is allot more interesting than some of the people I know.

Anyway, I need to get a handle on the parsing logic that is used to determine a response. Looks like parsing could be added right in the BRAIN editor to put PREFACED keywords ahead of all current parsing to see if buffer content passes as focused application input. Then add a function to implement dynamic calls to any opened application's exposed control methods.

-C

 

[cprichard]

Okay,, I just caught the flow of the BRAIN editor. IT IS POSSIBLE to parse input looking for specific phrases such as PREFACED keywords. PREFACING them is not dynamic, it is done manually to setup particular responses from HAL. Its possible to then PARSE HAL's responses to get application input and when appropriate, add further processing before passing HAL's response to the application. In taking dictation, HAL would have his BRAIN programmed (prefaced) to handle input by responding with a line for the application. The application then feeds HAL with a response that is actually used to generate HAL's response to the user who was dictating the message. He perceives what HAL is told by the application to do in completing an exchange between the user and the HAL-enabled application. Only problem here is getting something in place to parse HAL's output before making it visible or audible to the user.

The BRAIN EDITOR allows HAL to be VERY customized.

It seems there has to be a way to call a Windows API function to pass input to my application.

-C

[cprichard]

One thing to try might be to SHELL to an application without opening a window. That application would simply be capable of passing the associated command verbage along to the desired HAL-enabled application in COMMAND exchanges.

[cprichard]

I see,, looks like the HAL application uses the VBSCRIPT BRAIN as the dynamic, user-configurable aspect of the product. From VBSCRIPT there are calls to the HalBrain.DLL

I see no reason why I can't simply create my own COMMAND processing DLL that will accept input from HAL and pass COMMAND verbage to HAL-enabled applications.

It will even be possible to PREFACE keywords to help build application interfaces. When a command is issued to open an application, HAL first looks to see if a PREFACE file exists for it. If found, HAL reads the script and a number of KEYWORDS are prefaced with logic needed to build the interface.

Processing uses something like this:

CMD = HalBrain.TopicSearch(UserSentence, WorkingDir & "CMD.brn")

to illicit a response from HAL that is suited for the application to process the UserSentence content returned in COMMAND.

Then the CMD string is passed to the COMMAND.DLL which sends it to the opened HAL-enabled application. Ideally COMMAND.DLL is generic and suited for use by any developer who wants to use a HAL chatter-bot to optionally interface users to their application.

COMMAND.AUTHENTICATE(CMD) ;Validates HAL's user to the application
COMMAND.DO(CMD) ;Issues the command to the application
COMMAND.ABORT(CMD) ;Terminates processes
COMMAND.CLOSE() ;To require re-authentication.


ETC.