WinBatch® Technical Support Forum

All Things WinBatch => Beta => Topic started by: td on November 28, 2018, 10:33:11 AM

Title: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 28, 2018, 10:33:11 AM

We have released WinBatch+Compiler 2018c beta.

Customers with a current license may download the beta version of the software from the download page.  Find beta software in the Alternatives
download list.

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

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

https://commerce.winbatch.com (https://commerce.winbatch.com)

Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 28, 2018, 10:33:31 AM
 WB 2018C Nov 28, 2018 (beta)

  DLL 6.18crc First showing up in WB 2018C

  Removed the length limit on the Environment function's environment variable value maximum
  return size. 
 
  Fixed minor memory leak in Compiler's Syntax Analyzer module.

  Fixed problem with foreach loop implementation that prevented the successful interation of
  variant safearrays under certain conditions.

  Increased the default font size of WinBatch box text on systems with main display scaling of
  150% or more.

  Changed the font typeface of WinBatch built-in dialogs and for the default WinBatch box
  fonts.

  Modified the "Dialog" function to support the new "<dlg-variable>DPI" line in WIL dialog
  templates. When this line is present, the function adjusts the size of the dialog, contained
  controls, and control fonts to the display scaling of the main display of the system calling
  the function.
                                                                                       
  Added map collection support.  Map collections are key-value pairs.  Each value stored in the
  maps is referenced using a string key  enclosed in array style square brackets. However,
  instead of integer subscripts, map elements are accessed using sting keys. Maps cannot be
  passed to WIL array functions. The one exception is the "ArrInfo" function which can be used
  to discover whether or not a variable is a map and the number of key-value pairs in a map. A
  map variable can be created dynamically using the assignment operator or by using the
  "MapCreate" function. To create a map dynamically use array-style syntax:
  <map>[<"key">]=<some value>.  Where <map> is any allowed variable name and <"key"> is a string
  literal or variable containing a text string.  Note that when creating a map dynamically the
  first assignment must use a key that does not convert to an integer.  If a value that converts
  to an integer is used, the interpreter creates a regular WIL array instead of a WIL map.
  Numbers can be used as keys subsequent assignments to the map. <Some value> can be any value
  permited when assigning an element to a regular WIL array.
 
  New Map Functions:
    MapCreate([s:keys-values{kk, s:kv-delimiter[, s:pr-delimiter]]])
    Returns a map that is optionally initialized with the supplied key value pairs.
      keys-values  - (optional) delimtied list of one or more key-value pairs. Use an empty
                     string to create a map without and key-value pairs.  Leading and trailing
                     key or value whitespace is ignored.  Use a double-quoted(") key or value to
                     preserve leading and/or trailing whitespace or to include a delimiter in a
                     key or value. To include a double quotes as part of a key or value use two
                     double quotes inside a double quoted key or value.
      kv-delimiter - (optional) character delimiter between each key an its value. Defaults to
                     comma(,) when an empty string is used or when the parameter is omitted
                     completely.
      pr-delimiter - (optional) character delimiter between each key-value pair. Defaults to a
                     tab character(@tab) when an empty string is used or when the parameter is
                     omitted completely.

    MapKeyExists(m:map, s:key)
    Returns @true if the key exists in the map and @false if it does not.
      map - a map previously created either using dynamic allocation (map["key"]=value) or using
            the "MapCreate" function.
      key - a string value to test for presents as a key in the map.
   
    MapKeyRemove(m:map, s:key)
    Returns @true if the key and associated value are found and removed from the map and @false
    if the key is not found in the map.
      map - a map previously created either using dynamic allocation (map["key"]=value) or using
            the "MapCreate" function.
      key - a string value representing the key of a key-value pair to remove from the map.
   
    MapFileGetCsv(s:file-name [, s:delimiter])
    Returns a map created from the contents of the first two fields of a Comma Separated Value
    (CSV) file.  The first field of each row in the file becomes a map key and the second field
    of each row becomes the value for that key. So each row in the file becomes a key/value pair
    in the map. If the file contains single field rows, the function creates a map with each key
    having an undefined value.  If the file contains rows of more than two fields, only the
    first two fields are used and the remaining fields are ignored.
      file-name - path and name of a CSV file.
      delimiter - [optional] single character used to separate values of each row of the file.
                  If omitted a comma(,) is used.  The space, double quote, carriage return, and
                  line feed characters cannot be used as a delimiter.

    MapFilePutCsv(s:file-name, m:map [, s:delimiter [, write-undef [,flags]]])
    Returns the number of bytes written to the Comma Separated Value (CSV) file.
      file-name   - path and name of a CSV file to be created or overwritten.
      map         - map collection to write to file in CSV format.
      delimiter   - [optional] single character used to separate values of each row of the file.
                    If omitted a comma(,) is used.  The space, double quote, carriage return, and
                    line feed characters cannot be used as a delimiter.
      write-undef - [optional] set to @True to write keys with undefined values to the file. The
                    default behavior is pairs with undefined values are not
                    written to file.
      flags       - [optional] set to 2 to indicate that double quotes should not be used with
                    each key and value in the map written to file. By default each key and each
                    value is surrounded by double quotes.

  Added support for both WIL maps and WIL arrays to the "Foreach" statement.  When using a WIL
  map as the collection following the "in" clause, the statements element variable contains one
  key from the map's key-value pairs on each iteration.  When the collection represents a
  regular WIL array, the element variable contains an array element value on each iteration of
  the loop structure.

  Added two new requests to the ArrInfo function. 
   Request             Function Return Value
     -2     returns @TRUE of passed in array is COM safe array; otherwise, @FALSE.
     -3     returns @TRUE of passed in array is a map; otherwise, @FALSE.
 
  WinBatch Studio:
    Fixed problem in a WinBatch Studio that caused user-defined tool toolbar buttons to be
    removed from toolbars even when not required by the installation of a new version of
    WinBatch Studio.

    Added a new "Extra Large Buttons" option to the "Toolbars" property page of the "Customize"
    property sheet displayed when the "Toolbars..." menu item of the "View" menu is selected.
    Check this option to have WinBatch Studio display toolbar buttons that are approximately
    twice the size of "Large Buttons" toolbar buttons.

    Modified the "Project Tree" window, "Workspace Manager" dialog, "Array View" window, "Binary
    Buffer View" window, "Variable" window, "Find" window, and "Debug Parameters" dialog so that
    they are now display scaling aware on systems with main display scaling of 150% or more.

    Changed "Tabbed View" tabs to adjust both their size and font on systems with main display
    scaling of 150% or more.


    Add support for viewing WIL map variable contents by double-clicking the variable's Type or
    Value column in WinBatch Studio's Watch window.
   
  WIL Dialog Editor:
    Corrected problem with the rendering of the tracking rectangle around the entire dialog
    when the Dialog Editor's view window was scrolled.

    Changed display of toolbars and "Menu Editor" arrow buttons so that sizes are adjusted when
    the editor is started on a system with a main display scaling of 150% or more.

    Added a new "Allow dialog to automatically adjust sizes" attribute to the
    "Position and Size" tab of the "Dialog Attributes" dialog.  Selecting this option causes the
    dialog editor to add a "<dlg-variable>DPI = `<DPI>,<Base Units X>,<Base Units Y>`" line to
    the current dialog's template.  When this line is present in a dialog template, the "Dialog"
    function adjusts the size of the dialog, contained controls, and control fonts to the
    display scaling of the main display of any system that calls the "Dialog" function on the
    template.
    The new template line placeholders have the following meanings:
    <dlg-variable>  - template variable name prefix as passed to the "Dialog" function
    <DPI>           - number representing the dots-per-inch in effect when the template was
                      created or modified.
    <Base Units X>  - number representing the horizontal dialog base units used when the
                      template was created or modified.
    <Base Units Y>  - number representing the vertical dialog base units used when the template
                               was created or modified.
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: JTaylor on November 28, 2018, 03:01:27 PM
What would be a good use case for the new Map Collections feature?   Having trouble thinking of one but sure I am missing the obvious because there is this little voice that keeps telling me it will be very useful but it won't tell me why :-) 

Jim
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 28, 2018, 05:42:36 PM
When it comes to uses case analysis of WinBatch features we usually don't bother because users mostly end up using it for stuff we never thought of.  I know I will use it for parsing related tasks, source code complexity analysis and probably stuff I haven't thought of yet.

Most (maybe even almost all) interpreted and compiled languages have some implementation of associative arrays.  Associative arrays are commonly used in javascript, java, PHP, and C++ to name just a few.   In fact, all arrays are associative arrays in PHP.
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: JTaylor on November 28, 2018, 08:42:22 PM
So what would be a good example of a parsing related task for which it would be used?

Jim
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 28, 2018, 10:28:05 PM
You can use a map as the centerpiece of a tokenizer.   Each key would be a token's text and each value a token type in a parser state machine. 

Note that the same thing can be done with regular WIL arrays but for simple cases, WIL map syntax is cleaner and possibly faster.
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: PercivalOgg on November 29, 2018, 05:13:49 AM
I can think of several uses for a map right off the top of my head, such as reading a single record from a dataset and applying the field names / values as the map.  I am currently using the Scripting.Dictionary for this kind of thing - can we create maps and store them in an array? I am asking as again I use the Scripting.Dictionary for this kind of thing and I can store dictionaries in an array making for a handy way of accessing multiple records and the elements in each record by the field name.

I like the mget and mput as well - for instance I have a program that saves a student id number and the number of credit hours they currently have for match back later to see if hours changes have occurred for financial aid. I can save the id/hours in one step and read them in again later in one step.

Thanks for an excellent update!

KDB
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 29, 2018, 07:38:54 AM
You bring up a relevant point.  In a sense, WinBatch has always had associative arrays because of "scripting.dictionary".  That fact is one of the reasons it was not implemented natively in the WIL interpreter before now even though it has been on the to-do list for many years.  On the other hand, making associative arrays native with WIL maps permits expanding the functionality and tweaking performance, as well as, increasing availability because of simpler syntax.
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: JTaylor on November 29, 2018, 07:56:35 AM
Thanks.

Jim
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: kdmoyers on November 29, 2018, 11:39:18 AM
Quote from: JTaylor on November 28, 2018, 08:42:22 PM
So what would be a good example of a parsing related task for which it would be used?
Maybe Storing command line parameters and their arguments.

I think this is the best thing since sliced bread, or named dialog elements, which ever came first!

-Kirby
$0.02
Title: Re: ****************** WinBatch+Comiler 2018C Beta release **********************
Post by: td on November 29, 2018, 03:05:22 PM
Out of curiosity, I ran a bench test that compared the lookup performance of a sorted regular WIL array, a "scripting.dictionary" object, and a WIL map.  The test used a large dataset of about 2000 entries and performed the lookup of 50 randomly chosen text keys.  The same 50 text keys were used to perform the lookups using each technology.   

All three approaches are very fast but the WIL map lookups were 47% faster than WIL array lookups and 14% faster than "scripting.dictionary" lookups.  Given the speed of all three methods, I doubt it makes any real world difference but thought it interesting from the curiosity perspective.