ManuSoft version 6.0 was our first version of ManuSoft for Windows and was written for Windows 95 specifically. We never did a version for Windows 3.11 or earlier. As such, ManuSoft 6.x has always been a 32-bit Windows program, written in pure Microsoft Visual C++.

Through Windows 95, Windows 98, Windows 2000, Windows ME, Windows XP and now Windows Vista, ManuSoft has remained a 32-bit program, and this is fine as it's what the vast majority of users out there are using. But just recently we're starting to see a few "64-bit Windows" users out there. These are people running "Windows XP 64-Bit Edition" or "Windows Vista 64-Bit Edition", sometimes also referred to as "x64" versions of Windows.

There is some software out there where special "x64" versions are produced, specifically for running on these versions of Windows. Microsoft has versions of their Microsoft Exchange Server and Microsoft SQL Server products that are designed for 64-bit computers, and Adobe has released 64-bit versions of some of their photo and video editing software. Programs that use a lot of RAM or do computationally intensive operations typically perform better as 64-bit software, but for the vast majority of programs there is little to no benefit in converting to 64-bit. You will not find a 64-bit edition of Microsoft Word, or even Microsoft Excel.

Similarly, we have no plans to produce a 64-bit edition of ManuSoft. There is simply no benefit for the user in us doing so. It would not make ManuSoft run any faster, or be any more efficient. 

So what happens when you run 32-bit software on your 64-bit edition of Windows? The answer is that the 32-bit program is run in a special way, launched through a process called WOW64 or "Windows on Windows64". WOW64 essentially provides an emulated 32-bit environment so that the older software thinks it is still running on a 32-bit machine. Any time the software tries to talk to the 64-bit operating system the WOW64 process steps in and provides a translation service so things continue to run smoothly.

 (Incidentally, a very similar thing was done back when Windows 95 was first released. Windows 3.x was a 16-bit operating system, whereas Windows 95 was 32-bit. In order for all the older 16-bit software to continue functioning, Microsoft provided a service called WOW32, which performed in exactly the same way.)

All this happens silently and seamlessly. You'll have absolutely no idea that the WOW64 process is being used while you are running ManuSoft.

There is one small discrepancy that you must be aware of though. Because ManuSoft is 32-bit, it will only talk to 32-bit ODBC drivers. This is fine as the 32-bit ODBC drivers continue to function on 64-bit Windows. But if you go into the "ODBC Administrator" on a 64-bit edition of Windows (found by going into "Control Panel", then "Administrative Tools", then double-clicking "Data Sources (ODBC)"), then what you have in fact started is the "64-Bit ODBC Administrator".  You'll find the ManuSoftDAT and ManuSoftDBF User DSNs are listed, but if you try to configure them you'll get error messages about "The setup routines... could not be found."

Instead, you need to run the "32-Bit ODBC Administrator", which you can do by clicking "Start", then "Run", then entering "%WinDir%\SysWOW64\odbcad32.exe" as the program you wish to open. This will launch an almost identical looking program, but this time you will be able to successfully click on the "Configure" button and modify the ManuSoftDAT and ManuSoftDBF entries (should you need to.)

As most of our users are aware, ManuSoft uses Crystal Reports to produce a lot of its printed output. Whereas earlier versions of ManuSoft produced very boring looking print outs - mono-spaced slabs of numbers in Courier New, dashes used for separating lines, etc. - since version 6.2 we've been steadily improving the look of our reports by using Crystal, where we can use many and multiple fonts, draw boxes, include graphics, etc.

As well as looking better, this also gives our users an opportunity to further customise our reports in ways that were not previously possible. We've also added the "MDBC Reports" menu to allow you create your own reports from scratch (or from one of the downloadable reports from our support site) and still run them from inside ManuSoft. ManuSoft provides automatically everything you need to run and view Crystal reports.

But to create your own reports, or to modify the reports that ManuSoft have provided, you need your own copy of the Crystal Reports program (and a licence for each user that you install the program for.) Many users will already have a copy, so it's worth quickly running through the recent versions that have been released and how suitable they are for use with ManuSoft.

ManuSoft v6.2 used Crystal Reports v8.0 and then v8.5. We also used an optional feature called "Compiled Reports" in order to view the reports in ManuSoft.

With ManuSoft v6.3 we moved on to Crystal Reports v9. This was a big update by Crystal and was not "backwards compatible" with v8.5 an earlier. That is, if you created in a report in V9 of Crystal you could not open that report with v8.5 or earlier. This version of Crystal also required Windows 2000 or better to run as it now fully supported (and required) something called Unicode, which Windows ME/98/95 did not support.

When we came to release ManuSoft v6.4 Crystal Reports had moved on to version 11 (also known as "Crystal Reports XI".) We made use of some of the new features in Crystal XI in reports like the Job Ticket, in order to allow drawings to be attached automatically to the print out. But Crystal XI (and indeed Crystal v10) were both backwards compatible with v9, thus if you already had a copy of Crystal Reports v9 then you could still create reports for ManuSoft v6.4 (so long as you didn't need some of the specifically new features provided by v10 or v11.)

ManuSoft v6.5 continued to use Crystal XI as its "viewer", so there were no real changes there. But new versions of Crystal have continued to be released, so let's look at them and what they offer.

First, there was "Crystal Reports XI Release 2". This was a relatively minor update of Crystal Reports, and indeed if you install this version and go into Help then About you'll see it's also referred to as v11.5. Because it was a minor update it has in fact been made available as a free upgrade for "Release 1" owners from this location:

http://resources.businessobjects.com/support/additional_downloads/service_packs/crxir2.asp

As it explains on the link, you just need to use your same licence code you got when you bought the Crystal XI product in order to install this updated version. Warning: It's a big download, at just over 1Gb, and you'll need plenty of free hard drive space to decompress the files before installing the program too.

I think there are some great new features in "Release 2" which make it a worthwhile upgrade. Most importantly there is a "Find in Formulas" option, which is great for when you're trying to locate all the possible places in a report where you reference a particular field or formula. The formula editor has also been improved with an "auto-complete" feature, which is pretty neat.

Finally, there is the recently released Crystal Reports 2008 (also known as version 12.) This version is still backwards compatible all the way back to v9, thus if you use this version of Crystal to modify or create your reports then you'll be able to use those reports in ManuSoft v6.4 and v6.5. If you use a new feature that is specific to Crystal 2008 (and there aren't many) then it will just be ignored when the report is displayed in ManuSoft.

Any version of Crystal Reports can be a daunting prospect. It's a big and complicated (but also powerful) program. We try to regularly do introductory training courses on specifically using Crystal Reports with your ManuSoft data, and there's also a basic introduction in the online help. Otherwise there's always our telephone and email support where we'll try to help out as best we can, so long as we don't end up writing the whole report for you. A bit of Crystal support here and there is covered in your maintenance contract; writing customer specific reports are not, but we will hapilly quote you a price for designing any reports you can't create yourself. Many users like us to do the hard work of creating the inital report, but then hapilly tweak it as needs change over time.

It's always good to be able to get your ManuSoft data into other programs for further analysis or whatever. Anything that saves you tedious rekeying of data is a good thing, and is what computers are good at. A common requirement of our users is to be able to export some or all of their ManuSoft data into Excel in order to further manipulate it in some way.

The oldest way of doing this was to use the ManuSoft Report Generator to create a report with the data you wanted to export. You configured the columns, printed/exported the report to a text file, then opened that file in Excel. There, you had to go through an import wizard, confirming where the column breaks were and potentially what data type (text, number, date, etc.) each column was. Now you had your data in Excel and you could manipulate it how you chose, but when you came back a month later say, to do the same sort of thing, you had to go through the whole process again. But this method is still available today and is useful for one-off "quick and dirty" exports from ManuSoft.

Starting with ManuSoft v6.2 we created an ODBC link into ManuSoft databases. This allows you to grab information from ManuSoft from inside Excel itself, using the "Get External Data" feature with Microsoft Query. The advantage of doing things this way is that the Query is saved with the spreadsheet. This means you can reopen the spreadsheet days or months later, hit the "Refresh" option and have the latest ManuSoft data appear, without any need to rebuild things from scratch.

In v6.5 of ManuSoft we have introduced a new way which runs a middle ground between these two approaches. The first thing to consider here is the fact that now all ManuSoft reports are Crystal Reports it is possible to export them straight to an Excel file, which you can manipulate. But depending on the complexity of the report your results will vary - some reports come out looking all "neat and tidy" in Excel, other's can be a bit of a mess. The latter is true for the default report used by the Report Generator. But in v6.5 it is now possible to specify a particular Crystal Report to be used by the Report Generator, and by using this feature, and by using a particular Crystal Report, it is possible to very quickly create Excel spreadsheets straight from your ManuSoft data.

Firstly, go to the ManuSoft Support Site's Miscellaneous Files section and download the Export.rpt file and save it somewhere like your ManuSoft program folder. Next, in the ManuSoft Report Generator, create a report and on the "Other Criteria" tab set the "User Defined Report" field to "M:\Export.rpt" (where M:\ is where you saved the report). It doesn't matter whether the "Printout Style" is set to Print or Export. You can now print the report to screen using the "Printout" button. The report isn't very  much to look at (all the fields are very small, so almost all the text will appear truncated), but you can use the Crystal Report Viewer's "Export" button to save the output straight to an Excel spreadsheet. Open the saved spreadsheet in Excel and use its "Autofit" option to widen the column widths to display all your data, and you're done!

MDBC Reports are a powerful part of the ManuSoft System. They allow users to view Crystal Reports based on your ManuSoft data even if they don't have the full Crystal Reports product installed. We have many sample reports on our Support Web Site, and also run training sessions on creating Crystal Reports.

The MDBC Reports menu allows for up to 100 reports to be defined in the system. For each report you do several things: give it a name, enter the path to the report, and if any .DAT files are being used they all have to be ticked so that the program knows to copy the files into your User folder, so that the report is run using the latest data. After a while, this last part in particular can be hard to keep control of, and it's particularly tedious to change all these settings if, as part of your v6.4 or v6.5 upgrade, you change many of your reports from using the .DAT files to the .DBF files (and so they no longer need to be ticked.)

Enter another Excel Spread Sheet to the rescue! The MDBCReptSetup.xls spread sheet (you'll find it in the Miscellaneous Files section of the Support Web Site) allows you to quickly and easily see and change all the settings related to your MDBC Reports Set Up. Simply open the spread sheet (making sure you allow Macros to be enabled), click the "Load Settings" button and enter the path to your WORK.DAT file  (usually "N:\", though you may wish to initially start by working on your "C:\ManuPlay\" folder.) The spread sheet will be filled with all the entries in your MDBC Reports menu. The initial columns are fairly self explanatory, simply following the fields in the setup dialog of the MDBC Reports program. The columns with the titles rotated 90 degrees correspond to all the check boxes for the .DAT files. There are a handful which have titles in curly braces (e.g. {Unused}); these columns should be ignored and left blank. For the other columns, enter either a "1" where you do want the file to be copied down (equivalent to ticking the entry), or a "0" or blank where you do NOT want the file copied down (equivalent to leaving the option unticked.)

Once you've made the changes you need, simply click the "Save Changes" button to write the new settings back to your WORK.DAT file. Like most of these "outside the system hacks" that I've talked about, only rudimentary error checking is made of the values you enter, so take care with any changes you make, and if in doubt, make the changes inside the system itself using the standard menu. (You did make a back up of your WORK.DAT file first, didn't you?)

All the current versions of ManuSoft contain a powerful feature called the Report Generator. This routine lets you create custom reports on your data, so you can extract the information you need quickly. In today's blog post I'm going to give an example of what you can do with the Report Generator. In the example I use version 6.4 of ManuSoft. I'd also recommend trying this in a play system first, if you're new to the report generator.

The scenario: you have a particular raw material and you want to find all manufactured parts which include this raw material in its bill of materials.

If you only want to search for one material you can just select the standard report format, then click printout. In the search criteria form that pops up search for "Material" equal to and enter a stock code. The generated report should list a part code and a description on each line, corresponding to a part which uses the material code you searched for. The image below is an example of the search I mean.

Now that report is reasonably useful, but we probably want to see some details about the material being used, for example the quantity. To do so we will need to create a new report format of our own. 

To start off, open the report generator menu and select the part file. Then choose the standard report format from the drop down menu. Once the standard report is selected and appears on the screen, click the build/copy button to the right of the format selector. Give the new report a name and click ok. The image below shows this.

Now to show some details about the material we need to add a reference to the material file in our report. To do so click the "Secondary" button in the bottom left of the screen. The display in the Format Layout should now show two rows of headings. The first is from the standard report and the data under these will come from the Part file as usual. The second row is for the Material file, and allows you to select the information you wish to show about the material items. Add the following columns in this order: "Stock Code", "Units", "Price ($/U)", Quantity. If you did this correctly your report format should look like the following screen shot.

Before we print the report, click on the Primary button (in fact you have to as the print button will be "greyed out" while you edit the secondary columns). Select the material details column on the primary file and delete it. The reason for doing this is that we already have too much data and the font on the generated report will be far too small if this is the case.

Now we're ready to print. Click printout and use the same selection criteria as before. The new report should show details about how much material each part actually requires, and the associated cost per unit.

Another useful feature of this report is that if you do a wildcard search (say for all materials beginning with a specific prefix) then you can see all uses of a related set of materials quite easily, as per the sample report output seen in the image below.