fopen(..) returns wrong value, why? 3

[szcygan]

I can't figure it out, and am out of ideas what to do. If my program uses the default FileName before Execute() of OpenDialog everything works fine, but if it doesn't then fopen returns a value slightly different from the right one.. code looks like this:

Unit.h

..
char *plI, *plQ;
char strI[512], strQ[512];
..

Unit.cpp

FILE *plikI=NULL, *plikQ=NULL;
plikI=fopen(plI,"rb"
plikQ=fopen(plQ,"rb"
fread(&daneI[0],sizeof(short int),rozmI/sizeof(short int),plikI);
fread(&daneQ[0],sizeof(short int),rozmQ/sizeof(short int),plikQ); fclose(plikI);
fclose(plikQ);

There might be something not right here, I'm just a beginer. If someone could help me, I'd be very grateful

 

[cyprus106]

What kind of different value does it show you? Cyprus

 

[szcygan]

fopen(..) should return a pointer to the opened stream or NULL, in this case if it does it right gives me values
plikI=:324BEC74,
plikQ=:324BEC8C

and it works fine, but if the OpenDialog is opened first then it gives me
plikI=:324BEC5C,
plikQ=:324BEC74

I don't understand that. I would be very grateful for any help.

Thanks

Cygan

 

[hennep]

Do you use the same dialog to assign values to pli and plq ?
These two variables are pointers.

either give each variable its own opendialog or:

char plI[256], plQ[256];
strcpy( plI, dialog->FileName.c_str() );

 

[szcygan]

Thanks for the answer.

I use two different OpenDialogs for those two files, and I did exactly as you proposed, still if I open dialogs first fopen gives me wrong values. plI and plQ are the same (as far as I can see) in both cases. What can be wrong??

Whole thing looks like this:

Unit.h

..
char plI[256], plQ[256];
..

Unit.cpp

strcpy(plI,IOpen->FileName.c_str());
strcpy(plQ,QOpen->FileName.c_str());
...
FILE *plikI=NULL, *plikQ=NULL;
plikI=fopen(plI,"rb"
plikQ=fopen(plQ,"rb"
fread(&daneI[0],sizeof(short int),rozmI/sizeof(short int),plikI);
fread(&daneQ[0],sizeof(short int),rozmQ/sizeof(short int),plikQ);
fclose(plikI);
fclose(plikQ);

Cygan

 

[hennep]

try to add these lines just before: plikI=fopen(plI,"rb"

Application->MessageBoxA( plI, "plI", 0 );
Application->MessageBoxA( plQ, "plQ", 0 );

and see if the filenames are right.

 

[szcygan]

filenames and paths are ok, anyway if they wouldn't exist, or would be wrong, then fopen(..) should return NULL, I guess.

 

[Totte]

fread(&daneI[0],sizeof(short int),rozmI/sizeof(short int),plikI);
fread(&daneQ[0],sizeof(short int),rozmQ/sizeof(short int),plikQ);....
So You read rozmI/sizeof(short int) values into Your array daneI[]....and worries about a pointer to the file block....that makes no sense! The values are returned from the operating system and the ONLY you shall do with their value is to check if the files was opened and of course to access the datas with.

Firstly i would change the lines a little to:
fread(&daneI[0],sizeof(daneI[0]),rozmI/sizeof(daneI[0]),plikI);
fread(&daneQ[0],sizeof(daneQ[0]),rozmQ/sizeof(daneQ[0]),plikQ);
Does the expected values come into the arrays??? THAT'S the main issue! Totte

 

[butthead]

does the program work on the correct files. when you say the program works fine are you referring to the addresses being correct or what you expect. These are addresses in memory and what you do before or after in memory will probably effect the memory locations of the rest. I am not Quite sure why you are checking the value of the the addresses. I would worry about if the program does what I want it to, to the proper file. Leave the memory addresses to the OS programmers and your compiler.

 

[szcygan]

I see, I've started quite a discusion here.

Still my problem isn't solved.

Totte: The change you've proposed will work, but it will be almost the same, because the "dane" array is of the short type. I guess your way is better, but it won't solve my problem. I wouldn't worry about pointers... if they were right.

butthead: My program works fine or doesn't work on the same files depending what it did before. If the first thing is to call OpenDialog - it doesn't work, if I run it first on default FileName it works, and after that I can open whatever file I wish. I guess you're right about the memory location changes, in this case I won't be able to fix it. I'll have to leave it to OS programmers, to bad my programm won't work correctly... but there are no programs without a bug.

Thanks

Cygan

 

[szcygan]

Ok, but what can happen to memory locations between fopen() and fread() here:

plikI=fopen(plI,"rb"
plikQ=fopen(plQ,"rb"
fread(daneI,sizeof(daneI[0]),rozmI/sizeof(daneI[0]),plikI);
fread(daneQ,sizeof(daneQ[0]),rozmQ/sizeof(daneQ[0]),plikQ);
fclose(plikI);
fclose(plikQ);

The paths plI and plQ are the same when it works and when it doesn't. The only difference in those cases is value of FILE *plikI and *plikQ... WHYYYY???

Cygan

 

[butthead]

first of do some error checking
set some flags that are set only if file != NULL.

bool go1 = false;
bool go2 = false;

if ( (file = fopen(Logfile, "r&quot) == NULL )
Application->MessageBox("File Error", "Error", MB_OK);
else
go1 = true;

if ( (file = fopen(Logfile, "r&quot) == NULL )
Application->MessageBox("File Error", "Error", MB_OK);
else
go2 = true;

if ((go1 == true) && (go2 == true))
{
fread(daneI,sizeof(daneI[0]),rozmI/sizeof(daneI[0]),plikI);
fread(daneQ,sizeof(daneQ[0]),rozmQ/sizeof(daneQ[0]),plikQ);

fclose(plikI);
fclose(plikQ);
}

Im glad you got rid of the Address of operators. ->(&)

try displaying the results of each fread in a message box.

or adding it to a temp memo object. this may help you get a grasp of what actually is going on.

error checking can become cumbersome but somtimes you need it to figure out what is happening.

good luck;

ps - I have spent as much as 3 months trying to figure something out. sometimes you drop it for a while and then pick it up a week or two later and it becomes clear.

 

[Totte]

I know that the changes i purposed would give nill change but by using that approach You will only have to change the property at one single location in the future, should it be nessecary: the buffer declaration! It was meant as a general rule of thumb.
I can only agree with the others: Check if both of the files are REALLY opened, check that the expected number of bytes were REALLY read and THEN You can start look on addresses if it STILL goes wrong.
General fault-finding FIRST rule, applicable to software as well as hardware: FIRST assure that the unit/function has possibility of working (i.e. is it plugged in, can it access the files, is all inputs existing in the correct form?) Totte

 

[szcygan]

Thanks to you guys, I've learned really a lot...

I've done the error checking, and what turned out - the error is somewhere else. Here everything works fine.

What a shame... So much time and work without a reason. But not without a result, I've learned quite a lot thanks to you. Next time I'll won't make such a mistake.

One more time thanks - Totte, butthead and hennep.

Cygan