Ask Your Question
1

Debugging Qt application

asked 2017-05-29 06:43:00 -0500

Amit's avatar

updated 2019-03-13 10:16:04 -0500

Hi, I am trying to debug an application that uses a Qt framework (enaml) which uses Qt API version 2. Once the debugging session starts I get the following error:

"ValueError: API 'QDate' has already been set to version 1"

The application runs correctly when lunched from the command line.

My guess is that wingide already sets the API version. Is it possible to change this behavior (I cannot change the API version that my application uses)?

Thanks,

Amit

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
1

answered 2017-06-04 17:49:00 -0500

Amit's avatar

updated 2019-03-07 07:19:31 -0500

Wingware Admin's avatar

Hi,

I am not using pyinstaller.

The problem occurs when matplotlib is imported before enaml (the qt framework I am using). The work around is to import enaml before matplotlib.

I compared both setups (command line and wingide). The only difference I found was that wingide injects the following environment variables:   'PYTHONIOENCODING', 'WINGDB_ACTIVE', 'WINGDB_PARENT_PIDS', 'WINGDB_SPAWNCOOKIE'   Thanks,

Amit

edit flag offensive delete link more

Comments

Ah, yes, that would explain it. If matplotlib is using the Qt backend then it would initialized PyQt first.  Thanks for posting the solution!

Wingware Support's avatar Wingware Support  ( 2017-06-05 08:37:00 -0500 )edit
0

answered 2017-05-29 10:34:00 -0500

updated 2019-03-07 07:19:15 -0500

Wingware Admin's avatar

Are you possibly using PyInstaller or something else that might account for this? Maybe the work-around described in https://github.com/pyinstaller/pyinst... will solve it?

Wing uses PyQt itself but other than possibly leaking an environment variable your debug process should not be in any way affected by this, since it runs in a separate process space.  I checked this just now and don't see any environment variable set that I think could cause this, so I am guessing that it's some other cause, but still worth a check by looking at os.environ in each case. 

Also take a look at compare sys.executable and sys.path to make sure the same are being used in each case.  You can alter those by setting/adding values in Project Properties.  If sys.executable is wrong, set that into Python Executable.  To add things to sys.path put them in Python Path.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2017-05-29 06:43:00 -0500

Seen: 1,415 times

Last updated: Mar 07 '19