Winbatch versus VB - Quick Synopsis

Keywords: 	 winbatch versus vs VB Visual Basic comparison

WinBatch DLL's are not necessarily set up to be called in a straight forward manner by another program. The extenders are all DLL's in the classic definition of a DLL but all of the functions are written to a specification that allows them to be called by the WIL interpreter as an extension of the WIL language.

In order for a VB app to call them in any meaningful way it would be necessary for the VB app to be written to work like the WIL interpreter. All of the 'functions' in an extender, for the most part, are actually just a single exported function in the extender DLL that has a moderately complex set of parameters that get passed to it to determine what extender 'function' is to be called.

Now, if there was ever a totally screwy thing to do it would be to re-invent the WIL interpreter in VB just so that it could call functions from an extender.

I agree that even with the ability to use the HTML Dialog extender WinBatch falls short of VB in the GUI features arena. This is to be expected. Look at the very names of the products themselves get a good clue as to what purposes they were intended to be used for. 'VB' is for VISUAL basic, with a strong emphasis on the visual element and only a token reference to an actual programming language (basic). WinBatch, on the other hand, is a batch programming language for Windows platforms. It has sufficient GUI capabilities to perform basic interactions with the user but where it really shines is in its ability to automate (e.g. batch) various windows administration functions that are typically hidden behind a GUI admin tool.

When I need down and dirty manipulation of existing admin tools / apps or to automatically manage other windows features I use WinBatch. I even use WinBatch for some other types of applications that do not have strong GUI requirements, e.g. ODBC-extender related data manipulation apps and some socket programming.

However, when I need a sophisticated GUI interface I use Delphi or VB, depending on the types of underlying code that I need. If I am working on basic data manipulation for a database-driven app then I use VB. If I am doing sophisticated object oriented work then I use Delphi or even fall back on my C++.

I suppose that the most useful extension to WinBatch to help address the issue of calling WIL functions from other languages would be to give compiled scripts the ability to function as OLE servers or DDE servers. Then it would simply require the script developer to design a COM interface for the script.

Adding this type of feature could be very tricky. WinBatch is designed so that scripts are written to run as traditional 3GL mainline code by hiding the event driven Windows programming model from the WinBatch programmer. Adding in the ability to run as an OLE server would require some basic extensions to WIL that would either involve the use of goto/gosub labels or the actual implementation of user defined subroutines/functions in the classical sense that the subroutines/functions would have their own local scope for temporary variable storage that is independent of the caller. Regardless of the method used, the WIL interpreter would have to sit idle and then be able to dispatch incoming COM requests to the appropriate snippets of WIL code in the script to process the COM requests for method calls or property reads/writes.

Article ID:   W14356

Filename:   Winbatch versus VB - Quick Synopsis.txt

File Created: 1999:11:04:17:17:58

Last Updated: 1999:11:04:17:17:58

Database Search

TechHome

Winbatch versus VB - Quick Synopsis