lmi
[Top][All Lists]
Advanced

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

[lmi] Upgrading wx: ellipsis buttons, and wxUSE_STACKWALKER


From: Greg Chicares
Subject: [lmi] Upgrading wx: ellipsis buttons, and wxUSE_STACKWALKER
Date: Thu, 9 Jun 2016 10:20:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

Using wx with commit c4d06e8117f8930b57bffaf6a3323007c9df8d4b
I find that wx builds but lmi fails here:

/lmi/src/lmi/wx_checks.cpp:76:9: error: #error Disable wxUSE_STACKWALKER in wx s
 #       error Disable wxUSE_STACKWALKER in wx setup.
         ^

Here is the error directive in lmi's 'wx_checks.cpp':

#if defined __GNUC__ && defined LMI_MSW
// Not yet implemented for gcc on the msw platform.
#   if wxUSE_ON_FATAL_EXCEPTION
#       error Disable wxUSE_ON_FATAL_EXCEPTION in wx setup.
#   endif // wxUSE_ON_FATAL_EXCEPTION
// Not yet implemented for gcc on the msw platform.
#   if wxUSE_STACKWALKER
#       error Disable wxUSE_STACKWALKER in wx setup.
#   endif // wxUSE_STACKWALKER
#endif // defined __GNUC__ && defined LMI_MSW

I think the compiler message quoted above means that either
  (1) that error directive is no longer needed and should be removed, or
  (2) wx/configure is mistaken
Assuming (1) because wx/configure performs feature tests, I suppressed
the error directive; then lmi builds and seems to work, and (as we've
been discussing offline while trading screenshots) this makes the
ellipsis buttons for input sequences exactly the same, pixel for pixel,
as the similar buttons for file- and directory-picker controls (thanks).

I have two categories of questions:

(A) Between the text control and the ellipsis buttons I count one pixel
of spacing for input sequences, and ten for the picker controls. To make
them appear perfectly identical, could we change input sequences to use
the same spacing?

(B1) What's going on with wxUSE_STACKWALKER? I'm not sure we really know
that it works unless we cause lmi to crash. Or does wx/configure test
that so thoroughly that we can safely assume it must work?

(B2) I didn't observe this compile-time error with exactly the same
compiler version and a four-month-old wx version; has wx/configure's
test been improved so that it now detects a compiler feature that it
previously didn't detect?

(B3) If wxUSE_STACKWALKER is now okay, then is wxUSE_ON_FATAL_EXCEPTION
also now okay? I assume the answer must be "no", the reason being that
these are distinct features (and wxUSE_ON_FATAL_EXCEPTION probably needs
SEH, which MinGW-w64 32-bit tools don't provide).



reply via email to

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