|
Thank you for finding that.
Somewhat, but the same thing happens when running a release version outside of Debug.
I am looking into the possibility that it is a bus problem caused by one of the cards in the system.
|
|
|
|
|
Jack,
Turned out to be bad hotlink receiver card. Thanks again for your help.
|
|
|
|
|
Now that was SERIOUSY cool to know. Thanks a ton 
|
|
|
|
|
What happens in your main program AFTER the while loop?
Since you only check for WAIT_OBJECT_0, if the hAcquireActive is not signaled within 100ms then your wait will return with WAIT_TIMEOUT and oyu will not enter your while loop.
Could this be your problem?
|
|
|
|
|
Blake,
Good thinking, based on the amount of code I posted. I probably should have put more of the preceding code. The way the 2 interact, the Sub code - which is the one that was hanging on the sleep - has just set the event and checked that it is indeed set. Then comes the code I posted which is waiting for it to be reset by Main. If it has been reset, then there is no need to go into the loop.
During the debugging process, I took main out of the picture - created the event in Sub - and added some other lines inside the loop to guarantee things were for sure freezing on the Sleep or WaitForSingleObject, and they were.
The problem turned out to be a bad hotlink receiver card. It was replaced and now the problem is gone. The specifics of why it manifested that way I don't know. Since it works now, move on ...
In hindsight, since it was freezing to the extent the system had to be powered down, I might have more quickly ruled out that it was a coding problem.
Thanks for your help.
|
|
|
|
|
I don't see how this got to be a problem, but I'm trying to read a bitmap file data in a raw fashion, byte by byte. I'm dealing with 8-bit images and therefore my data starts at 0x436 (1078 bytes from the beginning of the file). I'm trying to read the file in 64-byte chunks using file pointers. I've used fseek to position the data read pointer at the start of the data properly and it starts to read fine. When it gets to byte 62, that's when the problems begin. I have a variable that's set by ftell to tell me the file position which I interpret it to be the byte offset from the start of the file. Before the problem, the characters are fine and the file position is where it should be. Once it hits byte 62, the characters it gets are different from what it should be and the file position reads 5175 instead of 1141 for byte 63.
Here's 96 bytes of what I'm trying to read from:
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1D 1D 1C 1C 1B 1D 1C 1B 1B 1A 1D
1D 1B 1B 1B 1B 1B 1C 1D 1B 1C 1C 1D 1D 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
Here's the result, I've bolded the bytes that are different:
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1D 1D 1C 1C 1B 1D 1C 1B 1B 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
The 1E's at the end of the snip are probably 1E's from somewhere else, the picture I'm reading is of a very white moon on a very black background. Any help would be greatly appreciated because this is an annoying problem.
edit: I was using fgetc to get a char (cast into a BYTE), but I tried using fscanf but the behavior is still the same, quite strange.
|
|
|
|
|
I traced through the read and here's what I found...
In the file pointer structure, there is a _ptr and a _cnt variable. When I open a file, the system seems to read in a chunk into memory and position _ptr at the front of it. As I read, the _ptr advances through the memory, and _cnt counts down to stop the read at the end of the chunk. When _cnt reaches zero, that may be a signal to the system to grab more data. Upon the signal, a new chunk of data overwrites the old data in the same memory area to save space, _cnt is reset to the amount of data it read in and _ptr points back to the beginning.
That sounds reasonable to me, however the data it reads in is very incorrect after the first block. I have the same file open in a hex editor and it's fine so the data is not corrupt. In the meantime, I may (relucantly) try a different method of reading a file, like iostream instead of file pointers but this is just disappointing to me. If anyone can say "it's because of X. Add "this statement;" and it'll work like a champ, I'll buy you a pint.
|
|
|
|
|
All I've seen from this post and the original, is that you are making it too complicated.
What you are describing, of course, makes since for buffered file I/O. Since reading a sector at a time is more effiecient than reading a character at a time.
You can read all the file data into a single buffer, to simplify manipulation.
Note: If you read an entire .bmp into a buffer, eccentualy, you end up with a DIB.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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"
|
|
|
|
|
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 />
data = getc(bmpFP);<br />
nBytesRead++;<br />
nVerticalPosition++;<br />
nCurrentPosition = ftell(bmpFP);<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 />
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.
|
|
|
|
|
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.....
cheerz.....
"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
 .....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
|
|
|
|
|
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 ... !!
|
|
|
|
|
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?
Thanks,
Odie
|
|
|
|
|
|
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?
|
|
|
|
|
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/
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
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..[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!