CompuServe Thread

#Writing to file fails

5 messages in this thread
#124892From: Ken Mascaro, Xing TSep 21, 1994 2:15 PM
I am developing an IPAS and cannot get file "write" to work when the "write" instruction is in a subroutine called by the IPAS module. This is what I did: Took the VBLUR sample, and stripped it then added my own stuff to simply transfer inpix scans to outpix scans, and also wrote each scan to a separately allocated memory DIB. After processing the final scan, I opened a file in the ClientProcImage function, and passed the file handle and DIB pointer to a subroutine. The subroutine called "write" to write 54 bytes and got a return value of 54, suggesting success. Then the subroutine returned and the ClientProcImage function then "close"d the file. Result was a file of 0 bytes. If instead of calling the subroutine I do "open", "write", and "close" all in the ClientProcImage function, then the file is truly 54 bytes long when closed. SO QUESTION: If "write" returns a non-zero value when called from the subroutine, I cannot understand why the file when closed would be zero length in this case, but would have proper length when the write takes place in the same object module. By the way, the subroutine with the "write" is in a different object module.
#124901From: Jonas Ruikis [ADESK]Sep 21, 1994 2:56 PM
Hi Ken, << SO QUESTION: If "write" returns a non-zero value when called from the subroutine, …. >> Please e-mail me a zip file file containing compilable source code. This is *always* the process that Autodesk requests in order to recreate your environment with different compilers and allows us to forward the code to QA for bug tracking. jonas[adesk]
#124986From: Ken Mascaro, Xing TSep 22, 1994 1:53 AM
I found the "cause" and it is not related to 3DS but rather to the Metaware compiler. I will take this up with them.
#125037From: Jonas Ruikis [ADESK]Sep 22, 1994 10:09 AM
Hi Ken, << found the cause.. >> Do you want to post a source code example with the problem, compiler version, etc so that others don't get caught by this? jonas[adesk]
#125667From: Ken Mascaro, Xing TSep 26, 1994 3:42 PM
No. The problem and solution are too "queer" for me to understand yet. Essentially, it was related to a huge vs far pointer issue, except the pointer at issue was not even referenced in the line of code which failed, but was located earlier in the same source module. I would have expected a pointer cast problem to give a memory portection fault at the point of referencting the pointer. Rather, about 50 lines later in the code I got a file write failure with no failure reported. I am just not in a position to further evaluate it.