|
|
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
|
|
|
|
|
I have problem to read long strings from windows registry.
I have no problems with writing...
my code>
char m_sPiasPath[MAX_PATH];
char m_sIniPath[1024];
CRegKey cRegKey;
if(ERROR_SUCCESS!=cRegKey.Create(HKEY_CURRENT_USER,"Software\\psm",REG_NONE,REG_OPTION_NON_VOLATILE,
KEY_ALL_ACCESS,0,0 ))
{
MessageBox(0,"Can't create register key","PSM",MB_ICONWARNING);
}
else
{
if(ERROR_SUCCESS!=cRegKey.QueryValue(m_sPiasPath,"pias",&dwData))
{
// find pias.exe
CFileFind cFileFind;
if(cFileFind.FindFile("pias.exe"))
{
cFileFind.FindNextFile();
strcpy(m_sPiasPath,cFileFind.GetFilePath());
if(ERROR_SUCCESS!=RegSetValueEx((HKEY)cRegKey,"pias",0,REG_SZ,(BYTE*)((LPCTSTR)cFileFind.GetFilePath()),
cFileFind.GetFilePath().GetLength()));
}
else
MessageBox(0,"Can't find \"pias.exe\". Try run it manual.","PSM",MB_ICONWARNING);
}
// psm.ini
if(ERROR_SUCCESS!=cRegKey.QueryValue(m_sIniPath,"psm_p",&dwData))
{
if(::AfxMessageBox("Can't read path for \"psm.ini\" from windows registry.\nDo you want to select it?",
MB_ICONQUESTION|MB_YESNO)==IDYES)
{
CSelectPathDlg dlg;
dlg.DoModal();
strcpy(m_sIniPath,dlg.m_sFolder);
if(strlen(m_sIniPath))
{
if(ERROR_SUCCESS!=RegSetValueEx((HKEY)cRegKey,"psm_p",0,REG_SZ,(BYTE*)m_sIniPath,
strlen(m_sIniPath)))
{
::AfxMessageBox("Can't create registry key.",MB_ICONWARNING);
}
}
}
}
}
cRegKey.Close();
Thanks for help...
R.
|
|
|
|
|
rudoq32 wrote:
I have problem to read long strings from windows registry.
And what would that problem be? Have you single-stepped through the code, especially the call to QueryValue(), to see what is happening? Do the variables (e.g., m_sPiasPath, dwData, m_sIniPath) hold the expected values?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I get these all the time...
CONCEPT MALFUNCTION: IN/OUT Pointer means you must SET the value before calling function and it MIGHT be assigned a different value upon return.
BE aware of discussion like this in MSDN about the arguments to a function:
pdwCount
The size of the string data. Its value is initially set to the size of the szValue buffer.
You are lucky this works at all, because unless I missed something, you never set the value of dwData prior to either of your calls to QueryValue, and you SHOULD set it to something like sizeof(m_sPiasPath)
Try this instead:
dwData = sizeof(m_sPiasPath);<br />
if(ERROR_SUCCESS!=cRegKey.QueryValue(m_sPiasPath,"pias",&dwData))
and
dwData = sizeof(m_sIniPath);<br />
if(ERROR_SUCCESS!=cRegKey.QueryValue(m_sIniPath,"psm_p",&dwData))
These changes might cpmpletely fix your problem.
|
|
|
|
|
In addition to what Blake Miller said, you also need to use the pdwCount value returned, to determine the actual length of the string. The reason for this is that you can not depend on the string returned to be null terminated. Some of the query functions do not return a null terminated string and others that are supposed to do not do so on all Windows OSs. One way to work around this problem is to initialize the receive buffer (szValue) to all 0's and call the query funtion specifing a dwCount that is slightly smaller than the actual buffer size.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
