C / C++ / MFC

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 5:16

Why are you trying to create a GUI component in a console application?

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

IGx8919-Jul-05 5:50

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 5:50

I'm using a library (not easily modified) that does that call. If I change "STATIC" to "STATIC_" (or probably anything else), the problem disappears.

David Crow19-Jul-05 6:10

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 6:10

What exactly is it that you are trying to do? CreateWindow() is a GUI, not a console, function that creates a window. It also sends messages (something that a console application knows nothing about) to the window's procedure.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

IGx8919-Jul-05 7:03

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 7:03

I know it's not proper, but it's in a (internal) library that would be hard to modify. Because using something other than STATIC doesn't appear to cause problems, it seems like there might be a way to get it to work (a define? another header file?). I basically just want to understand why using STATIC causes problems and using anything else doesn't cause problems. I like to know the causes of problems, not just the solutions.

David Crow19-Jul-05 7:32

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 7:32

IGx89 wrote:
Because using something other than STATIC doesn't appear to cause problems...

Have you entertained the thought that "doesn't appear" might be the key phrase here? Just because you do not see a problem does not mean a problem ceases to exist.

IGx89 wrote:
I like to know the causes of problems, not just the solutions.

Unless you have not shown all of the code, you're trying to solve something that is the product of a bad design. Why are you trying, or even thinking that it's possible, to create a static window from within a console application?

Much the same result can be achieved by trying to use getch() or printf() in a GUI application. Yes it might compile/link fine, but a "crash" of some sort is emminent.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

Trollslayer19-Jul-05 6:11

Trollslayer

19-Jul-05 6:11

It sounds like the problem is to do with resource IDs.

The tigress is here Big Grin | :-D

Re: Why does creating a static window from a console app cause havok?

IGx8919-Jul-05 7:05

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 7:05

Can you elaborate on that?

Trollslayer19-Jul-05 7:35

Trollslayer

19-Jul-05 7:35

It is to do with resource ID numbers, STATIC is used to define the resource id for static labels on forms.

The tigress is here Big Grin | :-D

Re: Why does creating a static window from a console app cause havok?

David Crow19-Jul-05 7:49

Re: Why does creating a static window from a console app cause havok?

19-Jul-05 7:49

"STATIC" is the type (e.g., listbox, button, edit) of window that is to be created. It is one of many predefined system classes. In his call to CreateWindow(), 0 (the 9th parameter) was used as the control id.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

James Brown19-Jul-05 7:56

James Brown

19-Jul-05 7:56

I don't believe that resource-ids are the problem:

The control/resource-id is specified as the 10th parameter to CreateWindowEx.
The STATIC you are seeing is the name of the window-class to create a window from - in this case, a static-control - so no problem there.
Changing the text to _STATIC_ results in an invalid class-name and CreateWindowEx fails (returns NULL) so no window is created.

I think the problem with the program is that a console-program does not run a message-pump, so it cannot receive or process windows messages. So all messages destined for the STATIC control do not get processed and the program/Windows hangs indefinitely.

Solution: create separate thread to handle the GUI and create a message-pump (GetMessage/DispatchMessage) to handle GUI messages.

or better yet, use a GUI program that's what they're meant for.

James

http://www.catch22.net

Re: Why does creating a static window from a console app cause havok?

IGx8919-Jul-05 9:34

19-Jul-05 9:34

Ok, thanks! That's exactly the detailed explanation I was looking for Smile | :)

.

It's nice to know about things not to do, but it's even nicer to know exactly why not to do them.

fread crash

sfeldi19-Jul-05 4:40

19-Jul-05 4:40

Hey,

maybe someone could help with this one... and yes I did look in the archives for help but failed to find any...

so, I am trying to read a file. It gets opened OK, the size is checked OK... then I call fread for 1 byte and it blows up...

the thing is also that these files are supposed to be cached. At the beginning only the directory structure is cached and the file names/info, but not the file contents itself, until the file is actually accessed, or so it seems. The cache is disk based, and if it helps at all, it is created by PointSoft Jukebox manager. It is just a software that drives a big DVD jukebox where the data that I need is read from....

is there any method or anything that would overcome this? I have also tryed unbuffered and buffered reads...

...or maybe I am just doing something stupid that I fail to see?...

<br />
FILE* file = fopen( m_oblFileName, "rt" );<br />
<br />
if( file==NULL ) <br />
{<br />
	// handle this<br />
	// .....<br />
	return false;<br />
}<br />
<br />
DWORD dwFileSize=GetFileLength(m_oblFileName);<br />
<br />
if (dwFileSize<1)<br />
{<br />
	// hnadle this<br />
	// ......<br />
	return false;<br />
}<br />
<br />
char chTmp;<br />
if (0>=fread(&chTmp,1,1,file)){<br />
	// blabla....<br />
	return false;<br />
}<br />
else<br />
	fseek(file,0,SEEK_SET);<br />
<br />
CString strLine;<br />
while(ReadLine(strLine, file)>0)<br />
// .....<br />

the other two lame functions that I used, but dont seem to be relevant because they do not crash

<br />
long GetFileLength( LPCTSTR szFileName )<br />
{<br />
	long length=0;<br />
	int handle = _open( szFileName, _O_RDONLY );<br />
	<br />
	if( handle!=-1 ) <br />
	{<br />
		length = _filelength(handle);<br />
		_close(handle);<br />
	}<br />
	return length;<br />
}<br />
<br />
int ReadLine(CString &strLine, FILE *pFile)<br />
{<br />
	char mmm[2]={0};<br />
	CString strTemp;<br />
<br />
	while((mmm[0]!=10))<br />
	{<br />
		if (fread( mmm, 1, 1,pFile)!=1)<br />
		{<br />
			if (feof(pFile)&&(strTemp.GetLength()>0))<br />
				break;<br />
			<br />
			fclose(pFile);<br />
			return -1;<br />
		}<br />
<br />
		mmm[1]=0;<br />
		strTemp+=mmm;<br />
	}<br />
	<br />
	strLine=strTemp;<br />
	<br />
	strLine.TrimLeft("\n\t\r");<br />
	strLine.TrimRight("\n\t\r");<br />
	<br />
	glb_Log.DebugLog2(TRUE,"ReadingLine = '%s'",strLine);<br />
<br />
	return strLine.GetLength();<br />
}<br />

David Crow19-Jul-05 5:28

19-Jul-05 5:28

The first thing I would do is remove, or at least comment out, the GetFileLength() function. Mixing streams and handles is not a good idea at this point. It serves no purpose in trying to figure out why fread() is not working, and anything you can do to make the problem set smaller is only going to help you in the long run.

sfeldi wrote:
if (0>=fread(&chTmp,1,1,file)){

Even though a char is one byte, I would change this to:

fread(&chTmp, sizeof(char), 1, file);

That said, why are you not using CFile or CStdioFile? You'll save yourself a lot of time and grief by doing so.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

C^hris L^osinger19-Jul-05 6:48

19-Jul-05 6:48

DavidCrow wrote:
why are you not using CFile or CStdioFile?

don't know about the original poster, but I don't use them because i don't use MFC in every project.

Cleek | Image Toolkits | Thumbnail maker

David Crow19-Jul-05 7:17

19-Jul-05 7:17

But since he has already indicated that it is an MFC application, it only makes sense to use them. Incorrectly mixing streams and handles with MFC (which uses its own streams and handles for file I/O) is a recipe for trouble.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

C^hris L^osinger19-Jul-05 7:30

19-Jul-05 7:30

DavidCrow wrote:
But since he has already indicated that it is an MFC application, it only makes sense to use them

not really a great reason, IMO. ex. i almost always use C-style streams 1) because i'm not always using MFC and 2) because i'm more comfortable with them than i am with MFC's wrappers and 3) i simply don't like MFCs file classes. i also mix STL collections and algorithms in with MFC (std::string, even). are you prepared to say we shouldn't use std::vector since MFC has CArray ?

Cleek | Image Toolkits | Thumbnail maker

David Crow19-Jul-05 7:40

19-Jul-05 7:40

Chris Losinger wrote:
3) i simply don't like MFCs file classes.

Why? What is it that they do/don't do that C-style streams do?

Chris Losinger wrote:
are you prepared to say we shouldn't use std::vector since MFC has CArray ?

Most assuredly, if it causes problems. You are getting a bit off topic here, Chris. The OP is obviously doing something that he is none too comfortable with and has little experience using. The solution in this case is to always scale the problem down to something much smaller than the original, hence my suggestion to remove the GetFileLength() call. My other suggestion, again to simplify things, was to remove the FILE* and handle-related code and use CFile or CStdioFile instead. Those two things alone will go a long way in uncovering the problem.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

C^hris L^osinger19-Jul-05 8:03

19-Jul-05 8:03

DavidCrow wrote:
What is it that they do/don't do that C-style streams do?

MFC's things probably do a little more (auto-closing on destruction, for example) than C streams. but that's not enough to get me to give up a tool that has served me well for 15 years. i can remember to fclose a file.

DavidCrow wrote:
The OP is obviously doing something that he is none too comfortable with and has little experience using.

no argument there. but you responded with what feels a lot like a blanket statement that went beyond the OP's question.

DavidCrow wrote:
Most assuredly, if it causes problems

if.

i put his code in a console app (at least up until the part where he starts using "....") and it works fine. the problem doesn't seem to be from the mixing of streams and handles - at least it wasn't a problem for my test.

DavidCrow wrote:
My other suggestion, again to simplify things, was to remove the FILE* and handle-related code and use CFile or CStdioFile instead.

i don't really see how those classes are any simpler. especially since that code doesn't suggest to me that he's unfamiliar with C streams.

anyway...

Cleek | Image Toolkits | Thumbnail maker

David Crow19-Jul-05 8:52

19-Jul-05 8:52

Chris Losinger wrote:
but you responded with what feels a lot like a blanket statement that went beyond the OP's question.

In trying to lead him to an answer, I was making a point to remove all superfluous code. As did you, I could just as easily have typed in the code snippet, extrapolated the missing parts, and came up with an answer. However, he would not have benefited from that.

Chris Losinger wrote:
...and it works fine.

Do you suppose this has to do with your having more experience than him and that the problematic code might be that which was omitted from his post?

Chris Losinger wrote:
i don't really see how those classes are any simpler.

Simpler in the fact that he was opening the same file twice just to get its size, and retooling a function, ReadLine(), that CStdioFile already provided and was known to work.

"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown

C^hris L^osinger19-Jul-05 9:27

19-Jul-05 9:27

DavidCrow wrote:
However, he would not have benefited from that

i suppose we're using different definitions of "benefit"

Cleek | Image Toolkits | Thumbnail maker

sfeldi19-Jul-05 20:39

19-Jul-05 20:39

true, but this is an old project,other did code on this, and I am tight on time, and had not managed to rewrite all... yeah an excuse, but I am doing the rewrite on it.....

sfeldi19-Jul-05 21:09

19-Jul-05 21:09

the original poster is used to FILE* things, but indeed CStdioFile looks cleaner when using in MFC projects , and it even has a ReadLine (ReadString) which he didnt know about...

C^hris L^osinger20-Jul-05 1:11

20-Jul-05 1:11

sfeldi wrote:
and it even has a ReadLine (ReadString) which he didnt know about

did he/you know about fgets ?

Cleek | Image Toolkits | Thumbnail maker

sfeldi19-Jul-05 20:38