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.

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.