Recent Changes

All the functionality of PyQt’s model/view architecture is available to database programmers. In addition, the SQL table models’ APIs have been extended to make database programming easier. And when we need to execute raw SQL,we can easily do so using the QSqlQuery class.
We have now reached the point where you should be able to create any kind of GUI application you like, limited only by your imagination and the time available to you. In Part IV we will look at some additional topics that can be tricky to deal with, starting with more advanced material on model/view programming, then internationalization, then networking, and finishing up with multithreading.
*to know about MySQL in python,you can visit the following link:http://zetcode.com/databases/mysqlpythontutorial/
* the example that we study in this chapter is:phonelog.pyw

If we are not using testing tools, adding testing code that is executed only if the form is run stand-alone does not affect the performance of our dialogs, and can be very convenient both during development and when maintaining a dialog.If complex objects that the dialog depends on are not available, we can often create a “fake” class that provides the same method as the complex object, and pass an instance of the fake class for testing purposes.
All PyQt programs can be written entirely by hand; there is never any need to use Qt Designer. However, designing dialogs with a visual design tool can be very helpful, since the results can be seen immediately, and changes to designs can be made quickly and easily. Another benefit of using Qt Designer is that a lot of fairly repetitive code for creating, laying out, and connecting widgets can be automatically generated rather than written by hand. Qt Designerwas used to create a dialog in both this chapter,and the preceding one. We will see many more examples of dialogs created with Qt Designer in the following chapters.
*To know more about Qt_designer,you can visit the following link:http://www.cs.usfca.edu/~afedosov/qttut/

Another possibility is to avoid using a dialog at all and to allow the user to edit data in-place—for example, in a list or table. This approach is covered in the chapters on model/view programming.
*To know more about dialogs in python,you can visit the following link:http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html
this chapter are:signals.pywinterest.pywcurrency.pywconnections.pywcalculate.pywalert.pyware:pen.pywnumbers.pyw

It is possible to design a dialog so that it can be used both for adding and for editing items. These add/edit dialogs are no different from other kinds of dialogs when it comes to the creation, layout, and connection of their widgets.The key difference is that they may need to behave in different ways depending on whether they are adding or editing. When editing, the widgets are populated from the item passed in, and when adding, the widgets are populated with default values. If the dialog is accepted, it may simply provide accessors through which the values set can be retrieved, leaving the work to the caller, or it may be smart, able to update edited items directly, and to create new items if the user is adding.
Another possibility is to avoid using a dialog at all and to allow the user to edit data in-place—for example, in a list or table. This approach is covered in the chapters on model/view programming.
*To know more about dialogs in python,you can visit the following link:http://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html
*The examples we study in this chapter are:signals.pywinterest.pywcurrency.pywconnections.pywcalculate.pywalert.pyw