|
yes you were right. now code is working.
thanks. 
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
IIRC GetXXXRect take pointers as parameters. Have you tried with
pGridCtrl->GetWindowRect(&grid_rect);
Same comment for the GetClientRect call a few line above.
|
|
|
|
|
This is working fine :-
void CMainView::OnInitialUpdate() {
CFormView::OnInitialUpdate();
initialized = TRUE;
CWnd *pGridCtrl = GetDlgItem(IDC_SALEPURCHASEGRIDCTRL);
CRect rect,grid_rect;
CWnd *pWnd = this->GetOwner();
pWnd->GetClientRect(rect);
pGridCtrl->GetWindowRect(grid_rect); grid_rect = rect;
grid_rect.left += 16;
grid_rect.top += 150;
grid_rect.bottom -= 300;
grid_rect.right -= 16;
pGridCtrl->MoveWindow(grid_rect); .
.
.
This is not working properly:-
void CMembersView::OnInitialUpdate()
{
CFormView::OnInitialUpdate();
initialized = TRUE;
CWnd *pGridCtrl = this->GetDlgItem(IDC_MEMBERSGRID);
ASSERT(pGridCtrl);
CRect rect,grid_rect;
CWnd *pWnd = this->GetOwner();
pWnd->GetClientRect(rect);
pGridCtrl->GetWindowRect(grid_rect); grid_rect = rect;
grid_rect.left += 16;
grid_rect.top += 150;
grid_rect.bottom -= 300;
grid_rect.right -= 16;
pGridCtrl->MoveWindow(&grid_rect);
.
.
.
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
Are the coordinate that should be returned by GetWindowRect really null ? What does the debugger says (if you look into the pGridCtrl structure) ? Have tried GetLastError ?
|
|
|
|
|
In CMainView :-
grid_rect {top=-0 bottom=912 left=0 right=1819} CRect
In CMembersView :-
grid_rect {top=-32639 bottom=-32483 left=-32709 right=-31884} CRect
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
Actually, you are overwriting grid_rect in the next part of the code with the content of rect, making the GetWindowRect call unnecessary. What if you comment out this line pGridCtrl->GetWindowRect(grid_rect); ?
( just to test if the MoveWindow is accepted).
|
|
|
|
|
I use it to just test whether grid_rect fetches some values or not.
Ok. I comment it out. But still it doesn't help.
---------------------------------------------
" Future Lies in Present "Manmohan Bishnoi
|
|
|
|
|
Then I guess the OP was right and the structure/window is not initialized properly at this point of time. So either this is the standard behaviour, and you will have to initialize it in another event, or something goes wrong when creating the GridCtrl.
|
|
|
|
|
This code below occurs no error but the result seems a bit weird.
class KBase
{
public:
void BaseFun()
{
printf( "KBase::BaseFun() this=%p\n", this );
}
};
class KMiddle : public KBase
{
};
class KMiddle2 : public KBase
{
};
class KDerived : public KMiddle, public KMiddle2
{
};
int main()
{
KDerived d;
d.KBase::BaseFun(); d.KMiddle::BaseFun(); d.KMiddle2::BaseFun();
return 0;
}
BaseFun simply shows this pointer and the result goes..
---------------------------
KBase::BaseFun() this=0012FF63
KBase::BaseFun() this=0012FF63
KBase::BaseFun() this=0012FF64
---------------------------
So my question is why KBase::BaseFun() and KMiddle::BaseFun() show the same address and the only KMiddle2::BaseFun() does the different address?
I was looking for the answer by reading Stephen Prata's book and Effective C++ but I couldn't.
Thanks in advance.
modified on Wednesday, August 24, 2011 9:51 PM
|
|
|
|
|
Which complier do you use?
in some complier that follow the standard c++ strictly, like g++, your code will not compiled and got Error Message:
`D' is an ambiguous base of `B'
To make the multiple inheritance follows the standard c++ well, you should using virtual inheritance in this case.
class KMiddle : virtual public KBase
class KMiddle2 : virtual public KBase
class KDerived : public KMiddle, public KMiddle2
|
|
|
|
|
Hi,
xrg_soft@163.com wrote: Which complier do you use?
I use Visual Studio 2008.
xrg_soft@163.com wrote: To make the multiple inheritance follows the standard c++ well, you should using virtual inheritance
I know that the multiple inheritance needs virtual inheritance.
However, when I don't on purpose, the result seems not understandable.
Could you explain to me why those 'this' addresses look unrestrained?
|
|
|
|
|
In your case(no virtual inheritance used),
the
The inside of the KDrived object, there is a KMiddle object followed by a KMiddle2 object.
d.KBase::BaseFun();
d.KMiddle::BaseFun();
actually calls to the function of the KMiddle object.
and
d.KMiddle2::BaseFun();
calls to the function of the KMiddle2 object.
As your Kxxx object contains nothing, so sizeof(Kxxx) == 1
That's why the result printed.
And if you adding somemember variable into the class, then the result should be:
KBase::BaseFun() this=<base />
KBase::BaseFun() this=<base />
KBase::BaseFun() this=<base> + sizeof(KMiddle)
|
|
|
|
|
Thank you so much!!
I truly appreciate it!
|
|
|
|
|
From "Diamond problem" at Wikipedia[^]:
C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" (for example, "class B : virtual public A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A. Please note that nonvirtual derivation of A in this case will be useless as direct access to any part of class A from class D will practically always end up with compile error.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
how it is possible to find out the running exe handle and name from the prcess tab of task manager
programmatically
Trioum
|
|
|
|
|
Not exactly sure what you mean, but try starting here[^]. Does this help?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
|
Hi all, I am searching the web and can not find any fast way to apply Lens Blur effect like in PhotoShop. For now, I have used convolution matrix with shape drawn to kernel, but it is very slow compared to Photoshop's one.
I have read many stuff on net about speeding up 2D Convolution process, but the most interesting seems to be using of GPU, but can not find any example...
Another way I can imagine is to use somehow HLSL to modify texture and then convert it back to bitmap, but still do not know how to do that...
Can anybody point me into right direction?
Thanks in advance...
|
|
|
|
|
I'd suggest a google search for "hlsl convolve filter."
If you haven't looked at GPUgems yet, you should check out Chapter 27 of GPUgems 2.
27.1.1 has information regarding how to select the pixels that are neighbours to the pixel in question.
If you download Demoniak, there's a fist-full of examples at http://www.ozone3d.net[^]
|
|
|
|
|
I use the following lines of code in my program to get focus to a particular object and select it:
hr = (SELFLAG_TAKEFOCUS,varTemp);
hr = pTempAcc->accLocation(&left,&top,&width,&height,varTemp);
The trouble is that after the my program has been running for a while ( as such there is no specific limit or minimum), the execution just hangs at pTempAcc->accSelect() and the only way to stop it is a forced exit.
Can anyone tell me why this might happen.
|
|
|
|
|
There appears to be some code missing from the 1st line you posted.
Looking at the MSDN page for IAccessible::accSelect Method[^] we can see an example given as:
HRESULT SelectItemAtPoint(POINT point)
{
VARIANT varItem;
IAccessible* pAcc;
HRESULT hr = AccessibleObjectFromPoint(point, &pAcc, &varItem);
if ((hr == S_OK))
{
hr = pAcc->accSelect((SELFLAG_TAKEFOCUS | SELFLAG_TAKESELECTION), varItem);
VariantClear(&varItem);
pAcc->Release();
}
return hr;
}
Which immediately causes me to wonder if perhaps you haven't done the clean-up for your equivalents of varItem and pAcc in the above block
|
|
|
|
|
The same problem occurs even when i give both the flags as follows:
hr = pAcc->accSelect((SELFLAG_TAKEFOCUS | SELFLAG_TAKESELECTION), varItem);
|
|
|
|
|
Do you perform the clean-up as shown in the example in my last post?
|
|
|
|
|
Clean up does not help either.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
