Blank lines in console after using wxFileDialog on Windows

Newbie Help
#1

I want to make an existing CLI application more user friendly with wxPython FileDialog. But on several machines running Windows 7, the console is slowly filled with blank lines (say: one line every minute - didn’t measure precisely) after a FileDialog has been created.

Below is a small piece of code that triggers the problem:

import msvcrt
import wx

if __name__ == '__main__':
    print("Starting...")
    app = wx.App()
    openFileDialog = wx.FileDialog(None, message="Open a .tiff image", defaultFile="", wildcard="Tiff images (*.tiff)|*.tiff", style=wx.FD_OPEN | wx.DIALOG_NO_PARENT)

    # after the call to ShowModal, extra lines in the console output appear every x seconds.
    # Destroying the dialog or App does not solve the problem

    print("Showing openFileDialog...")
    openFileDialog.ShowModal()
    print("Destroying openFileDialog...")
    openFileDialog.Destroy()
    openFileDialog = None
    app.Destroy()
    app = None

    msvcrt.getch()
    print("Exiting...")

Tested on 2 machines running Windows 10, and everything works just fine.
I’ve tried capturing sys.stdout, but the blank lines still appear. Capturing stdout via the file descriptor (https://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-python/) does work: the blank lines no longer appear.

So on this Windows 7 computer, something writes blank lines to the stdout file descriptor after a FileDialog has been created.

Is this a known problem ? Any ideas / tips on how to debug this ?

  • Windows 7
  • Python 3.7, 64-bit
  • wxPython installed via pip
#2

I haven’t been able to replicate this. Does it make any difference if you don’t import or use msvcrt and use Python’s input() instead?

#3

The problem still occurs with input(). And I’ve seen originally the problem in an application using Matplotlib to show some plots interactively.

I assume that destroying the FileDialog and App releases all wxPython resources. Yet, the blank lines still appear. So creating the FileDialog might just act as a trigger.

Another observation: when capturing stdout via the file descriptor and checking the output, the blank lines all appear at the beginning, followed by the regular sys.stdout output. So this looks like the offending code doesn’t use Python I/O, but directly accesses the file descriptor (the problem might be in a C library).

Script used for this test (and I’ve waited some time before pressing enter to quit):

import wx
import time

if __name__ == '__main__':
    print("Starting...")
    app = wx.App()
    openFileDialog = wx.FileDialog(None, message="Open a .tiff image", defaultFile="", wildcard="Tiff images (*.tiff)|*.tiff", style=wx.FD_OPEN | wx.DIALOG_NO_PARENT)

    # after the call to ShowModal, extra lines in the console output appear every x seconds.
    # Destroying the dialog does not solve the problem

    print("Showing openFileDialog...")
    openFileDialog.ShowModal()
    print("Destroying openFileDialog...")
    openFileDialog.Destroy()
    openFileDialog = None
    app.Destroy()
    app = None

    print("Sleeping...")
    time.sleep(120)

    print("Waiting for <enter>...")
    input()
    print("Exiting...")

and the output

Starting...
Showing openFileDialog...


Destroying openFileDialog...
Sleeping...








Waiting for <enter>...





Exiting...
#4

I’m still unable to replicate this. I tried with multiple Windows VMs and versions of wxPython.

Do you have something else installed on the system that may have hooked into the Windows message queues that might be trying to monitor or interact with all running applications in some way? Since your application is not responding to Windows messages at that point in time (neither the MainLoop nor ShowModal are running) then perhaps some other thing is trying to prod or wake up your app by writing to its stdio pipes…

#5

One step further. Indeed, it is another application that causes the problem. This occurs on some corporate machines with several tools preinstalled. I’ve disabled the Windows service for “Druva inSync”, a tool for on-line backup, and the problem is gone.

ApiMon revealed some calls to WriteFile from “insyncce.dll”, a DLL that is injected in Python. At this point I’m not sure if it is wxPython specifically that triggers this issue, or more in general the Windows FileDialog. But it is a bug in Druva anyway.

#6

The problem is not caused by wxPython, 100% sure now. Sorry for wasting your time.

I’ve created a similar version with PyQt. When using the native file dialog, the problem occurs there too. When using a non-native file dialog, the problem does not occur.

So everything is pointing to Druva inSync trying to inject itself in applications using the Windows file dialog, and accidentally causing extra output on stdout.

#7

I have a fix from Druva - we sat down and debugged this last month.

  • Kill all inSync* processes via the ‘Details’ tab of task manager (including inSyncAgent.exe)
  • Open an elevated CMD window and browse to C:\Program Files (x86)\Druva\inSync\amd64
  • Run the following command: regsvr32 /u insyncse.dll
  • Note: ignore the error popup simply click ok
  • If it doesn’t start automatically, start the inSyncCPHService service.

Druva are now aware of the problem and it should be fixed in future versions. The above only needs to be done once for a permanent fix.

Tested with Druva inSync 6.9.0 r110050