Hi,
I think the result of the discussion is clear. We don't have a generic
solution for the virtual methods GetFocus/LoseFocus.
A short explanation why I thought that IsVisible() can be a solution for
most of the scenarios. I thought that the dialogs/windows are hidden by
the code which is
Mathias Bauer wrote:
Philipp Lohmann - Sun Germany wrote:
That is as correct as useless. :-)
Ok, you win. Excuse my being alive. ;-)
If anybody has a better idea that can prevent the occurence of our bug
by fixing something in VCL please let us know. This would save us the
investigation and
Hi Carsten,
we have just found a nasty pitfall in one of our tab pages, which lead
to memory corruption. We needed about one week to track down this issue,
so I hope that someone else can profit from our findings.
...
If one uses the virtual methods at the Window class
virtual void
SomeWindow::SomeWindow()
{
DELETEZ( m_pBar );
DELETEZ( m_pFoo );
// note: less obvious versions of this use a
// ::std::auto_ptr Control for both m_pFoo and m_pBar, which makes
// the issue harder to spot
}
should have been SomeWindow::~SomeWindow, of course
Ciao
Frank
--
-
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Carsten,
we have just found a nasty pitfall in one of our tab pages, which lead
to memory corruption. We needed about one week to track down this issue,
so I hope that someone else can profit from our findings.
...
If one uses the
Hi Philipp,
This is based on the fact that the Window destructor does a Hide()
before setting the focus to somewhere else.
But this won't help. Window::~Window has not yet been called. In
Carsten's example, MyTabPage::~MyTabPage is just being called, and it's
just about to destroy its
Frank Schönheit - Sun Microsystems Germany wrote:
There is even a event listener mechanism for dying windows.
Which also doesn't help, since it's also triggered from Window::~Window
only - which is too late, since a lot of destruction already happens
before this in the derived class.
Philipp Lohmann - Sun Germany wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
There is even a event listener mechanism for dying windows.
Which also doesn't help, since it's also triggered from Window::~Window
only - which is too late, since a lot of destruction already happens
Mathias Bauer wrote:
Philipp Lohmann - Sun Germany wrote:
You overlook an important detail: the problem happens before any such
notification could have been sent and Frank obvisouly tried to explain that.
The case Carsten mentioned was a control implementing :GetFocus and in
there
Hi Philipp,
Bullshit. The object dying notifies you that it gets destroyed and you
still cannot refrain from using it ? Maybe that's just me, but i would
call THAT a destructive attitude ;-)
Mathias already explained that you got me wrong here - in the scenario I
described, there was no
Philipp Lohmann - Sun Germany wrote:
Mathias Bauer wrote:
Philipp Lohmann - Sun Germany wrote:
You overlook an important detail: the problem happens before any such
notification could have been sent and Frank obvisouly tried to explain that.
The case Carsten mentioned was a control
Frank Schönheit - Sun Microsystems Germany wrote:
No. The MyTabPage implemented a handler for the GetFocus event of one of
its children. Please examine the original example more carefully ;)
Point taken.
The other case you mention has nothing to do with
derivatives of Window at all; of
Hi,
we have just found a nasty pitfall in one of our tab pages, which lead
to memory corruption. We needed about one week to track down this issue,
so I hope that someone else can profit from our findings.
The following code snippet shows the root cause of the issue:
//
13 matches
Mail list logo
