C / C++ / MFC

12-Apr-05 19:30

How is it too complicated? I want to position the file pointer at a location (0x436, 1078 bytes from the beginning of the file) and then read the rest of the file, sound like quite the ordinary task (with some argument attributed to file positioning). I can't perform this task because the data it pushes onto me isn't the data I have in the file. Am I wrong in the fact that the file pointer is not working correctly? Shouldn't it keep reading the file, not skip around some and then read past the end of the file and return FF's? I don't want to read the entire bitmap file, only the data portion.

Re: Follow-Up

John R. Shaw12-Apr-05 20:43

John R. Shaw

12-Apr-05 20:43

LighthouseJ wrote:
How is it too complicated?

You've were talking about reading a structured file one byte at a time. Which impilies you need to decipher those bytes (complicated, may be need for cross platfom).

Now:

You've been talking about reading a bitmap file and you are assuming that there will be data at 1078 to be read. If the file is realy an .bmp file, then you need to read the file header to determine where the bitmap data is and (for safey) what format the data is stored in.

LighthouseJ wrote:
Am I wrong in the fact that the file pointer is not working correctly?

I would bet good money that the answer is YES!

LighthouseJ wrote:
I don't want to read the entire bitmap file, only the data portion.

The entire file is the data portion!

BUT: I assmue by 'data portion' you mean the bitmap data bytes:

1) Open file.
2) Read BITMAPFILEHEADER (header).
3) Check that it is a .bmp file type. (header.bfType == 0x4D42)
4) Seek start of header (probably beginning of file).
5) Seek offset header.bfOffBits. (data offset from beginning of header)
6) Read data.

The above will work, but the moment the bitmap type is changed, yout code will fall apart.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

Re: Follow-Up

LighthouseJ13-Apr-05 4:02

13-Apr-05 4:02

John R. Shaw wrote:
You've were talking about reading a structured file one byte at a time. Which impilies you need to decipher those bytes (complicated, may be need for cross platfom).

It's not that bad. For instance if I need to get the bitmap type, the "BM", I read in a character into a short, then shift the bits left 8-bits, then logically or that variable with the next character. When I read in an integer (4-bytes), I call the previous statement twice, and shifting by 16 bits in between the two calls. I do read in both headers and jump to that location (0x436) but every single 8-bit bitmap file always begins data at that same address so in the interest of simplifying the explanation, I just said I would always go to that byte offset.

John R. Shaw wrote:
... the moment the bitmap type is changed, yout code will fall apart.

I have conditionals in the right places to make sure the file that's read is of the right type, bit depth, size, etc....

Of course, all of this you've brought up is a non-issue because I have no problems reading the bitmap headers, only when I get to that particular location.

I looked at another reply from rateep and he pointed out the problem with a very concise on-topic response to my problem and it fixed my problems.

Ryan Binns12-Apr-05 18:25

Ryan Binns

12-Apr-05 18:25

Show us your code and we might be able to help...

Ryan

"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"

LighthouseJ12-Apr-05 19:16

12-Apr-05 19:16

Well, it's kind of spread out, but I can put the relevant parts back together. I have a class that doles out the data to the function I'm trying to use it in. It's pretty standard file pointer things and I've used file pointers exclusively in the past on countless programs.

Here's some code snips:

CBitmapFile::CBitmapFile(CString fileName) {<br />
bmpFP = fopen((LPCTSTR)fileName, "r");

Where bmpFP is a member variable in CBitmapFile.

Here's the function that I call to get data:

BYTE CBitmapFile::GetNextByte() {<br />
	BYTE data;<br />
	//fscanf(bmpFP, "%c", &data);<br />
	data = getc(bmpFP);<br />
	nBytesRead++;<br />
	nVerticalPosition++;<br />
	nCurrentPosition = ftell(bmpFP);<br />
	//CheckAlignment();<br />
	return data;<br />
}

I used fscanf, I'm trying to use file streams now but even after I include ifstream, fstream or anything else to try, the compiler still doesn't know what ifstream is even though I can hover the cursor over it and then start to use it and VS brings up that little class object list as I type.

Here's where I actually use the function. At this time I am only spitting the data back into another file for debug purposes but I'll eventually put the data into a CByteArray and then transmit it.

FILE * outFP = fopen("debug.dat", "w");<br />
for (int i=0; i<PacketSize; i++) {<br />
byte = BitmapFileReader->GetNextByte();<br />
//fputc(byte, outFP);<br />
fprintf(outFP, "%c", byte);<br />
}

PacketSize will almost always be 64. That for loop is inside a larger loop to keep going until it's created every packet. It's real simple, I can change functions to read the data, but I still get the same irregularities.

namaskaaram12-Apr-05 21:20

namaskaaram

12-Apr-05 21:20

hmmm.....i dunno if thiz will help.....tis JUST a guezz.....
u see when the command that u have given

bmpFP = fopen((LPCTSTR)fileName, "r");
FILE * outFP = fopen("debug.dat", "w");

both of openz in the text mode.....u have to specfy as.....

bmpFP = fopen((LPCTSTR)fileName, "rb");
FILE * outFP = fopen("debug.dat", "wb");

becoz when it openz in text mode certain characters are not accepted by the fopen(read the documentation relating that)for example i had done thiz encrypting code on a file,when opened in text mode and when ever it encounters the 26(ascii) value it(foperationz exit like as though end of file has reached!) stopz!basically i didnt know why....but then after a long search just by putting a "b" solved my prob!

ps:i dunno if thiz will help(might sound real stupid though,but could be the cause!)even i read filez using the basic file operationz.....itz fun though it can get hectic at timez..... D'Oh! | :doh:

cheerz..... Big Grin | :-D

"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13

LighthouseJ13-Apr-05 4:01

13-Apr-05 4:01

You're now my new best friend.

I was looking into ifstream as a replacement to file pointers and ran across an option to change to a binary mode which is what I wanted but I never got it to fly. However, you pointed out that I can do that within file pointers which is mindlessly easy and simple fix. Although the file pointer irregularities are still puzzling why it did what it did, it now doesn't do that anymore with the binary mode used. You made my day, thanks a lot.

Blake Miller13-Apr-05 7:12

Blake Miller

13-Apr-05 7:12

I think in the 'old days' a ^Z character used to signify the end of text in a text file, even if the file size was larger than that. So, when you had opened your file in 'text' mode, it read until it reached a ^Z (26) character.

serial port comm at low baud rate (50/75 /100 baud) in windows

namaskaaram13-Apr-05 19:36

namaskaaram

13-Apr-05 19:36

.....glad to be of help!well yes like mr blake has said the ascii value 26 standz for end of file for a text file.....
it is there in the documentation of fopen(hmm.....i dont remeber where exactly i read it,i guess i read that from the turbo c++ version 3....they mention that in the note....yez!in turbo c++ doucumantation)!

God Bless.....

"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13

pcm21112-Apr-05 8:40

pcm211

12-Apr-05 8:40

hi,

can any body tell me how to write code for programmin a serial port to communicate at low baud rates as we all know that
MS WINDOWS has API supporting upto 110 bauds ... nad we cannot use regular API to get speeds below 110 baud...

wat is the soln ...???
a sample code would b very useful

tx..!!

attitude is everything ... !!

CToolBar and CToolBatCtrl

odiesback12-Apr-05 8:40

odiesback

12-Apr-05 8:40

I am trying to save the status of my toolbars in
the OnDestroy() funtion and restore it later.

I used first the toolbar SaveBarState("MyToolBar") but it didnt work
the way I was explained to.
Now I am trying to use a CToolBarCtrl object.

I made this call which made my app crash on destroy:

m_wndColorBar.GetToolBarCtrl().SaveState(HKEY_CURRENT_USER, "CustomApp", "ToolBarPos");

how to do it? D'Oh! | :doh:

Thanks,

Odie

Re: CToolBar and CToolBatCtrl

Jack Puppy12-Apr-05 12:50

Jack Puppy

12-Apr-05 12:50

HOWTO: How to Save and Restore State of Dockable Toolbars

Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!

Re: CToolBar and CToolBatCtrl

odiesback13-Apr-05 4:33

odiesback

13-Apr-05 4:33

Thank you.
But I got one more questions that I could not figure out yet:

Do I have to have a SaveBarState funcion for each menu?

the online help tells me:
"Name of a section in the initialization file or a key in the Windows registry where state information is stored."

which name do I use as the argument to link to the right toolbar?

Adding a file to Windows MRU

yarp12-Apr-05 8:36

yarp

12-Apr-05 8:36

I think I've seen a SDK function that does this : adding a file path to the Windows/Explorer recently opened documents list.
At the beginning I thought I would find the answer quickly - it was in the morning - please, can someone give me the name of that function ?
Thanks,

Yarp
http://www.senosoft.com/

Gary Kirkham12-Apr-05 8:38

Gary Kirkham

12-Apr-05 8:38

Have a look at SHAddToRecentDocs[^]

Gary Kirkham

Forever Forgiven and Alive in the Spirit

He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot

Me blog, You read

yarp12-Apr-05 9:00

yarp

12-Apr-05 9:00

I'm a complete idiot. I scaned the internet, the Add*, Update* Set* SDK functions and forgot to check the SH* ones.
Thanks a lot for the info,

Yarp
http://www.senosoft.com/

Bob Stanneveld12-Apr-05 22:41

Bob Stanneveld

12-Apr-05 22:41

Hello,

Take a look at this[^]. It works fine for me.

But note when you use the code in the article that you do not need to override the CWinApp::OpenDocumentFile() function. I didn't and it still works. In technical note 22[^] it is said that it's better to leave that function alone.

Hope that this is what you are looking for.

I also got the blogging virus..[^]