Running WinBatch 2010A & 2013C

[IJRobson]

I have been using WinBatch 2010A for years but recently purchased 2013C.  As there have been some Extender and Functional changes between the two versions I wanted to keep both Versions installed so I can support old code written in 2010A whilst I upgrade the rest of the code to work with 2013C.

By installing both into different folders and setting up shortcuts to the related version I can launch either version of the Studio and Compilers so I can build 2010A or 2013C EXEs.

The problem is the "Run" option within the Studio only works on 2013C now if I press the "Run" button on 2010A nothing happens.

Any ideas?

[Deana]

Dual installs are not recommended. There are a number of registry entries that are involved. For example the .wbt file extension is associated with the last version of WinBatch installed.

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 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.   I recommend reading the Read Me Now.txt file in the WinBatch directory for all the details of any breaking changes.

The only "breaking" changes between these versions are:

***********************************************************
***                                                                       
***                        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.   

As you can see the only truly effected functions are MousePlay and IntControl 31. Are any of your scripts dependent on these particular functions? If not you should feel fairly comfortable with installing the 2013C version, and it should not break any existing scripts.

[IJRobson]

OK, understood.

My problem is I have found that a number EXEs rebuilt with 2013C and using the newer Extender DLLs do not function the same as they do when they were built with 2010A and 2010A DLLs.  I have not been able to determine the cause as the Applications run and don't report errors but do not give the same results?  This implies that general changes to the Functions / Extenders must be the cause.  Wondering about the Unicode or related changes?

The Workaround is that if I compile the Script with 2010A and use the old DLLs I have working applications so I will continue to Compile with 2010A for now.

It just would have been nice to be able to Run Scripts from Studio 2010A instead of having to Compile the Code and run the EXE.

Thanks

[td]

OK, understood.

My problem is I have found that a number EXEs rebuilt with 2013C and using the newer Extender DLLs do not function the same as they do when they were built with 2010A and 2010A DLLs.  I have not been able to determine the cause as the Applications run and don't report errors but do not give the same results?  This implies that general changes to the Functions / Extenders must be the cause.

You didn't give any specifics so you will have to look in the fixes file to determine why a bug fix is causing some kind of different results.

Wondering about the Unicode or related changes?

Very unlikely.

The Workaround is that if I compile the Script with 2010A and use the old DLLs I have working applications so I will continue to Compile with 2010A for now.

It just would have been nice to be able to Run Scripts from Studio 2010A instead of having to Compile the Code and run the EXE.

Just another one of the many reasons virtual machines are becoming indispensable to developers and other IT types.

[td]

It just would have been nice to be able to Run Scripts from Studio 2010A instead of having to Compile the Code and run the EXE.

Forgot to mention it previously but if you mean literally the WinBatch Studio 'Run' command and not the 'Debug' command, you can change the version of WinBatch used to run your script from the old WinBatch Studio executable.  Go to the Options menu and select the 'File types' tab.  In the 'File type:' combo box select 'WIL files. Go down to the 'Run command:' edit box and add the full path to the 2010A version of the manifest launcher executable in the edit box. Click 'OK' and now your scripts will run using the old WinBatch exe.

The problem with this approach is that it will also cause the new version of WinBatch Studio to run scripts using the old manifest launcher.   Just remember to save the contents of the 'Run command:' edit box  someplace before you change it so you can switch back to the new method for running scripts from WinBatch Studio without having to reinstall WinBatch.

[IJRobson]

Thanks for the Update.

I tried this approach and it does not matter what I enter into the Run Command Windows 2010 ignores it?

I have proved this by entering invalid or rubbish entries and the Run command does nothing and reports nothing.  But running with same settings on WinBatch 2013 reports Invalid entries or executes the command entered correctly.

I did try using Debug from WinBatch 2010 and that works fine.  It also appears to be running the 2010 environment.  So I can use that run the Code.

Long term the code will be changed to 2013 and rebuilt so I am happy to continue as is.

[td]

Thanks for the Update.

I tried this approach and it does not matter what I enter into the Run Command Windows 2010 ignores it?

I have proved this by entering invalid or rubbish entries and the Run command does nothing and reports nothing.  But running with same settings on WinBatch 2013 reports Invalid entries or executes the command entered correctly.

What did you put in the Run command edit box?  I have a system with both 2010a and 2013c installed and adding "C:\Program Files (x86)\WinBatch\System\winbatch.exe" "$(FilePath)" to the edit box allowed 2010a to run scripts using the 2010a WinBatch.exe.  Of course, this means that 2013C also uses 2010a to Run scripts.

That said, I should have recommended creating a custom tool using the Debug menu's Customized Tools... menu command to create a custom tool to run scripts with the 2010a WinBatch executable.  That way you could have executed scripts using 2010a from either WinBatch Studio 2010a or 2013C without breaking WinBatch Studio 2013C's run command.

I did try using Debug from WinBatch 2010 and that works fine.  It also appears to be running the 2010 environment.  So I can use that run the Code.

Yes, the 32-bit and 64-bit debuggers do not use WinBatch.exe or WBML.exe.  The 32-bit debugger will always use the version of the interpreter it was shipped with.

Long term the code will be changed to 2013 and rebuilt so I am happy to continue as is.

Try the custom tool approach. If done correctly, you can run scripts using WinBatch 2010a from 2013C WinBatch Studio and still use WinBatch Studio 2013C's run command to execute scripts using the 2013C version of the interpreter.