On Fri, 9 Sep 2005 15:09:24 -0400
"Dimi Paun" <[EMAIL PROTECTED]> wrote:
> From: "Phil Krylov" <[EMAIL PROTECTED]>
> > OK, should we then make a patch which adds an IsWindow() check after every
> > notification in every control? This one fixes a really annoying bug, while
> > the other places are
From: "Phil Krylov" <[EMAIL PROTECTED]>
> OK, should we then make a patch which adds an IsWindow() check after every
> notification in every control? This one fixes a really annoying bug, while
> the other places are not proved to crash.
Well, if it's a entire class of bugs, we should fix them all
On Fri, 9 Sep 2005 13:59:05 -0400
"Dimi Paun" <[EMAIL PROTECTED]> wrote:
> From: "Phil Krylov" <[EMAIL PROTECTED]>
> > Here is a patch which adds checking if the window has been destroyed at
> > that point. I don't know if it is acceptable but it fixes the problem.
>
> But this could potentially
From: "Phil Krylov" <[EMAIL PROTECTED]>
> Here is a patch which adds checking if the window has been destroyed at
> that point. I don't know if it is acceptable but it fixes the problem.
But this could potentially happen on any notification,
what makes this particular one special (sorry, I was awa
Phil Krylov wrote:
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
Wouldn't it be enough to call notify_click after notify_itemactivate? I've
attached a modification of your patch, which does just this. Seems to work
fine for me.
Probably, but what if s
Hello Dimi,
On Thursday 08 September 2005 23:37, Phil Krylov wrote:
> Michael Jung <[EMAIL PROTECTED]> wrote:
> > Wouldn't it be enough to call notify_click after notify_itemactivate?
> > I've attached a modification of your patch, which does just this. Seems
> > to work fine for me.
>
> Probably,
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> Wouldn't it be enough to call notify_click after notify_itemactivate? I've
> attached a modification of your patch, which does just this. Seems to work
> fine for me.
Probably, but what if some apps depend
Hi Phil,
On Thursday 08 September 2005 19:23, Phil Krylov wrote:
> * Every double click on a folder in the listview destroys this listview
> object (effectively destroying all underlying structures), creates a new
> one, and returns control to the place where double click notification was
>
On Fri, 26 Aug 2005 23:03:33 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> Every time you double click a folder, the current ShellView object is
> destroyed and a new one is created. Given that I have to browse into like 30
> different folders before it crashes on me, I can't pin down the rele
Duane Clark wrote:
As of the current CVS, the problem seems to have disappeared for me. It
is not clear to me what patch fixed it.
Oops, spoke too soon. Still there.
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the
Hi Michael,
2) Did other people see this bug already?
TextPad 4.5 broke just around the time when you checked in the patch. It
crashes at startup, the crash location is strange and has already
changed a few times when I updated the WINE source tree.
You can get TextPad 4.5 here:
ftp://ft
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the
On Monday 29 August 2005 18:09, Duane Clark wrote:
> I am seeing it now, using winecfg and browsing to "Add application..."
> in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the crash anyway?
Bye,
Phil Krylov wrote:
On Fri, 26 Aug 2005 22:10:16 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
2) Did other people see this bug already?
Yes, I confirm it.
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
On Fri, 26 Aug 2005 22:10:16 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> 2) Did other people see this bug already?
Yes, I confirm it.
-- Ph.
Hi,
On Fri, Aug 26, 2005 at 07:30:55PM -0700, Robert Shearman wrote:
> Andreas Mohr wrote:
> >In theory it's possible, but valgrind currently doesn't work with Wine any
> >more
> >(or rather the other way around), AFAIK.
> >
> >
>
> It used to as of a few months ago. Have you tried it recently
Andreas Mohr wrote:
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
3) Would valgrind be of help to debug this?
In theory it's possible, but valgrind currently doesn't work with Wine any more
(or rather the other way around), AFAIK.
It used to as of a few months
Hi,
On Fri, Aug 26, 2005 at 11:03:33PM +0200, Michael Jung wrote:
> Thanks for your comments. The problem is that things are really dynamic here.
> Every time you double click a folder, the current ShellView object is
> destroyed and a new one is created. Given that I have to browse into like 30
Hi Andy,
On Friday 26 August 2005 22:26, Andreas Mohr wrote:
> Why not use a watchpoint on that location?
> Choose some significant function call a while before the crash,
> have a breakpoint on that function (a DPA related function probably is
> best), check out which infoPtr is the relevant one,
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
> 1) Can someone give me some advice on how to debug such a problem?
Why not use a watchpoint on that location?
Choose some significant function call a while before the crash,
have a breakpoint on that function (a DPA related func
Hi,
Sometimes while browsing the unixfs namespace in the file dialog wine crashes
with the following console output:
=
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled e
22 matches
Mail list logo
