|
You can set a column name via numerous different ways - starting from filling LVITEM structure and sending a message to control.
Anyway:
all those ways use something like "iSubItem" - and thats the number of column to accomodate the text. Dont have MSDN by my hands - take a look there.
Sincerely yours, Ilya Kalujny.
|
|
|
|
|
Hi!
I've done a pretty large software project (a planning system) in vs.net c++ that is very interface "intensive" developed om Windows 2000 and targeting both W2000 and WXP.
Yesterday I tested this system on Windows XP Prof. on a new mobile computer from Dell and..
...Interface stopped working! ARGGG! I tried to debug the code and found out that DoModal() and WM_TIMER seemed to worked completely different from Windows 2000. The WM_TIMER in different windows came randomly and only when I moved the mouse over different controls (!). Verified this with Spy++.
Two DoModal() couldn't be done after each other (doesn't matter where it was done in the code, it was just a question of time and not logic). When I did this, the program locked up completely and never recovered (it didn't crash or leave any exception).
Question: Why is their a difference between W2000 and WXP Prof.? Have anyone else experienced this problem?
Hans Andersson from A&O Software Design (from sweden)
|
|
|
|
|
lionelzero wrote:
Two DoModal() couldn't be done after each other (doesn't matter where it was done in the code, it was just a question of time and not logic). When I did this, the program locked up completely and never recovered (it didn't crash or leave any exception).
Was this on the same instance of the CDialog class or on two different instances?
You'll probably need to post the section of code that is troubling you, so that we can provide more clues to what is going wrong.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
This is one example of when two domodals doesn't work for me in one dialog.
// A function called from PreTranslateMessage in the main dialog of a dialog based mfc program
void CMainDlg::FunctionCalledFromPreTranslateMessage()
{
CDialogOne dlgOne;
if (m_dlgOne.DoModal() == ID_OK)
{
CDialogTwo dlgTwo;
if (m_dlgTwo.DoModal() == ID_OK)
{
// Dialog Two doesn't show, the whole program locks up on WinXP Pro but not W2000 (W2000 version tested on a standard machine 2x1.2 ghz, XP tested on a mobile Dell, just a few days old)
}
}
}
|
|
|
|
|
Are you able to debug on the XP machine. The clue will lie in what is going wrong in the DoModal call to the CDialogTwo (assuming you are not doing any major work in the constructor).
I'd step into DoModal and see if anything is failing in there.
Does this dialog use any custom controls or any of the windows common controls ?
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
Hello,
I am trying to find all files with extension ".lng" in the directory of my application's exe. This is my current code:
m_listLang.ResetContent();
CFileFind ff;
char szThis[MAX_PATH*2];
unsigned long i = 0;
CString csTmp;
BOOL chk_w = FALSE;
GetModuleFileName(NULL, szThis, MAX_PATH * 2);
for(i = strlen(szThis)-1; i > 1; i--)
{
if(szThis[i] == '\\') { szThis[i] = 0; break; }
}
strcat(szThis, "\\*.lng");
chk_w = ff.FindFile(szThis, 0);
while(chk_w == TRUE)
{
if(ff.FindNextFile())
{
m_listLang.AddString(ff.GetFileTitle());
}
else
{
chk_w = FALSE;
}
}
ff.Close();
This should find all *.lng files in the directory of the executable and add their titles (so without extension) to a CListBox.
But it's not working. It always misses one file. I tried to use the FindFile function directly (so without a FindNextFile call), but as stated in MSDN this is not allowed.
Do you have any idea what I am doing wrong?
Thanks
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
OK. As written, it will always skip the first file it finds. This is because you find the first file, enter the loop, and immediately find the next file without using the first one. Write your loop like this:
chk_w = ff.FindFile(szThis, 0);
while(chk_w == TRUE)
{
m_listLang.AddString(ff.GetFileTitle());
chk_w = ff.FindNextFile();
} Hope this helps,
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"
|
|
|
|
|
No, that doesn't work. You may not use the "output" of the FindFile function.
MSDN says:
After calling FindFile to begin the file search, call FindNextFile to retrieve subsequent files. You must call FindNextFile at least once before calling any of the following attribute member functions: [blablabla, functions like GetFileTitle] .
So i think my loop is correct
Any more ideas?
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
Have you tried it? I read the docs too, but I also looked at the source code, and can't find any reason why it wouldn't work.
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"
|
|
|
|
|
Yes, I also tried it (couldn't believe it myself too ), but it really doesn't work (ASSERTed).
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
Hmmm. Ok. I'll have a look, because it sounds like a bug to me. The output of the Win32 FindFirstFile() function can definitely be used - I use it all the time.
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"
|
|
|
|
|
Thats true. The Win32 function returns information about the first file, but CFileFind::FindFile doesn't
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
I just had a close look at the source code. For some reason they buffer the returned data so you're always one file behind what FindNextFile() returns. I always use the Win32 functions. Much easier
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"
|
|
|
|
|
O damn, I cannot read the docs
MSDN on FindNextFile:
<br />
Return<br />
Nonzero if there are more files; zero if this is the last file, and the previous call to either FindFile or FindNextFile returned nonzero. To get extended error information, call the Win32 functionGetLastError. .
So the (in my opinion stupid ) function returns 0 if it returns information about the last file. I expected it returns 0 if there is no more file.
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
Aah. So you need to do
BOOL res = ff.FindFile(_T("filespec.whatever"), 0);
while(ff.FindNextFile())
{
}
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"
|
|
|
|
|
i guess i'm to late... but heres the code
CFileFind ff;
if(ff.FindFile(sPath+"*.bup"))
{
while(ff.FindNextFile())
{
InsertItem(ff.GetFilePath(),atoi(ff.GetFileTitle()));
}
InsertItem(ff.GetFilePath(),atoi(ff.GetFileTitle()));
}
ff.Close();
|
|
|
|
|
I am working with Visual C++ 6.0 in an MFC project and I lost/deleted corrupted my resource.h file. Is there a way to have Visual C++ auto generate my Resource defines. This is my worst nightmare I had probably over 1000 defines. Thanks in Advance
I think im going to be sick (
Alex
|
|
|
|
|
|
Tom,
Thank You. I did check this site and unfortunatly for me "Resource ID organizer" is based on the resource.h. As you already know this file no longer exists within my project. Fortunatly though "Resource ID organizer" is a great IDea and I will probabaly add it to my toolkit. I still have my .rc file and I may be able to extract **_**_** and auto generate IDs, I guess I was sort of hoping that I would not have to do this. Please know that the help you gave me is greatly appreciated.
Thanks again
Cheers
Alex
|
|
|
|
|
Oops. I haven't used the product in a very long time and for some reason was thinking it worked from the .rc file. Anyway, I'm definitely glad to hear that at least I was able to point you in the direction of a useful utility. Good luck with the resource.h problem.
Cheers,
Tom Archer
Inside C#, Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
|
Dude, I think you're screwed
If it was me, I would write a little Python script to scan your RC file and extract any strings that matched the pattern IDC_[A-Z]*, IDI_[A-Z]*, etc., assign them uniqe numbers and print the results out as a list of #define's. This will probably need a bit of tweaking by hand but it will do most of the grunt work for you.
Then I would think about a backup plan...
"Sucks less" isn't progress - Kent Beck [^]
Awasu 1.1 [^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Here is a function, can you tell me the function of "RUNTIME_CLASS"
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CStudentDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CStudentView));
Thank you in advance!
|
|
|
|
|
RUNTIME_CLASS is a macro that returns the static CRuntimeClass member data for a given class which allows the function being called (the CSingleDocTemplate c'tor in this case) to validate RTCI (Run-Time Class Information).
To be more specific, the CSingleDocTemplate needs to verify that a CDocument-derived class, a CFrameWnd-derived class and a CView-derived class are all being sent. As a result, this macro is used in passing those values.
Cheers,
Tom Archer
Inside C#, Extending MFC Applications with the .NET Framework
It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson
|
|
|
|
|
|
Hi, all
When is it necessary to use critical sections in a multithread application? I have read that it should be used when “manipulating shared resources”, but what do those that really mean? Does it mean when manipulating: global variables, allocated memory chunks or files? And does “manipulating” mean: reading (probably not), writing or reallocating? Could anyone please demonstrate some code examples for typical situations when critical sections should be used?
Thanks in Advance
Aidman » over and out
We haven't inherited Earth from our parents, instead we have borrowed her from our children; an old Indian saying.
|
|
|
|