Menu
▾
▴
[Pythoncard-cvs] PythonCard/docs/html sidebar.php,1.3,1.4 walkthrough3.html,1.7,1.8
|
From: Kevin A. <ka...@us...> - 2004-09-18 16:56:19
|
Update of /cvsroot/pythoncard/PythonCard/docs/html In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31788 Modified Files: sidebar.php walkthrough3.html Log Message: updated sidebar with gmane archive updated walkthrough for release 0.8 Index: walkthrough3.html =================================================================== RCS file: /cvsroot/pythoncard/PythonCard/docs/html/walkthrough3.html,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -d -r1.7 -r1.8 *** walkthrough3.html 26 Jul 2004 15:35:32 -0000 1.7 --- walkthrough3.html 18 Sep 2004 16:55:59 -0000 1.8 *************** *** 18,25 **** to help newcomers get started using PythonCard.</p> <h2>Overview, Scope and Purpose</h2> ! <p>This walkthrough covers PythonCard Version 0.6.7. Since PythonCard is ! still very much a prototype, you should expect that things will undoubtedly ! evolve over the next few releases of the product before its 1.0 release some ! time before the end of 2002.</p> <p>The first two PythonCard walkthrough tutorials (which can be found, like this one, in the docs/html directory of your PythonCard installation) --- 18,22 ---- to help newcomers get started using PythonCard.</p> <h2>Overview, Scope and Purpose</h2> ! <p>This walkthrough covers PythonCard Version 0.8.</p> <p>The first two PythonCard walkthrough tutorials (which can be found, like this one, in the docs/html directory of your PythonCard installation) *************** *** 27,31 **** to create applications with multiple windows. Adding another background as a child window will allow you to modularize your application. You can allow ! users to turn on and off windows (by using show()), and you can clean up your user interface and split widgets off into logical groups.</p> <p>In this walkthrough, we will extend our simple Counter application (the --- 24,28 ---- to create applications with multiple windows. Adding another background as a child window will allow you to modularize your application. You can allow ! users to hide and show windows (by using the visible attribute), and you can clean up your user interface and split widgets off into logical groups.</p> <p>In this walkthrough, we will extend our simple Counter application (the *************** *** 57,61 **** basically encapsulates a wxFrame and a wxPanel. Each PythonCard application is a class that derives from model.Background. You can't make a class derived ! from model.Background modal. That is a wxWindows limitation, not PythonCard. If you want a modal dialog then your class has to be derived from model.CustomDialog. They are similar, but different and the resource format --- 54,58 ---- basically encapsulates a wxFrame and a wxPanel. Each PythonCard application is a class that derives from model.Background. You can't make a class derived ! from model.Background modal. That is a wxWidgets limitation, not PythonCard. If you want a modal dialog then your class has to be derived from model.CustomDialog. They are similar, but different and the resource format *************** *** 117,128 **** <p>Next we'll add an event handler to be executed when the Counter application is started. This handler acts something like autoexec.bat on a PC or .login ! in a Unix shell. Place an on_openBackground handler right below the class definition. (Placement isn't important but following this convention will make it easier for you to work through and maintain multi-window applications.) Here is the class declaration of our Counter application with ! on_openBackground added:</p> <p class="code">class Counter(model.Background):<br /> ! def on_openBackground(self, event):</p> ! <p>and here is the code that we will add to the on_openBackgound method:</p> <p class="code"> self.minimalWindow = model.childWindow(self, minimal.Minimal)</p> <p>We create a minimal window object uisng the <span class="code">childWindow --- 114,125 ---- <p>Next we'll add an event handler to be executed when the Counter application is started. This handler acts something like autoexec.bat on a PC or .login ! in a Unix shell. Place an on_initialize handler right below the class definition. (Placement isn't important but following this convention will make it easier for you to work through and maintain multi-window applications.) Here is the class declaration of our Counter application with ! on_initialize added:</p> <p class="code">class Counter(model.Background):<br /> ! def on_initialize(self, event):</p> ! <p>and here is the code that we will add to the on_initialize method:</p> <p class="code"> self.minimalWindow = model.childWindow(self, minimal.Minimal)</p> <p>We create a minimal window object uisng the <span class="code">childWindow *************** *** 133,142 **** it is still hidden and not much good to us.</p> <h2>Communicating With Your Child Window</h2> ! <p>Continuing in the on_openBackground handler, we make calls to set the position and visibility of the new window:</p> <p class="code"> ! # override resource position ! self.minimalWindow.SetPosition((200, 5)) ! self.minimalWindow.Show()</p> <p>We now have a window that is an attribute of our main background, just like any of the menus or buttons that are already a part of Counter.</p> --- 130,139 ---- it is still hidden and not much good to us.</p> <h2>Communicating With Your Child Window</h2> ! <p>Continuing in the on_initialize handler, we make calls to set the position and visibility of the new window:</p> <p class="code"> ! # override resource position<br /> ! self.minimalWindow.position = (200, 5)<br /> ! self.minimalWindow.visible = True</p> <p>We now have a window that is an attribute of our main background, just like any of the menus or buttons that are already a part of Counter.</p> *************** *** 170,174 **** event handler directly. If you are interested in passing an arbitrary event such as a mouseClick, that will require creating the event and then posting ! it using wxPostEvent. Custom events are beyond the scope of this tutorial. However, the child window is able to access the parent window directly by traversing up the stack of windows.</p> --- 167,171 ---- event handler directly. If you are interested in passing an arbitrary event such as a mouseClick, that will require creating the event and then posting ! it using wx.PostEvent. Custom events are beyond the scope of this tutorial. However, the child window is able to access the parent window directly by traversing up the stack of windows.</p> *************** *** 178,189 **** minimal.py</p> <p class="code"> ! def on_openBackground(self, event):<br /> ! self.parent = self.GetParent()<br /> <br /> def on_btnReset_mouseClick(self, event): self.parent.components.field1.text = "0"</p> ! <p>When our child window it initialized, it calls GetParent() to get a reference to its parent window, and then stores that reference. We place the ! code that handles this task in the on_openBackground handler so that the reference is available to all handlers in the application.</p> <p>You'll notice that the text field on the Counter background is reset to --- 175,186 ---- minimal.py</p> <p class="code"> ! def on_initialize(self, event):<br /> ! self.parent = self.getParent()<br /> <br /> def on_btnReset_mouseClick(self, event): self.parent.components.field1.text = "0"</p> ! <p>When our child window it initialized, it calls getParent() to get a reference to its parent window, and then stores that reference. We place the ! code that handles this task in the on_initialize handler so that the reference is available to all handlers in the application.</p> <p>You'll notice that the text field on the Counter background is reset to *************** *** 194,198 **** itself, self.parent is set to None. If you were using the child window in other roles or wanted to make it multi-purpose, you could place the ! self.GetParent() call in a try...except block.</p> <h2>Closing the Child Window</h2> <p>Your main application window will clean up the child window when your app --- 191,195 ---- itself, self.parent is set to None. If you were using the child window in other roles or wanted to make it multi-purpose, you could place the ! self.getParent() call in a try...except block.</p> <h2>Closing the Child Window</h2> <p>Your main application window will clean up the child window when your app *************** *** 207,211 **** <p>We do this by overriding the on_close event handler. on_close would normally destroy the window but we change it so it hides the window by ! calling the Show method with a parameter of zero, hiding the window. Just to make things a little more interesting, we've also added a custom doExit function that sets the counter's field1 to an arbitrary value just to confirm --- 204,208 ---- <p>We do this by overriding the on_close event handler. on_close would normally destroy the window but we change it so it hides the window by ! setting the visible attribute to False, hiding the window. Just to make things a little more interesting, we've also added a custom doExit function that sets the counter's field1 to an arbitrary value just to confirm *************** *** 217,228 **** def on_close(self, event):<br /> self.doExit()<br /> ! self.Show(0)<br /> <br /> def on_menuFileExit_select(self, event):<br /> ! self.Close() </p> <p>As the above code shows, the File->Exit menu item just calls the ! wxPython method Close() to close the window. (This is one of the wxPython ! events that PythonCard does not yet wrap in its own calls, so we have to make ! the call directly to the wxPython method.) That is the same as clicking the close box on the window and triggers the close window event, so that on_close is called. We placed the work to be done when the document is closing in the --- 214,223 ---- def on_close(self, event):<br /> self.doExit()<br /> ! self.visible = False<br /> <br /> def on_menuFileExit_select(self, event):<br /> ! self.close() </p> <p>As the above code shows, the File->Exit menu item just calls the ! close() to close the window. That is the same as clicking the close box on the window and triggers the close window event, so that on_close is called. We placed the work to be done when the document is closing in the *************** *** 235,239 **** the parent. The code would look something like this:</p> <p class="code"> ! self.parent.menuBar.setChecked('menuViewMinimalWindow', 0)</p> <?php include "footer.php" ?> <p>$Revision$ : $Author$ : Last update $Date$</p> --- 230,234 ---- the parent. The code would look something like this:</p> <p class="code"> ! self.parent.menuBar.setChecked('menuViewMinimalWindow', False)</p> <?php include "footer.php" ?> <p>$Revision$ : $Author$ : Last update $Date$</p> Index: sidebar.php =================================================================== RCS file: /cvsroot/pythoncard/PythonCard/docs/html/sidebar.php,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** sidebar.php 14 Aug 2004 21:15:21 -0000 1.3 --- sidebar.php 18 Sep 2004 16:55:58 -0000 1.4 *************** *** 21,24 **** --- 21,25 ---- <li><a href="http://lists.sourceforge.net/lists/listinfo/pythoncard-users">Mailing list</a></li> <li> <a href="http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/PythonCard">Archive @ ASPN</a></li> + <li> <a href="http://news.gmane.org/gmane.comp.python.pythoncard">Archive @ gmane</a></li> <li> <a href="http://sourceforge.net/mailarchive/forum.php?forum=pythoncard-users">Archive @ SF</a></li> <li><a href="/samples/samples.html">Samples (screenshots)</a></li> |
