|
Use the String Table resource, don't put strings in code.
My blogs:
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
http://bloglines.com/public/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
hello,
Iam using CInplaceEdit class which I got from our own "codeproject".
This class adds an edit box into grid. Iam extending the feature by associating a spinbutton control with this edit box.
I have successfully done this.
But there are some problems which Iam unable to solve, which are as follows.
1) when the focus is in edit box and user pressess Up or Down arrow key in order to change the value of the buddy (edit box), the edit box looses focus and when user again clicks in the edit box & presses Up or Down arrow key the value of buddy changes & again edit box looses focus, & same process is repeated.
What is the solution to this.
2) when the grid column is resized it is showing many edit and spinner button control.
for more information Iam posting the code for creating a spinner button control:
BOOL CInPlaceEdit::ShowEditCtrl(DWORD dwStyle,
const RECT &rCellRect,
CWnd* pParentWnd,
UINT uiResourceID,
int iRowIndex,
int iColumnIndex,
CString& strValidChars,
CString& rstrCurSelection)
{
m_iRowIndex = iRowIndex;
m_iColumnIndex = iColumnIndex;
m_strValidChars = strValidChars;
m_strWindowText = rstrCurSelection;
m_bESC = FALSE;
if (NULL == m_pInPlaceEdit->m_hWnd)
{
BOOL bCreated = m_pInPlaceEdit->Create(dwStyle,rCellRect, pParentWnd, uiResourceID);
CRect rect;
rect.left = rCellRect.left + 50;
rect.top = rCellRect.top;
rect.right = 20;
rect.bottom = rCellRect.bottom;
bCreated = m_spinCtrl.Create(WS_CHILD | WS_VISIBLE | UDS_ALIGNRIGHT | UDS_SETBUDDYINT | UDS_ARROWKEYS |UDS_AUTOBUDDY
, rect, pParentWnd, IDC_SPIN);
m_spinCtrl.SetRange32(0, 1000);
UDACCEL uda;
uda.nInc = 20;
uda.nSec = 0;
m_spinCtrl.SetAccel(1, &uda);
m_spinCtrl.SetBuddy(m_pInPlaceEdit);
return bCreated;
}
return TRUE;
}
You need to comment(remove) following statement from "OnKillFocus" event handler of CInPlaceEdit class
//PostMessage(WM_CLOSE);
also one thing I observed that whenever u clicks on edit box Kill Focus event is generated is this the reason of edit box loosing focus??
Please help me.
I have almost achieved this but stuck b'coz of this minor(offcourse minor for u GURUS) problem.
|
|
|
|
|
Shoaib Patel wrote: 1) when the focus is in edit box and user pressess Up or Down arrow key in order to change the value of the buddy (edit box), the edit box looses focus and when user again clicks in the edit box & presses Up or Down arrow key the value of buddy changes & again edit box looses focus, & same process is repeated.
What is the solution to this.
In the CInPlaceEdit c'tor set the m_bExitOnArrows variable to false, this will prevent CInPlaceEdit::OnKeyDown from kicking you out of the edit control when an arrow key is pressed.
Shoaib Patel wrote: 2) when the grid column is resized it is showing many edit and spinner button control.
Override CGridCellBase::Draw to do your cell's drawing
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Hello PJ
I did not found the boolean member variable "m_bExitOnArrows" in CInPlaceEdit
class & not even in it's base class CEdit.
What did u mean by that
should I supposed to declare it...
plz clearify it.
Thank u for ur reply.
|
|
|
|
|
First lets clarify which CInPlaceEdit we are talking about. The only one I know comes with Chris' MFC Grid[^]. If you are talking about another one then I am sorry, you can ignore my post. If we are talking the same one then m_bExitOnArrows is a private member of CInPlaceEdit.
On line 69 of InPlaceEdit.cpp change
m_bExitOnArrows = (nFirst != VK_LBUTTON); to
m_bExitOnArrows = FALSE;
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Ok,
no both of we are talking about different CInPlaceEdit.
the one which u are talking about is of Chris Maunder's class & the one Iam talking about is of Aravindan Premkumar's.
but any ways thank u for answering.
If u think u can, u r right.
If u think u can't, think over it.
Shoaib Patel/
|
|
|
|
|
Hi friends,
If I have an array containing integer and I want to access elements of it using pointers.
int i=0;
int *ptr=array;
int value=0;
for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
Is there any performance hit of
value=*(ptr+i);
over
value=*ptr++;
Vikram S
|
|
|
|
|
Please look the updated code
int array[]={1,2,3,4,5,6,7,8,9,10};
int i=0;
int *ptr=array;
int value=0;
for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
|
|
|
|
|
vikrams wrote: for(i=0; i < 10;i++)
value=*ptr++;
should be a little faster than:
vikrams wrote: for(i=0; i < 10;i++)
value=*(ptr+i);
But it's likely to be the same with: value=array[i]
|
|
|
|
|
vikrams wrote: for(i=0; i < 10;i++)
value=*(ptr+i);
for(i=0; i < 10;i++)
value=*ptr++;
I don't know if the compiler is able to optimize this, but if we disregard from eventual compiler optimizations the second for-loop will be faster.
Consider the first for-loop.
For each round-trip you...
1) increase the value of i which is held in a register
2) load the address of ptr into another register
3) add the value of i to the register holding ptr 
4) assign to value using indirect addressing
Now consider the second for-loop.
For each round-trip you...
1) increase the value of i which is held in a register
2) assign the value of i using indirect addressing
There's more to it than this, but I've omitted parts that are the same for both for-loops such as calculation of the size of the data type pointed to and similar.
It's possible that the compiler is smart enough to optimize the first for-loop so it would generate the same machine code as if you would have written ptr[i], which I beleive would generate the fastest execution, but you have to look at the generated assembler code to be able to figure that one out. An exercise for the reader.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Microsoft VC++ 6.0 compiler generated following code
for: value=*(ptr+i);
mov edx, DWORD PTR _i$[ebp]
mov eax, DWORD PTR _ptr$[ebp]
mov ecx, DWORD PTR [eax+edx*4]
mov DWORD PTR _value$[ebp], ecx
for: value=*ptr++;
mov eax, DWORD PTR _ptr$[ebp]
mov ecx, DWORD PTR [eax]
mov DWORD PTR _value$[ebp], ecx
mov edx, DWORD PTR _ptr$[ebp]
add edx, 4
mov DWORD PTR _ptr$[ebp], edx
|
|
|
|
|
Yep, the compiler optimizes the first for-loop and generates the exact same assembler as ptr[i].
Conclusion:
Writing *(ptr + i) generates faster code than *ptr++.
However, for readability reasons I recommend writing ptr[i].
Have a nice weekend
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
It generates faster code because there is no code to update the value of ptr. The two operations do different things so it is like comparing apples and oranges.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: It generates faster code because there is no code to update the value of ptr.
You're talking about the resulting assembler code and in that aspect it's obvious.
However, I was not sure how the compiler would deal with the (ptr + i) operation since I haven't tested it, which I hope was clear enough in my previous post. 
PJ Arends wrote: The two operations do different things
Nope. Both for-loops walks through the array getting the value of each element and assigns it to 'value'.
However, the statement for getting the value of each element is different, but I interpreted vikram's question as if this doesn't matter.
Like you said: "You may be right, I may be crazy".
Have a nice weekend PJ
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
I guess my problem is not in setting up the initial directory for the
CFileDialog but rather in changing it when the dialog is up and running.
When the user selects a file type from file type selection list, say
.bmp type file, for example, I want the path changed from the current
dialog path to a bitmap directory. Any idea of how to get the dialog
change to a different directory?
Thanks for your help.
Linus
|
|
|
|
|
Subclass CFileDialog and override OnTypeChange which will get called when the user selects another filter.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
hi,
very nice, but how will i change now the Path to my specified? e.g C:\\Templates!
like Word 2003 when i will save a Doc as Dot?
|
|
|
|
|
I assume you know that if you write a path to a directory in the filename field and click 'Open', your file list will be updated with contents of that directory.
You can simulate this behaviour by the following steps:
1. Save the eventual already written information in the filename field
2. Paste the desired directory path to the filename field
3. Send a WM_COMMAND message simulating a click on the 'Open' button
4. Restore the previously wrriten contents of the filename field
Read Hans Dietriech's excellent article[^] if you need more info of how to do this in code.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Do you need to save current path for next time?
|
|
|
|
|
|
hi,
I am getting an MIDL2039 warning when you compile an .idl file .
Can anyone plz help me?
Thanx in advance,
skuu
|
|
|
|
|
I guess you've added the oleautomation keyword to an interface definition.
The MIDL compiler is complaining about the interface not being compliant with oleautomation, e.g you've used variables that cannot be represented with a VARIANT.
Or in other words from MSDN:
"MIDL2039 : interface is not automation marshaling conformant, requires Windows NT 4.0 SP4 or greater
The interface does not meet the requirements for an OLE Automation interface. Check to make sure the interface is derived from IUnknown or IDispatch."
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
thank u roger.
I like to know whether it is possible to disable this warning.
rgds,
skuu
|
|
|
|
|
By settings the 'oleautomation' option for an interface you ask the MIDL compiler for help making sure that the interface is compliant with the automation standard.
Asking for the compilers help and then tell it to shut up doesn't make any sense.
Remove the 'oleautomation' keyword from the interface definition instead.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
Hello,
I'm translating my application to different languages using resources files. I don't know how to manage different configurations of my Visual C++ project for each language. I've never done it before.
Can somebody point me to an article discussing that subject?
Thanks,
Sincerely
Allad
----
Navigator - Your best alternative to Windows Explorer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
