|
can u detail that!where is the problem which part of teh code?
cheerz!
dont want,dont want thinking,climbing on head and jumping grass!
(venda venda ennu vicharikumbol thellayill keyaree chadunnoda pulle!)
|
|
|
|
|
mahesh_patil166 wrote: I have problem communicating bluetooth in visual c++ MFC
Hi Mahesh,
Please Elobrate your question.. How can we know which class are you using to communicate between bluetooth devices or you have proper hardware for same...
or you have get struck on a particular state!..
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
It appears that when you have a scrollbar in a dialog or property page, the scrollbar steals the WM_MOUSEWHEEL messages. If you have two scrollbars it's worse. One takes most of the messages when the mouse is over the dialog window unless the mouse is hovering over the other scrollbar. Is there any way to intercept or change this?
|
|
|
|
|
hi all,
i m working on an application where i want to create two document and views and want to pass data from one documnt to another.do i need to add childframe,view,document class to the MDI .i m not getting exact idea
sourabh jain
patni computers system
|
|
|
|
|
Hi all,
first of all thanks for this great site.
It has helped me a lot in the last weeks, but now i`m stuck in
a serious problem. I have a derived class of CListCtrl
In it is a custom draw method.
void CExtendedListCtrl::OnCustomdrawList ( NMHDR* pNMHDR, LRESULT* pResult )
{
NMLVCUSTOMDRAW* pLVCD = reinterpret_cast<NMLVCUSTOMDRAW*>( pNMHDR );
*pResult = 0;
if ( CDDS_PREPAINT == pLVCD->nmcd.dwDrawStage )
{
*pResult = CDRF_NOTIFYITEMDRAW;
}
else if ( CDDS_ITEMPREPAINT == pLVCD->nmcd.dwDrawStage )
{
int iRow = pLVCD->nmcd.dwItemSpec;
if ((int)GetItemData(iRow) == 1)
pLVCD->clrTextBk = RGB(60,179,113);
}
*pResult = CDRF_DODEFAULT;
}
This is working fine when i add a item to the extended ListCtrl over
m_List.InsertItem and then setting the itemData to m_List.SetItemdata(1)
Now i have a huge amount of data (>100000) in the extended ListCtrl and
the insertion is getting really slow.
So i want to use OnGetDispInfo to just draw the "visibles" entries.
void CEvtlParseDlg::OnGetdispinfoList(NMHDR* pNMHDR, LRESULT* pResult)
{
LV_DISPINFO* pDispInfo = (LV_DISPINFO*)pNMHDR;
LV_ITEM* pItem= &(pDispInfo)->item;
if(pItem->mask & LVIF_TEXT)
{
if (pItem->iSubItem == 0)
{
pItem->mask=LVIF_TEXT | LVIF_PARAM;
pDispInfo->item.lParam=1;
lstrcpyn(pItem->pszText,"TEST",pItem->cchTextMax);
}
}
*pResult = 0;
}
This nearly works. I get the "TEST" text in my ListCtrl. OnCustomDrawList of
the extended List is still called, but the GetItemData always returns 0;
I also tried to get pLVCD->nmcd.lItemlParam but this value is also always 0
So how can i set itemData in the OnGetDispinfoList or is there only the way of using
InsertItem?
thx alot
t2x
|
|
|
|
|
t2x wrote: pDispInfo->item.lParam=1;
That doesn't change the actual item data, you're just modifying an LVITEM that the control set up for you to look at.. Call SetItemData().
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
But SetItemData is not working.
Whenever i call it in the OnGetDispinfoList
m_List.SetItemData(pItem->iItem,1);
or in an other program part i get an ASSERTION in WINCTRL2.CPP
BOOL CListCtrl::SetItem(int nItem, int nSubItem, UINT nMask, LPCTSTR lpszItem,
int nImage, UINT nState, UINT nStateMask, LPARAM lParam)
{
ASSERT(::IsWindow(m_hWnd));
ASSERT((GetStyle() & LVS_OWNERDATA)==0); <--- This one gives me the assertion
.
.
.
I can`t imagine that there is no way to set the ItemData during the virtual ListCtrl
call OnGetdispinfoList
thx t2x
|
|
|
|
|
Oh ok, you didn't mention that you were using a virtual list control. From the docs:A virtual list-view control maintains very little item information itself. Except for the item selection and focus information, the owner of the control must manage all item information. You'll need to keep the data somewhere else, a virtual list control doesn't support per-item data.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Just to let you know... I have this exact same problem and I've yet to track down the solution.
OnGetDispInfoList() is never invoked with a request to provide LVIF_PARAM nor does the system accept the value if you set the value manually as you are doing. My only solution was to rewrite the code in OnCustomDraw() to calculate the value of the lParam member on the fly - not elegant, but workable for my application.
Surely someone out there has (a) made this work, or (b) found the MSDN webpage where Microsoft admits they just forgot to make the virtual list ctrl's ask for the lParam value. At this point I'll be happy with either (a) or (b).
Sigh...
Dan
Remember kids, we're trained professionals. Don't try this at home!
|
|
|
|
|
Hm O.K. than i have to deal with this.
This is not really nice but it works.
Another short question. Is there any chance to set the "selected" State
in the OnGetDispInfoList without calling SetItemState.
Because this is terrible slow if i want to select all items.
thx t2x
|
|
|
|
|
Gee, I don't know right off the bat. My app only needs 'single' select. You'd really think that there ought to be, then again that sort of thinking about the LPARAM value is what got us here.
Sigh... all of those programmer-hours spent cobbling together work arounds for things like this.
Later,
Dan
Remember kids, we're trained professionals. Don't try this at home!
|
|
|
|
|
I have some code that I want to split off into it's own dll. Can I have the following method in the DLL and call it from a Client, like this?
void DllFunction (std::vector<int> &B)
{
B.push_back(1);
}
----------------------
void SomeFunction ()
{
std::vector<int> A;
DllFunction(A);
}
This works fine when all the code is in the same project but when I split off the DllFunction into it's own Dll, I get errors. I get a runtime error in _CrtIsValidHeapPointer (dbgheap.c) when SomeFunction returns. I suppose the problem is that the DLL allocates the memory and the Client is trying to free it and that's bad.
So, what do people do when they want to pass an STL vector as a reference parameter to a DLL? Cannot such a basic thing as this be done? Do I have to redesign things now that the code is in a Dll? I've looked at MS Knowledge Base Q168958 but it doesn't seem to help me.
I've made sure my runtime libraries are the same for the dll and the client (/MTd), but that didn't fix the problem.
|
|
|
|
|
You should never count on being able to alloc memory in one module, and free it in another module, using the CRT. You can use a process-wide allocator like CoTaskMemAlloc().
--Mike--
Visual C++ MVP
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Hi, I'm not an expert, but I recently ran across a similar problem. Try switching your projects to use the DLL version of the run-time libraries and see if that resolves the issue.
--
jthomps
|
|
|
|
|
Another solution (from Jeff's) would be to make an allocator that uses, say, CoTaskMemAlloc. Then you would create all your colloections using this allocator.
Steve
|
|
|
|
|
Try to do vector:reserve in *.exe before any push_back in *.dll to ensure all memory allocation activities are done in the executable.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Assume the following code:
#CODEBEGINS
int main( void )
{
CCPU CPU; // For CPU querys
HLint64 Begin, End; // To keep CPU times
int i, j; // Counters
tVar<int> *tvTest; // Test material
for ( i=1 ; i<500 ; i++ ) {
for ( j=0 ; j<i ; j++ ) {
// Begin counting
Begin = CPU.rdtsc();
tvTest = new tVar<int>;
delete tvTest;
// Stop counting
End = CPU.rdtsc();
// Calculations & output
printf( "[%d:%d]:(delta)TSC: %ld\n", i, j, ( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) );
}
putchar( '\n' );
}
return 0;
}
#CODEENDS
This is suppose to test how fast the computer allocs and frees a class (note: this class has no constructor). I got the following results:
[1 ]:(delta)TSC: 3234
[2 ]:(delta)TSC: 1385
[2:1]:(delta)TSC: 1212
[3:1]:(delta)TSC: 1189
[45:10]:(delta)TSC: 1230
[48:37]:(delta)TSC: 1240
[52:4]:(delta)TSC: 1571
[53:6]:(delta)TSC: 409762 // WOW!
[53:7]:(delta)TSC: 1375
[55:10]:(delta)TSC: 1296
[58:7]:(delta)TSC: 1239
[448:338]:(delta)TSC: 1177 // Almost all not shown so far are 1177
[448:339]:(delta)TSC: 10015
[448:340]:(delta)TSC: 1263
[448:341]:(delta)TSC: 1157
[448:342]:(delta)TSC: 1194 // Almost all from now on are 1194 (this only happned in one of the tests, all the others still had a HUGE majority of 1177)
Can anyone explain these small (sometimes not that small!) variations?
regards
hint_54
-- modified at 14:27 Tuesday 14th February, 2006
Oh.. I forgot, assume this is the CPU.rdtsc() function:
HLint64 CCPU::rdtsc( void )
{
HLint64 i64StampRead;
// Read time stamp counter
__asm {
rdtsc; // ReaD Time Stamp Counter
mov [i64StampRead.Lo], eax // Copy the low DWORD
mov [i64StampRead.Hi], edx // Copy the high DWORD
}
return i64StampRead;
}
regards, once again 
|
|
|
|
|
hint_54 wrote: Can anyone explain these small (sometimes not that small!) variations?
Read here.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
"QueryPerformanceCounter returns a reasonably accurate rendering of time, at least on Intel platforms. This is because on Intel platforms it returns the contents of a "cycle counter", converted to timing units based on the processor frequency. Because the cycle counter actually counts the number of CPU cycles, it gives a reasonable approximation of real time. However, executing the same loop twice may give different results because the presence or absence of data in the cache will change the number of cycles required to execute the program. So it is at best an approximation, and you have to do some more careful statistical analysis to figure out what is really going on."
This was quoted from the link that you have provided earlier.
Does this mean it is all about cache? If so, please assume the following code then:
int main( void )
{
int *ptr, i;
for ( i=0 ; i<100 ; i++ ) {
ptr = new int;
delete ptr;
}
return 0;
}
So, after "i=0", "i" gets in the cache. After the first time it executs "ptr = new int" "ptr" gets in cache too. From now on, all the 100 cicles will use "i" and "ptr" and these are supposed to be already cached, right? The only thing that I can see that is not cached is "*i", but I never access it directly (or do I?  ). So, I understand why the first values show a small variation (after the first 4 or 5 cicles it stabilizes), but I still don't understand why those variations keep showing up along the whole test (unless I'm really accessing "*i").
Anyone? 
regards
hint_54
|
|
|
|
|
That's a big variation, I don't think this can be written off to the fact that Windows is not a real time OS. I'd put timing around ever line in the loop so I've got a breakdown and try to narrow down the problem.
Steve
|
|
|
|
|
Aside from the issues about getting any sort of solid timings under Windows (pointed out ably by earlier responders), there is a subtle error in the time calculation that should be noted.
hint_54 wrote:
// Calculations & output
printf( "[%d:%d]:(delta)TSC: %ld\n", i, j, ( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) );
The calculation of '( Hi - Hi ) + ( Lo - Lo )' is not the correct implementation of a 64-bit difference. This code calculates two independent 32-bit differences and then sums them together, ignoring the difference in the order of magnitude represent by the 'Hi' values compared to the 'Lo' values.
Now, for this particular exercise, most of the time, in fact nearly all of the time, the answer will be still be correct because 'End.Hi' will equal 'Begin.Hi' giving a difference of 0. Indeed in this particular snippet of code, we may very well be lucky and never run into trouble.
But once in a great while things will go wrong. When you sample the timer for Begin just before the 'Lo' word rolls over and then sample the timer for End just after the rollover occurs, then the resulting calculation will be off because 'Hi - Hi' will no longer be 0, it will be 1. But in truth it's not really 1, it really represents 0x100000000.
Consider the following simple examples using 2 digit hexadecimal numbers. (The low order nibble will represent our be our 'lo' word and the high order nibble will represent our 'hi' word.)
Ex 1: Usual Case - no 'rollover'
<br />
Begin = 0x95
End = 0x98
<br />
End - Begin = 0x98 - 0x95 = 0x03<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0x9 - 0x9 ) + ( 0x8 - 0x5 ) = <br />
( 0x0 ) + ( 0x3 ) = 0x03<br />
<br />
Ex 2: Rare Case - 'rollover' bites us
<br />
Begin = 0x9E
End = 0xA1
<br />
End - Begin = 0xA1 - 0x98 = 0x03<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0xA - 0x9 ) + ( 0x1 - 0xE ) = <br />
( 0x0 ) + ( -0xD ) = -0x0C<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0xA - 0x9 ) + ( 0x1 - 0xE ) = <br />
( 0x0 ) + ( 0x3 ) = 0x04<br />
In either case for the 'rollover' example we get the wrong value (potentially very wrong). To correct the issue use true 64-bit arithmetic on these 64-bit values.
Dan
|
|
|
|
|
You mean this?
( ( End.Hi - Begin.Hi ) << 32 ) + ( End.Lo - Begin.Lo )
regards
hint_54
|
|
|
|
|
hint_54 wrote: You mean this?
( ( End.Hi - Begin.Hi ) << 32 ) + ( End.Lo - Begin.Lo )
regards
hint_54
Well, not really... If ( End.Lo - Begin.Lo ) generates a 'borrow' condition, that condition is not propagated up to the ( End.Hi - Begin.Hi ).
The shift by 32 also won't work since you are shifting a 32-bit value by 32-bits. The compiler does not automatically promote this expression to 64-bits. The shift results in either 0 because all of the bits get shifted out of our 32-bit value or, if you are on an intel processor or intel clone (and aren't we all), it remains unchanged because the hardware performs a ( modulo 32 ) on the shift count and you end up shifting by 0 bits.
A fully general solution would be to use something like ULARGE_INTEGER[^]
<br />
ULARGE_INTEGER largeBegin;<br />
ULARGE_INTEGER largeEnd;<br />
ULARGE_INTEGER largeResult;<br />
<br />
largeBegin.LowPart = Begin.Lo;<br />
largeBegin.HighPart = Begin.Hi;<br />
<br />
largeEnd.LowPart = End.Lo;<br />
largeEnd.HighPart = End.Hi;<br />
<br />
largeResult.QuadPart = largeEnd.QuadPart - largeBegin.QuadPart;<br />
<br />
printf( "Delta = %u\n", largeResult.LowPart );<br />
Because we are computing time deltas that we know are much, much less than 232, we can safely ignore largeResult.HighPart - it will always be 0. We just had to perform 64-bit math to handle those occasional 'borrow' conditions. If we were doing general math on arbitary values, then we couldn't just throw that value away.
Later,
Dan
Remember kids, we're trained professionals. Don't try this at home!
|
|
|
|
|
HI,
I am using the code below for writing in the file, that file opening on windows XP using WordPad , and the data is in new line for every \n but in win2k and XP 2003 server \n does not works and a box appears and all the data is written in one line.
Why it is so ?
CString write = res+",\t\t\t"+res1+"\n";
percentFile.Open( strFormulaPath , CFile::modeCreate|CFile::modeNoTruncate|CFile::modeReadWrite|CFile::typeBinary);
percentFile.Seek(0L,CFile::end);
percentFile.Write(write , write.GetLength ());
percentFile.Close ();
Regards.
|
|
|
|
|
Use "\r\n" instead of just "\n"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
