|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
|
Can you elaborate on that?
|
|
|
|
|
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 
|
|
|
|
|
 "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
|
|
|
|
|
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
|
|
|
|
|
Ok, thanks! That's exactly the detailed explanation I was looking for  .
It's nice to know about things not to do, but it's even nicer to know exactly why not to do them.
|
|
|
|
|
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 />
return false;<br />
}<br />
<br />
DWORD dwFileSize=GetFileLength(m_oblFileName);<br />
<br />
if (dwFileSize<1)<br />
{<br />
return false;<br />
}<br />
<br />
char chTmp;<br />
if (0>=fread(&chTmp,1,1,file)){<br />
return false;<br />
}<br />
else<br />
fseek(file,0,SEEK_SET);<br />
<br />
CString strLine;<br />
while(ReadLine(strLine, file)>0)<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 />
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
|
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.....
|
|
|
|
|
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...
|
|
|
|
|
|
Thanks David, for the tips,
this GetFileLength()was no problem at all, it did work the same with or without it, and yes, it is of no importance/help..... I did use CStdioFile as you recommended, the problem is just the same, it hangs when it tryes to read a cached file when yet no file content was cached,
<br />
CStdioFile ioFile;<br />
CFileException ex;<br />
<br />
CString strLine; <br />
<br />
glb_Log.DebugLog2(TRUE,"Opening OBL file=%s",m_oblIndFileName);<br />
if (!ioFile.Open(m_oblIndFileName,CFile::modeRead | CFile::shareDenyNone | CFile::typeText,&ex))<br />
{<br />
ex.GetErrorMessage(strMsg.GetBuffer(1024), 1024);<br />
strMsg.ReleaseBuffer();<br />
glb_Log.DebugLog2(FALSE,"Error opening IOB file %s",strMsg);<br />
return false;<br />
}<br />
<br />
glb_Log.DebugLog2(TRUE,"Start Reading File");<br />
while(TRUE==ioFile.ReadString(strLine))<br />
{<br />
glb_Log.DebugLog2(TRUE,"Annoying Log");<br />
}<br />
glb_Log.DebugLog2(TRUE,"Read Finished, OBL file=%s",m_oblFileName);
ioFile.Close();<br />
and the last comment in debug before it blows up is
07:28:33 OK: Start Reading File
so it never gets to printing "Annoying Log" when it tryes to read an uncached file, but when the file contents not just the directory structure are cached it works flawlessly...
anyway thanks....
|
|
|
|
|
As anyone heard of a problem where in Windows 2000 when drawing to an offscreen the TextOut would be clipped, but not anything else (lines, bitmaps, rectangles, circles, etc.).
My program creates a course map for dog trainers where they can place symbols, lines, and text to describe the various excercises they are doing. When they go to print the course map is always scaled to fit on one page. To do this I take the drawing surface (which may or not be larger than the screen) convert it to a DIB and use StretchDIBits to get the scaling right. The problem is that the text (and only the text) is getting clipped on the right side (from what my user is reporting is like I am clipping at the window rect, not the entire drawing area, but I am not sure she understands what I am asking). The same problem occurs when the user saves the course as a bitmap file, or places the course on the clipboard and the text is clipped in the same place for all three instances. The problem has to be in my CreateCompatibleBitmap in my rect size, but I never change it.
I have not seen this problem on any of my machines, XP, 98, and 2000. I have scrounged around town and tested on three other 2000 machines and not seen the problem. No one else as reported the problem (about 200 users and counting) I can not seem to duplicate the problem. Part of me says it is one person and not to worry, but...where's theres one. there is bound to more.
Any suggestions?
|
|
|
|
|
Try to scale the problem down to a much smaller one. Create just enough of an application that demonstrates the problem and go from there.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
