well to me path is whole location of a file eg. z:\windows\explorer.exe
Directory is a folder and we store files in folder. eg. windows is a folder
filename is the name of a file. eg. explorer.exe is a binary file
To access a file we must have complete file path
۞It is on our failures that we base a new and different and better success.
Alright... Remember the questions about binary files I've been asking lately? Well, thanks to you, my program worked!
I converted the program to C (not C++), no problem... I added a file header at the beginning of file, no problem... but if I try to compile the program with the Digital Mars compiler, with the -mtd option (DOS .COM file), and I make a file with that program, the file comes out 10 bytes less than the Windows version! Therefore, the programs can't open each other's files! Anyone know of a solution? Thanks!
Well... based on the error messages I get, the headers are messed up... Why isn't there a native DOS version of GCC?! (One that doesn't need a cwdpmi server or whatever it's called...)
Anyways... I'll see what I'll do. Thanks!
The C++ standard states that a long is 4 bytes and a short is 2 bytes. An int is defined by the size of the standard machine word for the architecture you're compiling for - 32 bits for Windows and 16-bits for DOS (unless you're using a 32-bit DOS extender such as DOS4GW).
Note that the size of a byte is not defined (other than to say it must be at least 8 bits), so a short may not actually be 16 bits, although I've never seen a situation where it is different.
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late"John Nichol "Point Of Impact"
I'm using DiLascia's CPictureCtrl in an MFC application, which works quite nicely. CPictureCtrl is essentially a wrapper around IPicture. Also, I use the gd library in my program. The dream of my sleepless nights would be to update the image displayed in the CPictureCtrl with text put into it through the gd functions. Hence, I'd need the picture to be stored in memory (which it is, inside the CPictureCtrl object) and then manipulate or replace it using gd. Any idea how to put those ends together?
Don't do that. If you need to construct/destruct individual objects, then a C-style array is the wrong thing to use.
If you could destruct individual members of an array, think what would happen when you later delete the array? The runtime will try to destruct the objects again.
I am having a problem with opening file for the second time. Below is the function that I wrote.
- cpHeader returns a portion of a string taken from the file
example: the file contains string "abcdefghi jklmn opqrstuvwxyz"
after some manipulations, cpHeader returns "n opqrstuvwxyz" (char*)
- cpTemp is supposedly taking in the rest of the string to process it further.
However, for the time being, it is only a dummy function, doing nothing
The problem occurs after I read a file once. Then, if I want to read another file (either it's the same or different), fileptr always returns NULL. And I received error message as "efghi jklmn opqrstuvwxyz" (not "File open error") . I can't think of any possible reason why this error occur. Or, what is the relationship between the string manipulations and the fopen operation?
It would be very great if anybody could help me with this matter. Thanks!
And I received error message as "efghi jklmn opqrstuvwxyz" (not "File open error") . I can't think of any possible reason why this error occur. Or, what is the relationship between the string manipulations and the fopen operation?
This clearly means, that cpTemp is still involved in the file operations, and you have already returned from the method and close the file pointer even before the file operations have been completed, check out the code in cpTemp, are you returning the command back to convertAdnpost() before the file operations have been completed?
Last Visit: 31-Dec-99 18:00 Last Update: 9-Aug-22 23:06