lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Ctrl-C in message box in Wine


From: Vadim Zeitlin
Subject: Re: [lmi] Ctrl-C in message box in Wine
Date: Fri, 3 May 2019 01:07:54 +0200

On Thu, 2 May 2019 21:58:43 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-05-02 15:12, Vadim Zeitlin wrote:
GC> > On Thu, 2 May 2019 01:20:24 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> BTW, in msw I could copy the contents of a messagebox with Ctrl-C
GC> > GC> or something, but that doesn't work in wine, so I have to transcribe
GC> > GC> diagnostics manually. Fixing wine sounds hard;
GC> > 
GC> >  It isn't really, I've had a look at dlls/user32/msgbox.c in Wine sources
GC> > and adding a handler for WM_CHAR/WM_KEYDOWN there seems pretty
GC> > straightforward. Of course, a patch doing this would take some time to be
GC> > accepted into Wine (assuming it is accepted) and propagate into Debian 
from
GC> > there, but maybe you could use your own build of Wine in the meanwhile?
GC> 
GC> If it's that easy, then would you send winehq a patch, please?

 Sure, >> TODO (BTW, I didn't forget about the Wine pipe handling slowdown
problem neither, but unfortunately it has proven even more intractable than
I thought, so I don't have much to report yet...).

GC> > GC> maybe the answer is to print a copy of any messagebox's contents on 
the
GC> > GC> console.
GC> > 
GC> >  We could use a custom wxMessageOutput object in lmi: from what I remember
GC> > you're somewhat allergic to wxLog, but wxMessageOutput is much more
GC> > straightforward and is really just a direct replacement for modal
GC> > wxMessageBox calls, so I hope this would be less controversial.
GC> 
GC> Please see the idea I've thrown together as an lmi patch below.

 Yes, this is even simpler and should work fine for our purposes. Logging
to the console is pretty unusual in the Windows world, but, as you say, end
users probably will never have an associated console anyhow. And we could
use OutputDebugString() (wrapped by wxWidgets as wxMessageOutputDebug) if
we wanted to ensure that normal users have no chance of seeing the output.
OTOH adding a new command-line option for enabling this doesn't seem like a
good idea because enabling this option before being confronted with an
error message box requires an unnatural degree of foresight, so I think in
practice it would just mean that you'd need to either copy the message box
by hand or run the program again and go through all the steps necessary for
reproducing the problem one more time, which looks like a waste of time.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]