*** WinBatch 2014A Release ****

[Deana]

We have just released WinBatch, WebBatch, WinBatch+Compiler 2014A.

Customers on an active maintenance plan may download the latest version of the software from the download page.

http://www.winbatch.com/download.html

If you do not have a current maintenance plan and are interested in getting updated, please visit our software maintenance renewal page. You can easily order online.

http://renewal.winbatch.com


Thanks in advance,
Wilson WindowWare Support Team

Fixes:

WB 2014A January 15, 2014

DLL 6.14ana First showing up in WB 2014A
   
    Modified manifests for all executable files to indicate that Windows 8.1 is a supported OS.
   
    Fixed string memory leak in the ArrayLocate, ArraySearch and ArraySort functions that occurred when these functions were used on arrays
    with floating point number element values.
   
    Enabled jump lists for WinBatch Studio and WIL Dialog Editor.

    Fixed potential heap corruption problem cause by the ArrayRedim, ArrayInsert, and ArrayRemove functions when
    these functions operated on an array passed as a parameter to a user-defined function or subroutines.

    Added support for a '/silent' command line option to the 'uninstal' program.  When specified, this option causes the 'uninstal'
    program to perform an unattended uninstall of WinBatch or WinBatch+Compiler.

    Increased the maximum number of simultaneously loaded extenders from 10 to 32.  The total extender constants and functions is
    increased to 750.  Depending on the number of functions and constants defined in each loaded extender, it is still possible to
    reach the maximum number of extender functions and constants limit before the 32 extender limit is reached. Also note that
    loading a large number of extenders may degrade script performance.

    New Function:                                               
     
     ArrayItemize(a:array[,s:delimiter])
       Converts a WIL array or variant safearray into a delimited item list. Each array element is converted to its string
       representation before being added as an item to the delimited list. Any element that does not have a string
       representation or does not have any value is ignored.  This means that it is possible to have fewer items in the
       delimited list than elements in the passed in array.  It is also possible to have more items in the delimited list
       than elements in the array because an array element may contain an embedded delimiter.  The function's return value
       is the delimited list representation of the passed in array.

       'array'      array to convert.
       'delimiter'  [optional] item list delimiter (defaults to '@Tab'). Must be a single character.
         
      ArrayReverse(a:array[,i:dimension])
        Reverses the order of the elements in a WIL array or a variant safearray in place. This function is primarily intended
        for use on single dimension arrays but it also accepts multi-dimensional arrays.  When the optional dimension parameter is
        used on a multi-dimensional array the reversal process is performed on blocks of elements within the array. The elements
        within each block are not reversed relative to each other.  For example, this feature can be used to reverse the perceived
        order of the columns in a two dimension array without changing the order of the elements within each column. The function
        always returns 1.

        'array'      array to reverse.
        'dimension'  [optional] array dimension to reverse or zero(0) (defaults to 0.) Valid values are 1 to the number of
                     dimensions in the passed in array or 0 to reverse the array without regard to dimension.   
   
         
  WinBatch Studio Changes

    Added a new "Quick Help" menu item to the "Edit" menu.  The "Quick Help" menu includes two sub-menu items. 

    The first menu item "Insert parameters" inserts the parameters for function to left of the caret. This menu item takes over the
    role previously performed by the "Insert parameters" context menu item.  Like the context menu version the new menu item can be
    invoked using the F12. The new menu implementation is more responsive and reliable than the context menu version.
 
    The second menu item "Auto complete" displays a list of WIL and WinBatch functions that match a partially typed word to
    the left the insertion caret.  When a listed function name is selected and the Enter key is pressed or a function name is
    double-clicked, the partially typed work is replaced with the full function name.  This functionality can also be invoked
    using the Alt+Right Arrow key combination.

    Added a new "Display syntax sensitive quick help" option to the "File types" tab of the "Options" dialog for "WIL" files.
    When this option is checked and the mouse cursor hovers over a WIL or WinBatch function name, the editor displays a popup
    window with the function syntax and description. This option also enables the display of a window containing a function
    parameters whenever an opening parenthesis is typed immediately after a WIL or WinBatch function.

    WinBatch Studio "Find in Files" searches can now be interrupted during the file search. To halt a search relaunch the
    "Find in Files" dialog from the Search dropdown menu on the main menu bar and then clicking the "Stop Find" button or
    pressing the return key. The "Stop Find" button text will change back to "Find" once the search is halted.
   

[DAG_P6]

Excellent!

In particular, ArrayItemize (the inverse of Arrayize) has been needed for a long time. I'll be able to retire a UDF that I've never especially liked. Whenever I have debugged through the UDF, I have wondered why this inverse wasn't implemented.

[kdmoyers]

Wonder if the increased limits in this release might have some bearing on the issue of the dreaded dialog constants. 

They are sorta in a limbo because they are in a sense, predefined constants (that is, they are what they are, you can't change them) but then again they are not constants (they are not defined for you, you must put an explicit assignment statement for each one).

It's been talked about before and I guess the problem with defining them has been the number of variables that would get used up, even for people who don't want dialogs.  fair enough.

It's been suggested they could be implemented as extender constants, which apparently come from a different pool than regular variables. But again, that been a pretty limited resource too.

But maybe now with the increased limits on extender constants and functions to 750, they could be defined there?  Not sure what I'm asking. Just hoping really.

One reason the present situation is a hassle (among the many already mentioned) is the weird disconnect with the help messages.  We are of course encouraged to use the constants in our code, but the help messages don't, because you want the help examples to work even if the user has not added the 40 lines of assignments for the variables.  So you have read the help, then look up what constant they are referring to, then use the constant.  A little klunky.

Even a short little sample posted here to the forum needs to be 40 lines longer, to include the dialog constants. kinda wordy!

$0.02
Kirby

[JTaylor]

Agreed....Would be nice to drop that part of the code.

Jim

[td]

Wonder if the increased limits in this release might have some bearing on the issue of the dreaded dialog constants. 

They are sorta in a limbo because they are in a sense, predefined constants (that is, they are what they are, you can't change them) but then again they are not constants (they are not defined for you, you must put an explicit assignment statement for each one).

It's been talked about before and I guess the problem with defining them has been the number of variables that would get used up, even for people who don't want dialogs.  fair enough.

It's been suggested they could be implemented as extender constants, which apparently come from a different pool than regular variables. But again, that been a pretty limited resource too.

But maybe now with the increased limits on extender constants and functions to 750, they could be defined there?  Not sure what I'm asking. Just hoping really.

One reason the present situation is a hassle (among the many already mentioned) is the weird disconnect with the help messages.  We are of course encouraged to use the constants in our code, but the help messages don't, because you want the help examples to work even if the user has not added the 40 lines of assignments for the variables.  So you have read the help, then look up what constant they are referring to, then use the constant.  A little klunky.

Even a short little sample posted here to the forum needs to be 40 lines longer, to include the dialog constants. kinda wordy!

I can't argue with the notion that the current dialog constants are a bit 'klunky'. If fact, describing them as 'klunky' might be a bit generous. We have been kicking around a few new ideas with regard to constants and pseudo constants that are a little outside of what has been discussed on this forum and on the old web board.  No one is making any promises, but perhaps something will be done in some future release.

[ChuckC]

I can't argue with the notion that the current dialog constants are a bit 'klunky'. If fact, describing them as 'klunky' might be a bit generous. We have been kicking around a few new ideas with regard to constants and pseudo constants that are a little outside of what has been discussed on this forum and on the old web board.  No one is making any promises, but perhaps something will be done in some future release.

Uh... How about something along the lines of the C/C++ pre-compiler "#define" that allows for string & numeric constants to be defined that don't actually result in a WIL variable being created to store their constant values?

[td]

It is an interesting idea.  Do something like #defineConstants/#endconstants where multiple constants could be define with multiple constants per line to avoid some of the above mentioned clutter.  The parser does do a bit of preprocessing so that part is not completely without precedent.  The implementation would either require a form of preprocessor substitution like is now done for regular substitution or a new data type implementation for handling user defined constants in a way that does not negatively effect the existing constants or variable implementations.

[correction: change 'president' to 'precedent'  @!$%#@%.]

[....IFICantBYTE]

What about holding them all in a special Array?

[kdmoyers]

It is an interesting idea.  Do something like #defineConstants/#endconstants where multiple constants could be define with multiple constants per line to avoid some of the above mentioned clutter.

Well, I love that idea, but the clutter wasn't the worst part of the problem. 

The essential problem is that we programmers are writing assignments that are really constants defined by Wilson.  To solve this, the solution must in some way assign these constant values for us.  That way, ALL of us get the same values, all the time.  The help messages can refer to the constants, we can reference the constants in our postings, we can use the constants in our programs, all knowing that with each release of winbatch they will be correctly updated with all the newest values.

So I think it's important to somehow distribute the constants with winbatch, placed somewhere stable and easy to express, like maybe new version of the include statement

Code (winbatch) Select Expand

#wwwinclude DialogConstants
This would eliminate the clutter too -- I don't care what that file looks like inside, I'm never going to look in it.  I'm just going to use the constants it defines.

$0.02
Kirby

[JTaylor]

I like the idea having the dialog constants predefined, in whatever way, but don't throw out the idea of user defined constants...that has possibilities.

Jim

[td]

Well, I love that idea, but the clutter wasn't the worst part of the problem. 

The essential problem is that we programmers are writing assignments that are really constants defined by Wilson.  To solve this, the solution must in some way assign these constant values for us.  That way, ALL of us get the same values, all the time.  The help messages can refer to the constants, we can reference the constants in our postings, we can use the constants in our programs, all knowing that with each release of winbatch they will be correctly updated with all the newest values.

So I think it's important to somehow distribute the constants with winbatch, placed somewhere stable and easy to express, like maybe new version of the include statement

Code (winbatch) Select Expand

#wwwinclude DialogConstants
This would eliminate the clutter too -- I don't care what that file looks like inside, I'm never going to look in it.  I'm just going to use the constants it defines.

We appreciate the feedback but I believe you may be assuming to much.  As I stated a couple of posts earlier, we have been kicking around several creative methods for making WIL language constants better.  It just happened that Chuck's idea works nicely with one of the proposed internal implementations but I did not mean to imply that it was necessarily a substitute for adding new WIL language manifest constants.

If help files were the only issue, just adding the existing WinBatch Studio generated variable names to the dialog's help file sections would solve the problem.   But there is a lot more to it than that.  In some sense having to look stuff up in a help file can indicate a flaw in the IDE.  Most modern IDEs provide information about things like manifest constants without ever having to take the input focus away from the IDE editor.  This is actually the one virtue of the current dialog 'constants' setup. But you may have noticed that we have been working to add better no-help-file-help functionality to WinBatch Studio in recent releases. Expect more.

The problem of 'magic numbers' has been a thorn in the side for a long time.  Rest assured that we are well aware of the problem and are looking for ways to making it less of an issue for WinBatch users.

[kdmoyers]

The problem of 'magic numbers' has been a thorn in the side for a long time.  Rest assured that we are well aware of the problem and are looking for ways to making it less of an issue for WinBatch users.

Well, cool! That's really all I can ask for.  Thanks Tony!
-Kirby