wxWidgets is a free and open source cross-platform C++ framework for writing advanced GUI applications using native controls.

This is a follow-up of bug #18113.

The codec used for converting between wxString and const char* is wxConvLibc. This may not be appropriate for everyone.

This pull request is to enable the macro wxNO_UNSAFE_WXSTRING_CONV2 that, when set, disallows any implicit conversion to and from const char*. An encoding must always be indicated instead.

In order to let everything compile with and without the macro, all the inline strings must be converted from char to wchar_t.

Issue migrated from trac ticket # 10258

component: base | priority: normal | resolution: fixed | keywords: wxProcess wxExecute

2008-12-10 09:42:39: lmichalski (Lukasz Michalski) created the issue

wxEndProcessFDIOHandler::OnExceptionWaiting is called when child process exits and closes all its descriptors.

On recent linux kernels (I've tested 2.6.25 to 2.6.27) process descriptors are closed first, then process changes state from Running to 'On Hold' and remains in that state until waitpid is called.

If controlling pipe notification arrives before child process changed its state waitpid with WNOHANG flag returns 0.

In this case wxEndProcessFDIOHandler assumes that only pipe was closed and pretends that process exited.

Lack of subsequent waitpid() calls leaves child process in "On Hold" state forever.

My solution to this problem is to remove WNOHANG flag from wxEndProcessFDIOHandler::OnExceptionWaiting. This could possibly lock parent process if child will do something nasty to controlling pipe, but for now I don't see better solution to this.

Issue migrated from trac ticket # 14756

component: wxAui | priority: normal | resolution: wontfix | keywords: aui notebook dynamic

2012-10-17 22:22:50: mmacleod (Malcolm MacLeod) created the issue

Please find attached a patch containing all changes from the 'dynamic notebook' branch of AUI that I have been maintaining. While far from perfect at this point I think that it is time (and the pragmatic thing to do) to go ahead with this and then iron out the problems as they happen, with my work load and the huge amount of other patches coming in it is unlikely that a better opportunity will arise to do this merge and if we wait too much longer we risk it just becoming simply impossible. It is also crucial I think that this must make it into wxWidgets 3, and therefore 2.9.5 is the last opportunity for proper testing and stability fixes, so it makes sense to push this before 2.9.5

This patch regresses the following revisions that will have to be looked at again after merging (one of them overly critical I don't think): 72641 72627 71560

The following (minor) documentation patches will have to be looked at again and/or redone, I unfortunately don't have the time currently for this, but can try get around to it in the coming weeks after the merge, of course if anybody else wants to assist thats even better... 72686 72418 71907 71204 70807 70708 70691 70541 70248 70183 69280 69267 67428 67280 67279 66698 66670 66007 65096 64940

In addition to the above there are some small visual regressions in wxAuiNotebook art to look into, and probably also various other wxAuiNotebook regressions that will appear with more testing. The new functionality of course is also bound to have numerous bugs.

Issue migrated from trac ticket # 8945

component: wxAui | priority: normal | resolution: outdated | keywords: wxAuiDocMDI

2008-01-07 13:22:33: ru10 created the issue

Here is my patch for including Doc/View framework into wxAUI MDI concept.

I created the classes wxAuiDocMDIParent/ChildFrame which derives from the corresponding wxAuiMDI classes. I took back the wxDocMDI code and adapted it to the wxAui needs.

I thus added the files tabdocmdi.h/cpp and modified the VS project of wxAUI and wxWidgets to take them in care. I created a sample app but you should probably create de folder 'samples\auidocvwmdi' before applying the patch. Moreover, I created the related doc in tex format. The doc makes reference to the wxAuiMDI classes which do not exist at this time.

It seem to work fine under Windows XP sp2, I do not test it under other platforms.

I'm waiting for any remark, critic, idea...

This is my proposal for a simple HTTP request class which would allow modern HTTP and HTTP/s connections based on APIs provided by the operating system.

Please have a look at the interface file to see the complete documentation.

• Documentation Page
• Sample source code
• Test source code

Usage would look like this:

// Create the request object
wxObjectDataPtr<wxWebRequest> request(
    wxWebSession::GetDefault().CreateRequest("https://www.wxwidgets.org/downloads/logos/blocks.png"));
// Bind events
request->Bind(wxEVT_WEBREQUEST_STATE, [](wxWebRequestEvent& evt) {
    switch (evt.GetState())
    {
        // Request completed
        case wxWebRequest::State_Completed:
        {
            wxImage logoImage(*evt->GetResponse()->GetStream());
            if (logoImage.IsOK())
                wxLogInfo("Image loaded");
            break;
        }
        // Request failed
        case wxWebRequest::State_Failed:
            wxLogError("Could not load logo: %s", evt.GetErrorDescription());
            break;
    }
});
// Start the request
request->Start();

As always any feedback is welcome. I don't have an ETA on when or if I would implement this, but I've experience with the proposed underlying APIs and it should be easy to get started.

Initial todo for a basic (but functional) implementation:

• [x] Interface Documentation
• [x] Finalize API
  • [x] Storage_File event params
  • [x] Storage_None event params
  • [x] Authentification params and event
• [x] Add generic wxCredentialEntryDialog
• [x] Sample application with common usage scenarios
• [x] WinHTTP implementation
• [ ] NSURLSession implementation
• [x] libcurl implementation
• [ ] Improve error handling

Further improvements in the future could be:

• More detailed connection options (timeouts, TLS versions, insecure HTTPs, etc)
• Use Vista+ CredUIPromptForWindowsCredentialsW for wxCredentialEntryDialog

The following APIs would be used:

Sample App Screenshots

This PR makes wxWidgets Per-Monitor DPI-Aware on Windows.

Per-Monitor DPI support is added for standard (GDI-based) Windows controls and controls drawn using wxDC*. Other objects, like wxBitmap, wxImage, wxDC*, wxGraphicsContext, wxGLCanvas and any other image/drawing related controls are not affected.
_{*The font in wxDC based controls will change if it has an associated wxWindow, anything else (e.g. line width) is based on the DPI of the main monitor.}

In short, it works as follows:

• When a new top-level window is created:
  • Check if the process is Per-Monitor DPI-Aware, and if so:
  • Determine active DPI.
  • Adjust the PPI of the fonts to the new DPI.
• React to WM_DPICHANGED events:
  • Invalidate sizes of the window and all its (non-top-level) children.
  • Call MSWUpdateFontOnDPIChange which will adjust the PPI of the wxFont to the new DPI. This function can be overridden by classes implementing wxWindow to do their own DPI specific handling.
  • Generate the new wxDPIChangedEvent to inform application.
  • Change the window size to the new size suggested by WM_DPICHANGED.
• Let FromDIP(), ToDIP() and GetContentScaleFactor() use the active DPI of the window.

It is usable with Windows 10 Creators Update (build 1703) or later, as it correctly scales Checkboxes, RadioButtons and other native GUI items, and all non-client areas (blog).

To use it, add <dpiAwareness>PerMonitorV2</dpiAwareness> to the manifest. This option is currently not available directly in Visual Studio. Move (a dialog of) the application to a monitor with a different DPI, or change the DPI of the current monitor, and voilà.

 build/cmake/functions.cmake | 1 +
 samples/dpi.manifest        | 8 ++++++++
 2 files changed, 9 insertions(+)

diff --git a/build/cmake/functions.cmake b/build/cmake/functions.cmake
index 6e0e528c0d..7397b62780 100644
--- a/build/cmake/functions.cmake
+++ b/build/cmake/functions.cmake
@@ -622,6 +622,7 @@ function(wx_add_sample name)
             # Include default sample.rc
             list(APPEND src_files ${wxSOURCE_DIR}/samples/sample.rc)
         endif()
+        list(APPEND src_files ${wxSOURCE_DIR}/samples/dpi.manifest)
     elseif(APPLE AND NOT IPHONE)
         list(APPEND src_files ${wxSOURCE_DIR}/src/osx/carbon/wxmac.icns)
     endif()
diff --git a/samples/dpi.manifest b/samples/dpi.manifest
new file mode 100644
index 0000000000..5891f961eb
--- /dev/null
+++ b/samples/dpi.manifest
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
+  <asmv3:application>
+    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
+      <dpiAwareness>PerMonitorV2</dpiAwareness>
+    </asmv3:windowsSettings>
+  </asmv3:application>
+</assembly>

The table in the collapsed panel below shows the results of the wxWidgets components tested for Per-Monitor DPI-Awareness.

Issue migrated from trac ticket # 15589

component: wxOSX | priority: normal | resolution: fixed

2013-10-17 11:07:04: rocrail (Rob Versluis) created the issue

I can run the minimal example on Mac OS X 10.9 Mavericks. But after compiling my own application, which runs OK on Mac OS X 10.8 Mountain Lion, it crashes. How can I fix this problem in my application?

• thread #1: tid # 0x18d54, 0x00007fff889c108a libstdc++.6.dylibstd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_grab(std::allocator<wchar_t> const&, std::allocator<wchar_t> const&) + 4, queue'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x76fffffffc) frame #0: 0x00007fff889c108a libstdc++.6.dylibstd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_grab(std::allocator<wchar_t> const&, std::allocator<wchar_t> const&) + 4 frame #1: 0x00007fff889c1656 libstdc++.6.dylibstd::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) + 32 frame #2: 0x0000000100b47f24 libwx_osx_cocoau-3.0.dylibwxLog::IsLevelEnabled(unsigned long, wxString) + 84 frame #3: 0x0000000100bf6afd libwx_osx_cocoau-3.0.dylibwxCSConv::DoCreate() const + 61 frame #4: 0x0000000100bf8dea libwx_osx_cocoau-3.0.dylibwxGet_wxConvLocalPtr() + 106 frame #5: 0x0000000100bfa9f3 libwx_osx_cocoau-3.0.dylib_GLOBAL__I_a + 419 frame #6: 0x00007fff5fc11c2e dyldImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 268 frame #7: 0x00007fff5fc11dba dyldImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40 frame #8: 0x00007fff5fc0ea62 dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 308 frame #9: 0x00007fff5fc0e9eb dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 189 frame #10: 0x00007fff5fc0e8f6 dyldImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 54 frame #11: 0x00007fff5fc021da dylddyld::initializeMainExecutable() + 189 frame #12: 0x00007fff5fc05560 dylddyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2419 frame #13: 0x00007fff5fc0127b dylddyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 477 frame #14: 0x00007fff5fc0105e dyld_dyld_start + 54

Issue migrated from trac ticket # 17623

component: base | priority: low | resolution: fixed | keywords: work-needed

2016-08-10 11:28:32: tambre (Raul Tambre) created the issue

Whenever a class is derived from a class for which events can be bound and the inheritance of the class is either private or protected, the Bind() fails with a compile-time error about the conversion to wxEvtHandler* being inaccessible.

The error message on MSVC14 is as follows:

wxWidgets\include\wx/meta/convertible.h(31): error C2243: 'type cast': conversion from 'Test *' to 'wxEvtHandler *' exists, but is inaccessible
  wxWidgets\include\wx/event.h(335): note: see reference to class template instantiation 'wxConvertibleTo<Class,wxEvtHandler>' being compiled
          with
          [
              Class=Test
          ]
  wxWidgets\include\wx/event.h(3568): note: see reference to class template instantiation 'wxEventFunctorMethod<EventTag,Test,EventArg,EventHandler>' being compiled
          with
          [
              EventTag=wxEventTypeTag<wxSizeEvent>,
              EventArg=wxSizeEvent,
              EventHandler=Test
          ]
  Test.cpp(78): note: see reference to function template instantiation 'void wxEvtHandler::Bind<wxEventTypeTag<wxSizeEvent>,Test,wxSizeEvent,Test>(const EventTag &,void (__cdecl Test::* )(EventArg &),EventHandler *,int,int,wxObject *)' being compiled
          with
          [
              EventTag=wxEventTypeTag<wxSizeEvent>,
              EventArg=wxSizeEvent,
              EventHandler=Test
          ]

The issue was discovered as a bug in this SO question: http://stackoverflow.com/questions/38833116/conversion-in-derived-class-inaccessible-if-base-class-is-protected

The error is caused by the wxConvertibleTo template incorrectly not detecting that protected and private inheritance is also fine.

I have attached a minimal sample and a patch for C++11 versions. I would like to get the patch merged, but I'm guessing it would likely require making it work with the ancient compilers wxWidgets supports.

Issue migrated from trac ticket # 8690

priority: normal

2007-07-29 18:18:30: xeee created the issue

This patch renames the existing wxFileCtrl to wxFileList(I think it's a proper name, it just displays a file list and it's even inherited from wxListCtrl) and adds the new generic wxFileCtrl to the current trunk along with its latex docs and a page in widgets sample for the new control. The only part that is not very ready is the sample, but the control itself and its docs are fine, I'm working on the sample right now and I'll send a newer version soon.

Issue migrated from trac ticket # 14403

component: wxMSW | priority: normal | resolution: fixed | keywords: DrawBitmap alpha

2012-06-15 11:55:08: GP89 (Paul) created the issue

Link to question on wxpython user list: [https://groups.google.com/forum/?fromgroups#!topic/wxpython-users/Iqtjj37sxXo ]

I'm experiencing a weird problem on windows where I create a bitmap in a memory dc, but if I try and draw a bitmap onto it with DrawBitmap I lose everything else in the image.

As Robin pointed out in my post the issue can be fixed by setting the banner_bmp image to use a bit depth of 24

I've attached a sample showing the issue and the bitmap in question (although other pngs I've tried all have the same effect)

windows 7 64bit, python 2.7.3 32bit, wx 2.8.12.1 (msw-unicode)

Issue migrated from trac ticket # 10660

component: base | priority: high | resolution: fixed | keywords: _T() macro-conflict suncc

2009-03-30 11:02:31: jroemmler (Jochen Roemmler) created the issue

Hi, I'm compiling and using wxWidgets library in various versions and platforms on a number of different machines. Lately, I came across a serious problem with macro _T which is defined in wxWidgets header files (see [http://docs.wxwidgets.org/stable/wx_stringfunctions.html#underscoret]). A simple "program" like this won't compile any longer:

// file bad.cpp
#include <wx/wx.h>

# /opt/SUNWspro/bin/CC -V
CC: Sun C++ 5.8 Patch 121018-18 2009/02/25
# /opt/SUNWspro/bin/CC -I/usr/local/wxWidgets-2.6.3/build_Motif_CC_shared/lib/wx/include/motif-ansi-release-2.6 -I/usr/local/wxWidgets-2.6.3/include -I/usr/local/wxWidgets-2.6.3/contrib/include -D__WXMOTIF__ -I/usr/openwin/include -I/usr/dt/include -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -xarch=amd64 -o /dev/null -c bad.cpp
"/opt/SUNWspro/prod/include/CC/Cstd/./memory", line 107: Error: Type name expected instead of "{".
"/opt/SUNWspro/prod/include/CC/Cstd/./string", line 850:     Where: While specializing "__rwstd::__rw_basis<__rwstd::_T, __rwstd::_Base>".
"/opt/SUNWspro/prod/include/CC/Cstd/./string", line 850:     Where: Specialized in std::string .
"/opt/SUNWspro/prod/include/CC/Cstd/./stdexcept", line 65:     Where: Specialized in non-template code.

The problem is because _T is also used in template code by latest Sun Studio (11 and 12) STL header files (see my posting here: [http://forums.sun.com/thread.jspa?threadID=5376645]). I think using names with underscore-prefix in (public) header files is definitely a bad idea.

My suggestion for wxWidgets 3.0 would be to break source code compatibility and get rid of _T() (and _() while we're at it); using existing wxT() instead is a simple search'n'replace operation - or making it a #define like so:

#ifdef wxUSE_DEPRECATED_T_MACRO #define T ... #else do not define _T because it may lead to name clashes in user code _ or STL compiler header files. #endif

What do you think? Jochen

Description

I was expecting to find wxrc.exe in the msvc dev packages. Issue #18124 requested this to be added, and it was closed with a fix, but wxrc.exe does not appear to be in the msvc dev packages. I downloaded wxMSW-3.2.1_vc14x_x64_Dev.7z and it was not there. I also downloaded a few earlier versions and it didn't seem to be in any of them. It is however in wxMSW-3.2.1_gcc1220_x64_Dev.7z

As mentioned in this comment, neither WGL_SAMPLE_BUFFERS_ARB nor WGL_SAMPLES_ARB seem to be supported by VMware OpenGL driver, meaning that creating OpenGL window fails by default inside the VM.

This PR updates Scintilla to 5.0.0, and adds Lexilla 5.0.1.

I replaced c++17 features, so it can be built with c++14 compilers. And another commit to replace c++14 features with c++11, if this will be the maximum c++ version that wxWidgets will support.

This might be the moment to move the Scintilla and Lexilla sources to submodules. Lexilla's upstream is on GitHub. But Scintilla is using Mercurial at Source Forge, so we would have to maintain that ourselves.

@eranif This should also fix #23080

SCI_SETLEXER, SCI_SETLEXERLANGUAGE and SCI_LOADLEXERLIBRARY have been removed from Scintilla, I reimplemented them using the new API

The xcode and msvc projects have not yet been updated.

Description

When MacOS system is set to use English as its language and a region that is not provided by the locale database (e.g. Germany), calling wxLocale::Init( wxLANGUAGE_DEFAULT ) will attempt to set the language to en_DE even though this language does not exist.

Expected behavior

According to the documentation,

    wxLANGUAGE_DEFAULT has special meaning: best suitable translation,
    given user's preference and available translations, will be used.

I would expect that if the language/region combination does not exist that the first available matching language would be used regardless of region. If no matching language is available, I would expect that the base translation (usually english) would be used.

I would never expect that we would see an error message when setting the locale to wxLANGUAGE_DEFAULT

To Reproduce

Set language and region like the following:

Then run intltest.cpp and set the language to wxLANGUAGE_DEFAULT

Platform and version information

• wxWidgets version you use: wxWidgets: 3.2.1 (wchar_t,wx containers)
• wxWidgets port you use: wxOSX
• OS and its version: macOS Ventura Version 13.1 (Build 22C65)

Such functions modifying errno is undocumented, and may come as a surprise to the caller. Consequently also a call to wxString::Format() would modify errno.

Steps to reproduce (tested on macOS):

--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -120,6 +120,10 @@ bool MyApp::OnInit()
     if ( !wxApp::OnInit() )
         return false;

+    fopen("asdfg", "r");
+    wxString::Format("aaaaaa");
+    wxLogMessage(wxSysErrorMsgStr());
+
     // create the main application window
     MyFrame *frame = new MyFrame("Minimal wxWidgets App");

This code would produce a log message Unspecified error: 0 or similar. If the line with wxString::Format is commented out, the log message becomes No such file or file or directory.

The current behavior is not wrong either per se, and the error code/message should have been read as soon as possible, which is not what this code sample does. But many would not think of wxString::Format as the kind of call that would cause a system error on failure, nor cause the system error to be reset on a successful call.