You probably already know that you can access your ManuSoft data using standard ODBC drivers. This allows you to display your ManuSoft data in programs that support ODBC, like Crystal Reports and Excel. Another program that supports ODBC is Microsoft Access. Unfortunately, it appears that Microsoft Access' ODBC support is not quite as good as Microsoft Excel's, plus how you set up the links to your ManuSoft data in Access has changed quite a lot with each new release of Access.

Here are the steps for creating a "linked table" to your ManuSoft data in Access 2007:

1. Create a new blank Database.
2. Select the “External Data” ribbon, then in the “Import” section click on “More”, then “ODBC Database”, like so:
   
3. Select “Link to the data source by creating a linked table” and click “OK”.
4. In the “Select Data Source” dialog that opens, select the “Machine Data Source” tab, find and select “ManusoftDBF” in the list, then click “OK”.
5. Select the table(s) you want to link to. Use Ctrl-Click to select/deselect more than one entry, then click on “OK” to continue:
   
6. For each table to selected you’ll now be prompted to “Select Unique Record Identifier”. This is essentially asking you to select which field(s) make up the Primary Key for the table. This information can be found in Section 4 of the reference manual. For example, in the case of the Material database, the Primary Key is made up of the “partcode”, “reserved” and “item” fields, so I select all three of them (no need to hold down the Ctrl key this time) then click OK:
   
7. If the Database Navigator is turned on you should now see some new entries for the tables you have linked, each with a “globe and arrow” icon, like so:
   
8. Double-click on any of the entries to open the table and you should see some data, like so:
   
    

It *should* be as simple as that! What sorts of problems are there or might you face? 

• Amount fields will sometimes be rounded to 2 decimal places, even if you use more than 2 in ManuSoft.
• Other number fields may not support number as big or as small as in ManuSoft. This will display some sort of error message in their fields inside Access.
• $NAME or other funny error messages may be a result of a dodgy DBF file header. Do a Condense of the table in ManuSoft, then delete the linked table and add it again using the steps above.
• Note: If you hover your mouse over a linked table in the Navigator pane a tool tip appears showing the ODBC Link information. Part of this information is the path to the DBF files. Thus, if you copy the Access database onto another computer which does not have the DBF files in the same location, then the links will no longer work.

In recent years Microsoft has tried to shed its image as producing "insecure" operating systems. Virii and trojans can be attached to many different file types and attack your computer in various ways, but the rise of the Internet has provided many new methods, so Microsoft has made quite a few changes in this area. But as you might expect, part of the process of making Windows "more secure by default" also breaks some existing systems and software. One example of this is the Microsoft Help system.

A number of years ago Microsoft changed the format of the standard "Help File" from the .HLP format to the newer .CHM format, where CHM is short for "Compiled HTML". Being a form of HTML, each of the "pages" in a CHM help file are displayed using Microsoft's Internet Explorer software, just in a special way so it doesn't look like that's how it's being done. Microsoft no doubt felt there were lots of good reasons for them to now do things this way, but one of the (hopefully) unforseen problems was that all the "security risks" that come with browsing the web could now also be applied to .CHM files. That is to say, while it is not very likely, somebody could craft a special .CHM file that could do damage or pose a security risk to your computer, and all they'd need to do is get you to download the file and view it.

So, sometime after the .CHM file format was in general use, Microsoft tightened up the security in Internet Explorer, but because the new Help Viewer application uses IE to do its displays, changes to IE affected how the Help Viewer functioned. It was now possible that you would try to view a help entry in your software and rather than seeing the text you were supposed to see, you'd see some sort of security message or other error instead, basically telling you that the help file was not properly accessible. Because ManuSoft is typically installed on your server and not on your actual PC it is more likely that you'll see an error message accessing our help files because Windows will decide (incorrectly in this case) that a file on your server is somehow inherently more insecure than a file on your local hard drive. And that's just one possible scenario where things go wrong.

So, if you're having trouble viewing the online help in ManuSoft, what can you do? Below are a few steps to try:

1. The file could be "blocked" because you downloaded it from the internet. Locate the .CHM file on your hard drive, right click it and select Properties. At the bottom of the dialog there may be an option to "Unblock" the file. If so, select it then try reading help again. Note that ManuSoft has 3 help files, named Manual.chm, Tutorials.chm and Seminars.chm and you may need to check all three.
2. Download the "Fixhelp" registry file from the Miscellanous Files section of the ManuSoft Support Web Site, extract the file, then double-click it to merge it with your System Registry. Try opening the help again. This fix works by adjusting the "zones" from which the HTML Help application will allow content to be displayed. See http://support.microsoft.com/kb/892675 for more information (specifically Example 2, and in this case we raise the MaxAllowedZone to 1.) 
3. Another possibility is that the PC has somehow got confused about what is part of the “INTRAnet”, and what is part of the “INTERnet”. If it thinks your local server is part of the “INTERnet”, then it places higher security on it, and that can stop Help (and other things) from working. For example, this typically means that every time you launch ManuSoft you also get a warning confirmation prompt before the program is actually started. To check for this, open a Widows Explorer Menu and select a network drive like M: or N:. Down in the bottom-right hand corner it will say either “Internet” or “Local Intranet”. (If you’re not getting a bottom status bar at all, click on the “View” menu, then select “Status bar” to tick it.) Seeing “Local intranet” is good, seeing “Internet” is bad. If it says “Internet” we need to go into "Control Panel", then "Internet Options", then go to the "Security" tab. Select “Local intranet” from the list of “zones”. This zone should already be set to “Medium-low” security, but click on “Default level” if it is not. Then click on the “Sites” button to get a further dialog box. Computers that are having a problem typically have the “Automatically detect intranet network” option ticked. Untick that option and leave the other three ticked. Click OK then OK again to close everything. If you reopen a Windows Explorer display and check a network drive again, you should see that zone has changed. And hopefully now Help will function correctly too.
4. A final posibilitiy is that the folder and/or file security on the server is set in such a way that the user has insufficient permissions to view the files. Checking and correcting these permissions can be a complicated process and describing it all is beyond the scope of this entry, so I recommend you contact your network/server support person to check these settings.

Naturally, if you are still having problems with your help files after all the above then you should contact ManuSoft Support for further help.

Using the Crystal Reports viewer ManuSoft has the ability to print out drawings on your Job Tickets. (And potentially you could add drawings or images to other documents, like Delivery Notes, or a custom Goods Received Note.) This begs the question what sorts of image file does ManuSoft/Crystal reports support, and how do I best create them to get the best print outs?

The image formats supported by Crystal are BMP, TIFF/TIF, JPEG/JPG, PNG, and WMF (Windows Metafile). Of these, JPEG is probably the worst for reproducing drawings, since its “lossy” compression techniques are meant for photos, not drawings, which results in the fine details getting all fuzzy when they are saved in JPEG format. BMP, TIFF and PNG will all give very similar output. BMP has no compression, so results in large file sizes. TIFF has compression, but there are actually many different sub-versions of TIFF and Crystal does not explicity list which it supports, so users should always test their particular graphic software to make sure the TIFFs that it produces are ones which Crystal understands. PNG has the best compression, but is also a relatively new standard, so not all software supports it.

Now, almost everybody knows that a computer image has a size measured in pixels; an image file is x pixels wide and y pixels tall. And when displayed on a computer screen it will typically be displayed at its “native” resolution, with one pixel in the image using one pixel on the screen (unless it is so large that the image is bigger than the screen, in which case it will often get automatically shrunken.) A typical screen resolution is around 75 to 100 dpi (dots per inch), so an image that is 400x600 will be very approximately 4 by 6 inches on the screen.  What about printing the image out on a printer though? Now we have a device that might be printing at anywhere from 180 to 1200 dpi. Somehow the software has to work out how big to make the image on the paper, and certainly with no further information being available, there is no correct answer to the question. The image needs to have some additional information stored with it before the software can make a sensible decision.

The problem is, a lot of image formats only care about being displayed on screen. What we need is for the image to have stored with it some information about what the DPI was when the image was taken. So, for example, I scan in a 4in x 6in drawing at 150 DPI, which results in a 600x900 pixel image. So long as the “I’m a 150dpi image” information is also stored with the file then Crystal (and other software) knows it’s a 4in x 6in image, and when it prints that image on a 600dpi laser printer it can use a 4x4 pixel block for each of the original pixels, so the image comes out at the correct size. So, what image types support this information? TIFF images have a DPI stored in their format. A JPG file may have a DPI stored in them. BMP and PNG do not store any DPI information. This usually means that I recommend TIFF as a good format to start off with.

And if you are scanning your drawings yourself, with a typical flat-bed scanner, you can be pretty sure that the TIFF file will have the correct DPI stored with it. Thus, if you have a drawing printed out on an A4 page, and you scan that A4 page in, then it should come out neatly on an A4 page when attached to the job ticket. In reality I’ve found you should scan in slightly less than the full A4 page, to allow for the non-printable margin that the printers normally allow for, plus the small header and footer that is part of the Job Ticket report. But what if you are using some sort of “Export to TIFF” function directly in your CAD software, rather than scanning in a paper document? What DPI will be stored with the file in that situation? The answer is “I don’t know”, because of course every bit of software is different. It is, unfortunately, a case of “suck it and see”.

Let's talk a bit more about what size of image you should scan. The default Job Ticket in ManuSoft has a small default image in it which is a graphic consiting of the words "Drawing Not Available - Click here to view Hyperlink." Thus if the Crystal Reports Viewer cannot interpret your image file correctly, this is what you'll see instead. If you click on the graphic then it'll try to launch the file in whatever your default viewer for that file type is. So, for example, if you attach a PDF file to a ManuSoft part, then when you display the Job Ticket on screen you'll see the "Drawing Not Available" image, but you can click on it to automatically open the PDF in your installed version of Acrobat Reader.

Anyway, the default image is quite small, but it is set to "can grow", thus when you scan a larger image then the Crystal Viewer will try to display the image at it's "natural size". There is no way to set an upper limit to this natural size, so if you attach an A3 sized graphic, then it will get spread over two (or more likely four, because of the margins) A4 pages in the print out. Unfortunately also the images cannot be automatically rotated, so if you scan in your A4 drawing in landscape mode, then when the Crystal Report puts that image on the portrait mode Job Ticket you'll find the image split over two pages as it has ended up too wide for the page. The only way to stop this "multiple page" behaviour is to create a custom MyTicketMOB.rpt report where you turn the "can grow" option off, but size the default graphic to something suitable for the images you will be using. All the image files you link to will now be stretched or shrunk to the default size you have set, so you obviously need to be fairly consistent in the scanning of your drawings in order to get a consistent output.

So, as you can see, there are a lot of factors in place that usually means you have to experiment a little to get the best results. It’s worth you having a decent image viewing program installed on your PC while doing all this, something which will give you information like the DPI setting inside the files being created. The copy of Microsoft Paint that comes with Windows XP is not enough! I recommend IrfanView (http://www.irfanview.com/) as a good bit of Freeware for viewing images of all types.

Way back at the start of this post I mentioned a final format of “Windows Metafile”, or WMF. Unlike all the other formats, WMF is a vector format, not a bitmap format. This means that WMF is a lot more like DXF or other CAD files. WMF is most commonly used by Microsoft for their clipart files, so you’ll find a heap of WMF files somewhere in your Microsoft Office program folders. Because it is a vector format this means that it can be resized to any size and still look good, instead of going “blocky”. This would obviously be great for drawing files. But as a vector format it doesn’t have a DPI setting, but there’s some sort of “default size” in there somewhere. But it is also a pretty obscure format in a way, so unless the CAD software that you use specifically supports WMF as an export format, you should probably ignore it. But if it is supported then you may want to try it out and with some small modifications to the TicketMOB.rpt report you might get some very good results.

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.