|
Hi there,
First thank you for the answer.
Actually i know about the referentail integrity needed in a 1-to-many connection.
The thing is i don't know how to use it in actual user interface of MFC.
Lets Say as you said i have :
Table1.ID - connected in m_T1_ID linked to a CEdit Value : m_edtVal
Table1.Table2ID - connected in m_T1_T2_ID linked to a CComboBox Value : m_cmbVal
How can i put all Table2 Entries in m_cmbVal and put the Actual Table2.ID inside Table1.Table2ID ?
m_pSet->AddNew();
// Somwhere in here i should reference the 1-to-many, but how ???
Thank you for your answer,
Ariel.
|
|
|
|
|
Does static_cast<> produce any code or
class_A_ptr *a = static_cast < class_B_ptr * > (b);
is equal to
class_A_ptr *a = (class_B_ptr *)b;
?
With the best regards, Vitaly.
|
|
|
|
|
Testing with MS Visual C++, in release build, no difference, code size was the same either way.
|
|
|
|
|
the newstyle casts are basically the same as the oldstyle casts, except the results are more clearly defined.
(class_B_ptr*) is actually a combination of several kinds of casts, const_cast and static_cast depending on situation. there is also dynamic_cast and reinterpret_cast, which all do different things, and only very specific things (unlike the oldstyle casts which would often allow you to do something you didn't intend to do).
static_cast can sometimes generate code, for instance, when casting an object with multiple vtables, the vtable is adjusted when you cast it. but generally speaking it usually does not.
|
|
|
|
|
thanks a lot
With the best regards, Vitaly.
|
|
|
|
|
How could I close a modeless dialog from a view? This dialog is opened by a thread defined in the view (like as: AfxBeginThread(RUNTIME_CLASS(CThread)) ). The dialog isn´t defined in view, it´s defined in a CWinThread.
|
|
|
|
|
Do you want to hide it, or destroy it ? If you want to hide it, use ShowWindow(SW_HIDE), if you want to close it permanently, use DestroyWindow()
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
On clicking on an item of a tree I don´t get an answer until I click it tree times. How can I get it to answer on the first click? I treat it on "OnLButtonDown" and on "OnClick" but with the same result.
|
|
|
|
|
trap the TVN_SELCHANGED notification message
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
How could I from the cancel button from a dialog close all the program? Thanks
|
|
|
|
|
DoModal() will return IDCANCEL if the cancel button is clicked.
just post a WM_CLOSE message to your main window.
CMyDialog thedialog;
int returnvalue = thedialog.DoModal();
if (returnvalue == IDCANCEL)
AfxGetMainWnd()->PostMessage(WM_CLOSE);
else
...
|
|
|
|
|
Sorry, it´s me again. I desperately need a modeless dialog over a view WHILE it is filled with a treecontrol that is on view (the view is a CTreeView).
I create a modelees dialog before filling in the tree view, immediately I fill in the tree but the modeless dialog doesn´t come out on the screen until the tree hasn´t completely filled in and it is useless I can´t use it.
Could you help me to show modeless dialog correctly? Thanks. Could you explain it step by step?
|
|
|
|
|
I always do it in the constructor :
If (Create(pParent, IDD))
ShowWindow(SW_SHOW);
then I make my dialog a pointer, and call new on it when I want my dialog to appear. Depending on the dialog, I either delete and recreate, or use ShowWindow to hide and reshow it.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
ok, I have got the modeless but now I can´t click on any button of the modaless dialog while the tree is filling.
|
|
|
|
|
isnt this a threading issue? the view treectrl is not returning until it is filled in completely and so the dialog doesn't get its kick-off message ... maybe spin one of the tasks off into a separate thread and 2 things at once so to speak
alternatively you could post a message back to your main window or view or whatever after the initdialog has completed telling the view to build the tree now
or did i miss the point?
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
I coded an application using hook events but when I trace events in debug mode, only the events sent by this application are catched!! The application doesn't catch others events from Windows!!
My hook functions are in a dll, I don't understand!!
|
|
|
|
|
I'm trying to figure out how to make a deque from scratch. Can anyone help me?
|
|
|
|
|
are you talking about a fifo buffer? if so just use a circular buffer of ptrs to the objects you want to queue and dequeue and manage the head and tail ptrs as required ... i would suggest a doubly linked list as the easiest way to do this
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Can I resiza a column in a DataGrid control (whriting a code of cource)
|
|
|
|
|
I am trying to write a safe DC class, so I can avoid the hassle of keeping track of pens and brushes returned to me, as well as a one step create/select bitmap process.
Here is what I am doing:
CPen* CGDC::SafeSelect( CPen* pPen )
{
if (m_pOldPen)
{
return SelectObject(pPen);
}
else
{
m_pOldPen = SelectObject(pPen);
return m_pOldPen;
}
}
CBrush* CGDC::SafeSelect( CBrush* pBrush )
{
if (m_pOldBrush)
return SelectObject(pBrush);
else
{
m_pOldBrush = SelectObject(pBrush);
return m_pOldBrush;
}
}
m_pOldPen and m_pOldBrush are both NULL, I have stepped through and both functions behave as I would expect, as does the destructor:
CGDC::~CGDC()
{
if (m_pOldPen)
SelectObject(m_pOldPen);
if (m_pOldBrush)
SelectObject(m_pOldBrush);
if (m_pOldFont)
SelectObject(m_pOldFont);
DeleteDC();
}
Here's the thing. I tested it with this:
// for (int j = 0; j < 500; j++)
{
CGDC dc;
for (int i =0; i<500; i++)
{
CPen pen;
pen.CreatePen(PS_SOLID, 1, RGB(0,0,0));
/*CPen* pPen = */dc.SafeSelect(&pen);
CBrush brush;
brush.CreateSolidBrush(RGB(0,0,0));
dc.SafeSelect(&brush);
// dc.SelectObject(pPen);
}
}
Now, no matter which loop I comment in, if I comment out the SafeSelect on the pen it works fine. If I include the pen select and the call to SelectObject, it works fine. If I declare pPen here or not, if I call SafeSelect on the pen, it doesn't matter if I grab pPen here or not - unless I select it here, although it gets selected in CGDC, I lose about 30% of my GDI rsources when this code is called.
I have checked using GDI usage and the number of sequential ( in memory ) pens I leak varies, but is between 450 and 470. I don't leak any brushes. Can anyone tell me what is going on ? I have experimented with deleteobject, etc., but the fact is I seem to do the same thing inside the class and outside, but inside works for brushes, not pens.
Thanks
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Modify your SafeSelect functions like this:
if (m_pOldPen!=NULL) SelectObject(m_pOldPen);
if (pPen!=NULL) m_pOldPen = SelectObject(pPen); else m_pOldPen=NULL;
return m_pOldPen;
Same for the brush version.
Now, if you are detaching the DC handle from the CDC base class, then your destructor is worthless, since the DC handle is gone.
The other problem is that I did not see a constructor for your CGDC class. Assuming that you're using the base CDC, then the DC handle is null, and SelectObject will either (a) do nothing (b) bomb (c) leak.
Just my $0.02
|
|
|
|
|
Thanks for the comment, but apart from the fact that I'd not yet checked for NULL 'incoming', I had tried doing it this way previously, tried it again with your code, and it still leaks pens like craazy, but not brushes.
Here is my constructor:
CGDC::CGDC(CDC* pDC /* = NULL */)
{
CreateCompatibleDC(pDC);
SetStretchBltMode(COLORONCOLOR);
m_pOldBitmap = NULL;
m_pOldBrush = NULL;
m_pOldPen = NULL;
m_pOldFont = NULL;
}
P.S. Why won't Code Project remember me under IE 4 ?
Christian
|
|
|
|
|
Heck it doesn't remember it under IE55 either.
I think I spotted your problem; it's in the loop:
for (int i=0;i<500;i++)
{
CPen pen;
pen.CreatePen(PS_SOLID, 1, RGB(0,0,0));
dc.SafeSelect(&pen);
/* Okay, here is the problem as I see it: the first time this is called, there is no pen to release, so the pen handle is selected into the device context, which basically takes ownership of it. Then your loop exits, and the CPen object is destroyed, taking the handle with it - but more than likly just a COPY of the handle, leaving the other one still selected into the device context, since it was never selected out. Then the 2nd time into the loop you create a new CPen, and then select it in, but you never got rid of the other one. */
}
I've never written code like this; I've always done it like, the scope of the function:
CPen *pOldPen = dc.SelectObject(&pen);
...dowhatever....
dc.SelectObject(pOldPen);
If I was going to attempt to re-write the SafeSelect, I would probably NOT do it like this (IMHO), but instead, make a helper class (or nested class) that does the need balanced SelectObject's on construct and destruct.
|
|
|
|
|
That is how I have done it in the past too, but what I do not understand is why recreating this process in my class works for brushes, but not pens.
If you follow my logic, I am doing the exact same thing in safeselect for brushes ( which work ) and pens ( which don't ) and the same thing as what I do externally ( which works ). I tried Deleteing whatever gets returned to me in SafeSelect, which does not leak, so I may think along those lines instead.
|
|
|
|
|
Actually, it's not really necessary to remember to reselect the original pens. All you need to do is use the SaveDC() and RestoreDC() functions at the beginning and end of your draw routines.
Unfortunately, it's hard to build these into your DC class because pens allocated on the stack might get destroyed before you DC class gets destroyed, and if those pens are currently selected, then you get a resource leak. You have to call RestoreDC() before the objects go out of scope.
|
|
|
|