|
If you call,
m_wndStatusBar.SetPaneInfo(0, IDS_MESSAGE, SBPS_STRETCH, len);
is program crashing?
|
|
|
|
|
T.RATHA KRISHNAN wrote: static UINT indicators[] =
{
0,// ID_SEPARATOR
IDS_MESSAGE,
ID_SHOWFPS,
};
IDS_MESSAGE is the ID of the second pane.
Do you have an entry for IDS_MESSAGE in the stringtable resource?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I think its strange that one problem persists for such a long time... 
I have some questions for you.
1. Have you used "SetIndicators" function?
>> If you are not using function, your prograam will definitely crash.
2. What is the idea behind doing these operations in a DOC class?
3. Is it possible to share the code you are using to create status bars?
thanks and regards
haribabu
|
|
|
|
|
Here is the indicators array.
static UINT indicators[] =
{
0,// ID_SEPARATOR
IDS_MESSAGE,
ID_SHOWFPS,
};
The code that is used to create status bars.
if (!m_wndStatusBar.Create(this) ||
!m_wndStatusBar.SetIndicators(indicators,
sizeof(indicators)/sizeof(UINT)))
{
TRACE0("Failed to create status bar\n");
return -1;
}
These two codes are in the same file only(MainFrm.cpp)
|
|
|
|
|
|
T.RATHA KRISHNAN wrote: Actually my requirement is to set width of the second pane only.
Do you have to use SetPaneInfo() to do this?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
ok i would like to make a console app be able to send a command to a nother console app and have it run it,
i use dev C++ for the compiler. 
|
|
|
|
|
heyhey
so, I searched everywhere and I cannot find the right answer...
I want to do a filter of my output in OpenGl. output actually means framebuffer but perhaps I have to do the operation somewhere else.
I want to subtract parts of the color, so let's say 50% red and 20% green.
I found the way of removing all the RGB parts by glColorMask(R,G,B,Alpha) but that's not exactly what I want, because it removes the whole R,G or B part!
I could use some BlendFunc I figured out but I'm not sure how to use it.
And I would need to set a certain background color for that.
I did something with that my 3d model got transparent, too, cause I need to use the alpha channel one way or the other. And I don't want that either.
Hope you got my question cause it's buggin me now for some days
zqueezy
|
|
|
|
|
Not sure exactly what you are asking, but you may want to try glPixelTransfer().
e.g.
glPixelTransferf(GL_RED_SCALE, 0.2126);
glPixelTransferf(GL_GREEN_SCALE, 0.7152);
glPixelTransferf(GL_BLUE_SCALE, 0.0722);
would convert the RGB colours to their luminance (grey scale) value.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Hi all,
Following is the problem (I provided some test code):
After runing the below sample the correct item is displayd at
the top of the list control's visible area just as I want.
The problem is that if I push the VK_DOWN or VK_UP key, the next
selected item will be the first item and not item 356 or 354 as
as you would expect from this sample.
The list will automatically scroll to the first item. However if
I click on the selected item (in this example 355) and then push
the VK_DOWN or VK_UP key it will select the correct item
(in this example 356 or 354).
This is really anoying. Could anybody please give me a hint on how
to proceed. It should be easy to solve but I just can't figur it out.
// In CMyDialog.h
CListCtrl m_cListCtrl;
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
// Remove styles
m_cListCtrl.ModifyStyle( LVS_ICON | LVS_LIST | LVS_REPORT | LVS_SMALLICON, 0 );
// Add styles
m_cListCtrl.ModifyStyle(0, LVS_REPORT | LVS_SINGLESEL | LVS_SHOWSELALWAYS );
// Add extended styles
ListView_SetExtendedListViewStyle( m_cListCtrl.m_hWnd, LVS_EX_FULLROWSELECT );
// Header
m_cListCtrl.InsertColumn( 0, "Col 1", 0, 100 );
m_cListCtrl.InsertColumn( 1, "Col 2", 0, 100 );
// Set LVITEM structure
LVITEM lvi;
lvi.mask = LVIF_TEXT;
lvi.iSubItem = 0;
// Adding items and subitems
for ( int i=0; i<900; i++ )
{
lvi.iItem = i;
lvi.pszText = "";
m_cListCtrl.InsertItem( &lvi );
for ( int j=0; j<2; j++ )
{
CString str;
str.Format( "Col %d, Row %d", j, i );
m_cListCtrl.SetItemText( i, j, str );
}
}
return TRUE; // return TRUE unless you set the focus to a control
}
void CMyDialog::OnBnClickedButton1()
{
int nItemIndex = 355;
CRect rcTopItem;
CRect rcSelItem;
// Current top visible item
int nTopIndex = m_cListCtrl.GetTopIndex();
// Get bounding rectangle around the current top item
m_cListCtrl.GetItemRect( nTopIndex + 1, &rcTopItem, LVIR_BOUNDS );
// Get bounding rectangle around the selected item
m_cListCtrl.GetItemRect( nItemIndex, &rcSelItem, LVIR_BOUNDS );
// Compute the y distance between the two items
CSize sz( 0, rcSelItem.bottom - rcTopItem.bottom );
m_cListCtrl.Scroll( sz );
m_cListCtrl.SetItemState( nItemIndex, LVIS_SELECTED, LVIS_SELECTED|
LVIS_FOCUSED );
m_cListCtrl.EnsureVisible( nItemIndex, FALSE );
m_cListCtrl.SetFocus();
}
|
|
|
|
|
Zombie_Inc wrote: m_cListCtrl.SetItemState( nItemIndex, LVIS_SELECTED, LVIS_SELECTED|
LVIS_FOCUSED );
You are clearing the LVIS_FOCUSED flag for the item in the above code. Was that your intention?
If fixing that doesn't help...
What if you clear the previous focused/selected item before setting the newly selected/focused
item?
m_cListCtrl.SetItemState( -1, LVIS_SELECTED|LVIS_FOCUSED, LVIS_SELECTED|
LVIS_FOCUSED );
m_cListCtrl.SetItemState( nItemIndex, LVIS_SELECTED|LVIS_FOCUSED, LVIS_SELECTED|
LVIS_FOCUSED );
|
|
|
|
|
Hi Mark,
All I can say is thank you a million times!!!!!
Your first suggestion did not help but clearing the
previous selected item did the trick.
I knew there was an easy fix for it.
Thanks again.
Regards
Lars
|
|
|
|
|
Cool!
I was just going to direct you to this, although it wouldn't have helped:
How To Select a Listview Item Programmatically[^]
Anyway, I looked up the default processing for WM_LBUTTONDOWN in a listview control and it got
me thinking that maybe just because the single-select style is set doesn't mean the control clears
the previous selection if you manually select another.
Glad it worked!
Mark
|
|
|
|
|
Was the correct code
m_cListCtrl.SetItemState( -1, 0, LVIS_SELECTED|LVIS_FOCUSED );
instead of
m_cListCtrl.SetItemState( -1, LVIS_SELECTED|LVIS_FOCUSED, LVIS_SELECTED|
LVIS_FOCUSED );
??
|
|
|
|
|
Before I start building my logger class, I wouldn't mind a having a few ideas on how to create it. This is a basic outline of what I need: The file needs to be divided into sections ( OS details, Error's and program flow ). The latter two sections would need to be resizable, but the file must have a max size limit. ( I don't want end users e-mailing me 10 mb log files ). The file doesn't need to be readable, I can create a seperate utility for this.
Now I'm not very sure how to procede. I'm thinking a memory mapped file with a linked list. But a linked list is basically a pointer to a pointer which isn't very practical in a mapped file. Another way I could do it is use some sort of hash table. Divide the whole file into chunks and each entered record has it's offset stored in a known place.
I'm open to ideas on this one.
|
|
|
|
|
How about two linked lists of file offsets - one for error entries, one for program flow entries.
Store a offset-first and offset-current for each list in a header struct at the beginning of (or
a known place) in the file.
To add a new entry:
1) get the offset-current
2) append the entry to the end of the file (noting it's offset)
3) move to the offset-current entry and update it's next-offset to the new entry offset
4) set the offset-current to the new entry's offset
4a) if it's the first entry then set offset-first as well
5) flush the file buffers to ensure the disk image is current in case of crashes.
Mark
|
|
|
|
|
It's probably the best way to approach the problem. The only trouble is dealing with the items when the file reaches it's max size. Obviously the oldest entries should be removed, but going from the begininning to the end is where the problem lies. Each entry would have to be a fixed size. So lets make them 256 bytes each, but what happens when a critical error occurs and it needs 600 bytes to log the error?
So I'm thinking of a structure similar to a FAT table. IE have allocation slots within the file, but the problem here is how to index them.
|
|
|
|
|
WalderMort wrote: The only trouble is dealing with the items when the file reaches it's max size. Obviously the oldest entries should be removed,
 Yeah. A linked list allows for variable size entries no problem (each entry just needs
a little header of some kind (with at least a next_offset field and a length field).
Whether you use a table (like FAT) or a linked list you still end up with fragmented file image
(little holes of free space) when removing oldest etries since there's two types of entries.
You'll have to periodically defrag anyway so a table would be much more efficient then walking
a chain of offsets every time.
I guess each entry in a FAT_style table could represent a 256-byte area of the log file.
Each entry only needs to be a WORD, with perhaps 0 indicating free, 0xFFFF indicating the last
entry in a chain of entries, and any other value indicates the index of the next entry in the
chain.
Reserve entries at index 0 and 1 for "directories" (one for each of the two types of log
entries). In the directories keep structs for each log entry - each struct has a timestamp and
an index into the "FAT" table of the first 256-byte "sector" of the entry. The directories can
grow as necessary since they are just linked chains in the "FAT" table. Of course, directory
entries need a way to be marked as free as well.
That's pretty similar to the FAT system if I remember right 
Thank goodness for random access files!
|
|
|
|
|
I had a thought about this last night. I will use a linked list of fixed size structures, let's say 128 bytes. Each entry may use one or more of these structures to span the data. The first would contain the time stamps, source details etc.. the next would act as an overflow from the first.
Continue like this until the end of the file is found, then, link the last to the first and overwrite the data within the first group of items, if more space is required, overwrite the next group also.
Depending on the size chosen for each structure, the wasted space would be limited to a few bytes for each entered record. In the header, I would only need to store the offset to the first and last. Each record would then store an offset to it's overflow and a count of it's overflows ( if required ) and the offset of the next list item.
On with the coding...
|
|
|
|
|
Could you consider to make a CP article on the subject? I find it really interesting, and so does others, I suspect.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Possibly, it really depends on how much closely it ties in with my project. Ultimatly I would like to make it re-usable, in which case I may create an article, if I have time.
|
|
|
|
|
I, for one, would (will) really look forward to such an article.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Hi All,
Here's an interesting one... Debug is Broken, Release is OK. I've got test cases down to failures on LARGE files in Debug Builds. The reason the large file does not exist in Release: Debug information is stripped (I'm literally probing my own EXE).
The original FileMapping code was shamelessly ripped from Matt Pietrek's An In-Depth Look into the Win32 Portable Executable File Format[^]. I can't seem to find what is wrong with the original useage.
I suspect this has to do with the Memory Manager's ability to keep up... Any ideas? Below is how I am using CreateFileMapping/MapViewOfFile.
Jeff
if( 0 == GetModuleFileName( NULL, szFilename, PATH_SIZE ) )
{
std::cout << _T("Error Retrieving Process Filename") << std::endl;
__leave;
}
hFile = CreateFile( szFilename, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if ( hFile == INVALID_HANDLE_VALUE )
{
std::cout << _T("Error - CreateFile()") << std::endl;
__leave;
}
hFileMapping = CreateFileMapping(hFile, NULL,
PAGE_READONLY, 0, 0, NULL);
if ( NULL == hFileMapping )
{
std::cout << _T("Error - CreateFileMapping()") << std::endl;
__leave;
}
PVOID pMappedFile = NULL;
pMappedFile = MapViewOfFile(hFileMapping, FILE_MAP_READ, 0, 0, 0);
if ( NULL == pMappedFile )
{
std::cout << _T("Error - MapViewOfFile()") << std::endl;
__leave;
}
|
|
|
|
|
Where exactly are you picking up the error and did you make sure you SetLastError before the whole process?
|
|
|
|
|
Hi Waldermort,
WalderMort wrote: Where exactly are you picking up the error...
From the Output Window in Visual Studio .NET on Windows 2000.
I also confirmed it was a bug Windows XP, and Windows Server 2003. And confirmed the behavior using Visual Studio 2005. The bad thing was, it was my bug...
Basically, when inspecting ones own .CODE section, one of two methods is used:
1) if the image is a disk image, use (.TEXT Section)pSectionHeader-> PointerToRawData to locate the first .CODE page on DISK.
2) if the image is a memory image, use (.TEXT Section)pSectionHeader-> VirtualAddress to locate the first .CODE page in MEMORY.
PointerToRawData is usually 0x1000. VirtualAddress is larger - for example 0x3D00. The previous is added to a image Base Address - 0x400000 (hModule), PVOID from MapViewOfFile(), etc. Under certain circumstances (Debug Builds with large LIB files that cause a cross of Granulation Boundary), an ACCEESS_DENIED occurs - more correctly Access Violation.
With Debug builds, VirtualAddress != PointerToRawData. In Release builds, VirtualAddress == PointerToRawData. Hence the reason why Debug failed, and Release was successful.
My error crept in with the fact that VirtualAddress >>> PointerToRawData, and I was using VirtualAddress when probing the disk image in Debug.
What was especially frustrating was the fact that I wasted time in WinDbg on my spare Server (it only has 700 MHz CPU and 768MB of RAM) - painful. My development machine has dual 1GHz with 2GB of RAM. This is my personal Test lab at the house - complete with a pair of Cisco 1700s for segment testing
Jeff
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
