Fax Software

Community Forums

  • This topic is empty.
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #2597

    What you are probably experiencing is that WinFax is taking the OLD fax image (that was already sent to someone else) and sending it to the this new recipent .

    The reason why this is happening is as follows:

    1. When you tell WinFax to send an attachment, it converts your RTF file to a FXD (WinFax Send) format automatically. This process is done via the WinFax PRO printer driver in the background.
    2. The converted file is stored in your temporary attachments folder displayed in the WinFax Message Manager. (Physically, the file is in your WINFAXDATA directory) The original .RTF file is no longer used by WinFax.
    4. The file is transmitted as a fax as normal. The fax file resides in your WINFAXDATA directory (FXD format)
    3. The next time you send a file (RTF) with the same name, WinFax will look to see if it has already converted the fax. If it has, it will skip the conversion process and just send the image that is hanging around in the Temporary Attachments folder.

    Unfortunately, just because you attach a file with the same name doesn’t mean the contents of the file is actually the same! But WinFax thinks otherwise.

    Just because you delete the original RTF file doesn’t mean that fax image no longer exists.

    Does this sound like what is happening in your situation?

    Posted on 2:59 pm on Sep. 13, 2001
    Our VB6 program generates Invoices and Statements in the form of .rtf files. These files have a system generated name and are place in a temp directory. The naming algorithim has a base string and increments an interger suffix to make it unique Checking the files in the directory and looping until a unique name is created.. Files that are over 48 hours are deleted and thier name possibly reused. The problem we are seeing is that some of the attachments goto the wrong recipients. That is one attachment goes to two people. My question is how does the attachments collection handle duplicate file names? Does it reject the new attachment? What attachment index gets a** igned to that fax that was trying to add the duplicate? Is there a way to verify or view which attachment (indexes) get a** igned to which faxes. I realize our naming algorithm might be faulty and I have already changed it to take into account the attachments in the WinFaxes collection. I appreciate any insight you can provide in this matter.

    Thank you very much!


    Yes! That sounds very much like what we are experiencing. What do you recommend as a solution?
    I guess the attachment names must be unique. Does the attachment collection contain the temporary attachment name too? In which case I can use the .GetDescription method to check them and make sure the new name is not one of them.
    Thanks for the quick reply. This really sound like the problem I’m facing.

    Thanks you!


    there are a couple of possible solutions. A simple one (which I am not sure if it will work) would be to delete the ATTACH.DB file found in the WINFAXDATA directory before you start your application. The attach.db file contains all the information on attachments, and deleting this forces WinFax to generate a new (default) file without any references to the previous temporary attachments. The only problem with this method is if you plan on using the attachment database for any other reason, it will be always at the default setting…and I am not 100% sure if WinFax will allow you to delete the file while WinFax is running, so you might have to do it before you start the controller (or activate any of the SDK functions)

    another solution would be to manually clear out the contents of the attachment database by going to the Attachments folder in WinFax Message Manager.

    you can also ensure that filenames are never the same, instead of inv001.rtf or inv002.rtf, have a larger number..like inv99999999.rft which decreases the chances of duplicate filenames.

    Hope that helps you out. This is a problem that one developer had back in WinFax PRO 9.0 days (I think) that was simply fixed by doing the ATTACH.DB removal method..you might find that will work for you with WinFax PRO 10.0

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.