Upgrade -- convert/upgrade existing scripts?

[stevengraff]

I searched for "dialog conversion upgrade" and didn't find it, so...

When I upgrade from 2008-B, will I need to upgrade/convert my existing scripts when I want to run them from within Wil, or compile them? Or will the new version fully respect all the old commands and dialogs?

If not "necessary," is it desirable? and is there any utility for aiding with the upgrade of an old script, particularly the dialog format and statements?

[Deana]

In general, our policy is to make new versions of WinBatch as compatible as possible with older versions of WinBatch,  and to limit the occasions when we feel compelled to introduce what we term "breaking changes".

Current versions of WinBatch still support the older Dialog format 6.1. Therefore you should still be able to run your unmodified dialog code using current versions.

However if you need any functionality of the newer 6.2 formatted dialogs then you will need to update your script. The WIL Dialog Editor provides a menu option to help convert the Dialog code to 6.2, however you would need to modify any callback procedures to handle the new 6.2 dialog.

You will want to take a close look at all changes made between 2008B and 2014A, listed in the file "The list of fixes and improvements.txt". There are have only been a few breaking changes that would not be backward compatible, these changes are listed in "Read Me Now.txt".

[stevengraff]

"The list of fixes and improvements.txt"
"Read Me Now.txt".

I've glanced at http://www.winbatch.com/winbatchversions.html#WB2014A and found the word "breaking" only twice. Do I still need to check out those two files? If so, they're where? Thanks.

[Deana]

"The list of fixes and improvements.txt"
"Read Me Now.txt".

I've glanced at http://www.winbatch.com/winbatchversions.html#WB2014A and found the word "breaking" only twice. Do I still need to check out those two files? If so, they're where? Thanks.

the winbatch versions page is basically identical the "The list of fixes and improvements.txt" file that get installed with WinBatch. Both "The list of fixes and improvements.txt" and "Read me now.txt" are installed to c:\program files (x86)\WinBatch directory.

Here is the contents of interest in the current Read me now.txt file:

*****************************************************************************
*****************************************************************************
*****************************************************************************
***                                                                       ***
***                 Converting scripts to the latest version              ***
***                                                                       ***
***    In general, our policy is to make new versions of WinBatch         ***
***    as compatible as possible with older versions of WinBatch,         ***
***    and to limit the occasions when we feel compelled to               ***
***    introduce what we term "breaking changes", where we change         ***
***    WinBatch in a way that may cause perfectly functioning scripts     ***
***    to no longer work correctly with the new version of WinBatch.      ***
***                                                                       ***
***    We've attempted to make a list of these changes that might         ***
***    break currently running scripts and to give you some               ***
***    background on the issues involved so that you can successfully     ***
***    modify your scripts to run under the latest version of WinBatch.   ***
***                                                                       ***
***                                                                       ***
***                                                                       ***
*****************************************************************************
***                                                                       ***
***                        Note for 2013A version.                        ***
***                                                                       ***
***    Fixed several problems with the MousePlay function                 ***
***    incorrectly locating the mouse cursor on multi-monitor systems     ***
***    when using a window origin instead of a screen origin. Also        ***
***    fix problems that caused the function to use an invalid            ***
***    origin instead of the origin of the restored parent window         ***
***    when the parent windows was minimized and a child window           ***
***    was specified. These are breaking change that may require          ***
***    changing existing scripts that use the function.                   ***
***                                                                       ***
***    Modified the legacy WinMacro application to reflect the            ***
***    multi-monitor fix in the MousePlay function.  This may require     ***
***    rerecording macros that were record using mouse coordinates        ***
***    relative to a specific window instead of to the screen.            ***
***                                                                       ***
***                                                                       ***
*****************************************************************************
***                                                                       ***
***                        Note for 2010B version.                        ***
***                                                                       ***
***    IntControl 31 has been changed to enumerate only 64-bit Explorer   ***
***    windows on 64-bit versions of Microsoft Windows. Previously, the   ***
***    IntControl only enumerated 32-bit Explorer Windows on 64-bit       ***
***    versions of the operating system. This does not affect Windows 7   ***
***    or Windows 2008 R2 because the 64-bit versions of these operating  ***
***    systems do not display stand-alone 32-bit Explorer windows.        ***
***    However, 64-bit XP, Vista, Windows 2003, and Windows 2008 do so    ***
***    you may need to modify any scripts that rely on the IntControl to  ***
***    enumerate 32-bit Explorer windows on those systems.                ***
***                                                                       ***
***                                                                       ***
*****************************************************************************

[stevengraff]

However if you need any functionality of the newer 6.2 formatted dialogs then you will need to update your script. The WIL Dialog Editor provides a menu option to help convert the Dialog code to 6.2, however you would need to modify any callback procedures to handle the new 6.2 dialog.

The new method entails using a name rather than the control number, right? Would it still function, following the update, using the existing control numbers? Or would names need to be assigned before the scripts would work again?

[td]

The new method entails using a name rather than the control number, right? Would it still function, following the update, using the existing control numbers? Or would names need to be assigned before the scripts would work again?

It depends on what you mean by 'it'. If you mean a dialog callback procedure then yes, you would need to change the callback to use names instead of numbers.  This only applies to dialogs converted from the 6.1 to the 6.2 format.  Also, the DialogProcOption 1004/1005 can be used to get the 6.2 control names associated with a dialog control's 6.1 number and the reverse.  This may make the conversion a little easier but it is strongly recommended that you simply use the control names where you previously used control number in your callback.  Using names makes it much easier to change you dialog in the future without completely breaking the dialogs callback. The callback breaking problem is one of the main reasons the control name concept was introduced in the first place.

[JTaylor]

Your dialogs should all work immediately after updating without any changes.

The new method entails using a name rather than the control number, right? Would it still function, following the update, using the existing control numbers? Or would names need to be assigned before the scripts would work again?

[JTaylor]

When you are ready to go from 6.1 to 6.2.....With a little creative scripting you could probably convert your scripts to use names rather than numbers without a lot of manual labor.   That is what I do but I have been using WBRAD for years so that has made it fairly easy but would probably still be doable.   All depends on your scripting habits.


Jim

[stevengraff]

All depends on your scripting habits.

i.e. ill-disciplined and unprofessional? :)

[td]

In case it is not clear, you will need to change the dialog callback procedure of a converted dialog, if your dialog callback references the third parameter passed to it or references controls directly via their number. This is because that parameter is the integer control number for 6.1 dialogs but is the control name for 6.2 dialogs. This is an issue for 'switch', 'if' and 'dialog*' function statements that reference controls by their number.  The dialog will not work properly if you do not make those changes.*

*The one exception would be if you change the name of each control to it's number.  This would make the callback of the converted dialog work in most cases because WIL is a negatively typed language.  However, this approach is not recommended for hopefully obvious reasons.   

[stevengraff]

@Tony... Thanks for clarifying. I do get it now.

@Jim... what is WBRAD? Something that will help me convert my scripts?

What kind of naming convention works best?/well? Seems like using the variable name would be pretty straightforward, no?

[JTaylor]

My response, unless I'm wrong, was to clearly state that no changes needed to be made if the dialog version didn't change.   Was I wrong in that?  I don't recall having to make changes unless I switched to 6.2.

Jim

In case it is not clear, you will need to change the dialog callback procedure of a converted dialog, if your dialog callback references the third parameter passed to it or references controls directly via their number. This is because that parameter is the integer control number for 6.1 dialogs but is the control name for 6.2 dialogs. This is an issue for 'switch', 'if' and 'dialog*' function statements that reference controls by their number.  The dialog will not work properly if you do not make those changes.*

*The one exception would be if you change the name of each control to it's number.  This would make the callback of the converted dialog work in most cases because WIL is a negatively typed language.  However, this approach is not recommended for hopefully obvious reasons.   

[JTaylor]

WB_RAD is a program I distribute at no cost.   Not that it really matters but it is written in WinBatch.  It prompted what you find in the Dialog Editor for generating some similar stuff but does much more.  I realized early on that most of the time spent scripting was repetitive work so I basically wrote a program that writes my programs  :)

One thing that it does is takes a dialog and creates the Callback Structure.   You can also generate control names based on the variable names, among numerous other options for manipulating dialogs in batch form.  One of the upsides is that all of one's scripts adhere to a standard so when I needed to convert from 6.1 to 6.2 I was able to easily script the conversion in about 30 lines of code.

If interested you can find it at http://www.jtdata.com.

Jim

@Jim... what is WBRAD? Something that will help me convert my scripts?

[stevengraff]

Thanks; sounds good. Looking forward to trying it out (after I upgrade).