Language Bindings

Thank you guys for your answers!

I solved this by adding two lines (for sure it works, but is it OK?:):

@# -- coding: utf-8 --
from PyQt4 import QtCore, QtGui
from start_window import Ui_Form
from second_window import Ui_Form as Ui_Form_Second

class StartForm(QtGui.QWidget):
def init(self, parent=None):
QtGui.QWidget.init(self, parent)
self.ui = Ui_Form()
self.ui.setupUi(self)
self.child_windows = None # this one
self.ui.pushButton.clicked.connect(self.button)

def button(self): secondWindow = SecondForm() secondWindow.show() self.child_windows = secondWindow # this one self.hide()

class SecondForm(QtGui.QWidget):
def init(self, parent=None):
QtGui.QWidget.init(self, parent)
self.ui = Ui_Form_Second()
self.ui.setupUi(self)

if name == "main":
app = QtGui.QApplication(sys.argv)
myapp = StartForm()
myapp.show()
sys.exit(app.exec_())@

I am just wondering if this approach doesn't leave any garbages in memory, like closed forms?

I ma not using QWizard because this is going to be something more than widget with "Next" and "Previous" buttons. Nor QStackedWidget since, at some point, I want to have more than one visible widget at a time.

Can someone tell what to do after cloning? How to build the documentation?

Then maybe layoutChanged would be more appropriated

It's not on the model, it's on the QTableView.

You have to code the connection yourself e.g. in your widget constructor

Hi,

I've never combined .NET with Qt before, but have a look at http://qt-project.org/doc/qt-5.1/activeqt/activeqt-index.html -- all the ActiveQt documentation can be reached through there.

In particular, try:
http://qt-project.org/doc/qt-5.1/activeqt/qaxwidget.html
http://qt-project.org/doc/qt-5.1/activeqt/activeqt-dotnet.html

For what is worth this issue seems to be solved after upgrading to PySide 1.2.1.

Just for future reference to anyone who runs across this I ended up going with my current solution. QGraphicsScene is very optimized and seems to do a good job of not bothering with redrawing obscured objects. This approach also allowed me to do some other things visually that would have been much more difficult to implement otherwise.

Hi,

Did you follow the "deployment documentation":http://qt-project.org/doc/qt-4.8/deployment-windows.html ?

you'd better not move it.Each time when you run your program ,the current folder is always the one that the start file lives in.

ok, SGaits thanks for your explanation

I followed the "UncleZio" suggestions

ciaooo

What do you want to wrap?

I concur with you that the errors are harmless to the install. Its an open source project: it is low priority for them to port the examples to Python 3. I don't know how to read the install scripts to know whether the success of the installation is conditional on successful interpretation by Python 3 of the examples. Probably not, since you will find whether the install was successful soon enough as you try PySide with your real code. Your post is good to know (for others who will be trying Python3 soon) but I wouldn't file a bug report, the PySide project probably knows already.

I can confirm that the QPrintDialog used as above does work (whereas modally it did not) on Qt 4.8.2(?). So my question is now academic, about how Qt signals in PySide would bind the string parameter to QPrintDialog.open() to a method.

Also, in OSX, the dialog appears hung down off the mainwindow title bar, and IS non-modal in the sense that the app still gets events in the main window that is not obscured by the print dialog. So now I need to read up on whether the fact that the dialog will not go behind the main window, or say off to the side, is a feature of OSX in general for all non-modal dialogs, or just a feature of their native print dialog. If I open a second non-modal dialog (but not a native OSX dialog), where will it appear?

Can you say that as far as Qt is concerned, the dialog is non-modal, but as a native OSX dialog, it has a restricted sense of non-modal? Is there another word for such behaviour, such as pull-down dialog, or tear-off (I'm not sure it will tear off?)

My original attempt to make the dialog modal is laziness? Now I must test that anything the user does while the print dialog is open has no harmful effect. Including testing that if the user asks to print again, another print dialog should not open.