wxpython-users Digest, Vol 12, Issue 26

The_Helmbolds · February 6, 2009, 4:38am

This is what I received

The Helmbolds
2645 E Southern Ave A241
Tempe AZ 85282
Email: helmrp@yahoo.com
VOX: 480-831-3611

···

From: “wxpython-users-request@lists.wxwidgets.org” wxpython-users-request@lists.wxwidgets.org
To: wxpython-users@lists.wxwidgets.org
Sent: Thursday, February 5, 2009 9:18:43 PM
Subject: wxpython-users Digest, Vol 12, Issue 26

Send wxpython-users mailing list submissions to wxpython-users@lists.wxwidgets.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.wxwidgets.org/mailman/listinfo/wxpython-users or, via email, send a message with subject or body ‘help’ to wxpython-users-request@lists.wxwidgets.org You can reach the person managing the list at wxpython-users-owner@lists.wxwidgets.org When replying, please edit your Subject line so it is more specific than “Re: Contents of wxpython-users digest…” Today’s Topics: 1.
Re: OS-X issue – raising minimized frame. (Christopher Barker) 2. Re: OS-X issue – raising minimized frame. (Phil Schloss) 3. Re: OS-X issue – raising minimized frame. (Kevin Ollivier) 4. problems with wx.ComboBox and wx.ToolTip (Vlastimil Brom) 5. Re: experiment with Grady class for staticTexts on a gradient (C M) ---------------------------------------------------------------------- Message: 1 Date: Thu, 05 Feb 2009 15:30:57 -0800 From: Christopher Barker Subject: Re: [wxpython-users] OS-X issue – raising minimized frame. To: wxpython-users@lists.wxwidgets.org Message-ID: 498B76B1.8080608@noaa.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cody Precord wrote: > > wrote: > I just tried this, and I’m getting close: > > in wx.App OnInit: > > self.Bind(wx.EVT_ACTIVATE_APP, self.OnActivate) > … > def OnActivate(self, event): > if
event.GetActive(): > self.frame.Raise() > event.Skip() > However, if I minimize the frame, then click on the app icon, I > don’t get an EVT_ACTIVATE_APP, so the frame doesn’t Raise(). If I > bring another app forward first, then it does work. > > I believe if a frame has been ‘iconized’ to the taskbar/dock you need to > call frame.Iconize(False) to bring it up from there, then call Raise to > make sure its the most forground frame. Just plain old Raise() seems to work fine. The issue at hand is that when the app is already the front app, then it doesn’t get a EVT_ACTIVATE_APP event when the dock icon is clicked, so I can’t bring the frame up. > Not sure if it should happen automatically or not, Well, it’s standard Mac behavior, including with a a wx App we wrote in C++, in which I don’t think we’ve done anything special at all – though I’m going to poke into that code to make sure. > but for example if > your app has
many frames open and minized to the dock, which one / all > should be raised from the dock when you click on the icon? well, usually when I click on the icon, ALL the apps non-iconized windows come forward. It appears that only one does when they are all iconized – Finder acts this way, for instance. As for wx – there is SetTopWindow / GetTopWindow which seems to be the solution as to what to bring forward. In the case at hand, we only have one Frame, so it’s a non-issue. By the way, Editra 0.3.80 has this same issue, though If I drag and drop a file onto the icon – the frame does get raised. Another note: I put the : if event.GetActive(): clause in, 'cause it seems to get an EVT_ACTIVATE_APP event when the frame is minimized, too. -Chris – Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov ------------------------------ Message: 2 Date: Thu, 05 Feb 2009 17:50:26 -0600 From: Phil Schloss Subject: Re: [wxpython-users] OS-X issue – raising minimized frame. To: wxpython-users@lists.wxwidgets.org ,wxpython-users@lists.wxwidgets.org Message-ID: 7.0.1.0.2.20090205173104.0221f2f8@red-castle.com Content-Type: text/plain; charset=“us-ascii” At 04:04 PM 2/5/2009, Cody Precord wrote: >Hello, > >On Thu, Feb 5, 2009 at 3:56 PM, Chris Barker >< Chris.Barker@noaa.gov> wrote: >Cody Precord wrote: > Chris Barker wrote: > We’ve found an odd OS-X issue. If I have an app with one frame, > and that frame is minimized to the dock, clicking on its icon on > the dock brings the app to the front (it gets the menubar), but > the frame stays minimized, so you can’t see it. > > >Have you tried seeing if your App gets an Activation event

‘EVT_ACTIVATE_APP’ when the doc icon is clicked on. If that is >recieved you should then be able to raise your frame to the >forground from there. > > >I just tried this, and I’m getting close: > >in wx.App OnInit: > >self.Bind(wx.EVT_ACTIVATE_APP, self.OnActivate) >… >def OnActivate(self, event): > if event.GetActive(): > self.frame.Raise() > event.Skip() > > >this mostly works. > >However, if I minimize the frame, then click on the app icon, I >don’t get an EVT_ACTIVATE_APP, so the frame doesn’t Raise(). If I >bring another app forward first, then it does work. > >Also, shouldn’t this happen automatically, by default? > > >I believe if a frame has been ‘iconized’ to the taskbar/dock you >need to call frame.Iconize(False) to bring it up from there, then >call Raise to make sure its the most forground frame. > >Not sure if it should happen automatically or
not, but for example >if your app has many frames open and minized to the dock, which one >/ all should be raised from the dock when you click on the icon? > > >Cody > >_______________________________________________ I am having some problems with this also, when the app is ‘iconized’ to the taskbar/dock, and on PC right clicking on icon and the restore menu item it works, if the close menu item is clicked the main frame goes away, but the icon is still in the taskbar, and if you click on it get an error message “wx._core.PyDeadObjectError: The C++ part of the mainframe object has been deleted, attribute access no longer allowed.” A double left click on the icon restores the app. on the Mac when it is iconized to the dock(with a miniture version of the app screen), and if you then click on the icon, the app de-iconizes and displays. But when you close the app the app appears to go away but the dock icon (of the app, not the iconized
to the dock one) will create the save error above. self.Bind(wx.EVT_TASKBAR_LEFT_DCLICK, self.OnTaskBarActivate) self.Bind(wx.EVT_MENU, self.OnTaskBarActivate, id=self.TBMENU_RESTORE) self.Bind(wx.EVT_MENU, self.OnTaskBarClose, id=self.TBMENU_CLOSE) self.Bind(wx.EVT_ACTIVATE_APP, self.OnTaskBarActivate) def OnTaskBarActivate(self, evt): if self.frame.IsIconized(): self.frame.Iconize(False) if not self.frame.IsShown(): self.frame.Show(True) self.frame.Raise() def OnTaskBarClose(self, evt): wx.CallAfter(self.frame.Close) Thanks Phil -------------- next part -------------- An HTML attachment was scrubbed… URL: http://lists.wxwidgets.org/pipermail/wxpython-users/attachments/20090205/3bb6249a/attachment-0001.htm ------------------------------ Message: 3 Date: Thu, 5 Feb 2009 16:11:54 -0800 From: Kevin Ollivier Subject: Re: [wxpython-users] OS-X issue – raising minimized frame. To: wxpython-users@lists.wxwidgets.org
Message-ID: 8465EA2F-1F19-4BA6-AD7F-8F45E29AC4E2@theolliviers.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi Chris, On Feb 5, 2009, at 3:30 PM, Christopher Barker wrote: > Cody Precord wrote: >> > wrote: >> I just tried this, and I’m getting close: >> in wx.App OnInit: >> self.Bind(wx.EVT_ACTIVATE_APP, self.OnActivate) >> … >> def OnActivate(self, event): >> if event.GetActive(): >> self.frame.Raise() >> event.Skip() > >> However, if I minimize the frame, then click on the app icon, I >> don’t get an EVT_ACTIVATE_APP, so the frame doesn’t Raise(). If I >> bring another app forward first, then it does work. >> I believe if a frame has been ‘iconized’ to the taskbar/dock you >> need to call frame.Iconize(False) to bring it up from there, then >> call Raise to make sure its the most
forground frame. > > Just plain old Raise() seems to work fine. The issue at hand is that > when the app is already the front app, then it doesn’t get a > EVT_ACTIVATE_APP event when the dock icon is clicked, so I can’t > bring the frame up. > > > Not sure if it should happen automatically or not, > > Well, it’s standard Mac behavior, including with a a wx App we wrote > in C++, in which I don’t think we’ve done anything special at all – > though I’m going to poke into that code to make sure. That behavior is common, but AFAICT even the default handling (which surely can be overridden) depends on the type of app it is. For example, in Mail.app there is a “main window” which is always restored and even recreated if needed, each time you click on the dock icon. Document-based apps, however, either create or restore a document, but only if there are no other documents open and shown. The thing is, I don’t know if wx can
really tell if you have a “main window” type app, or a “document-based” app (heck, we technically can’t even have an app without at least one top level window). > >> but for example if your app has many frames open and minized to the >> dock, which one / all should be raised from the dock when you click >> on the icon? > > well, usually when I click on the icon, ALL the apps non-iconized > windows come forward. It appears that only one does when they are > all iconized – Finder acts this way, for instance. But if you iconize one window but leave the rest up, the iconized window does not come to the front. > As for wx – there is SetTopWindow / GetTopWindow which seems to be > the solution as to what to bring forward. In the case at hand, we > only have one Frame, so it’s a non-issue. Except that apps that written code using this API may not expect this behavior, and once it’s “built-in”, you’re stuck with
either recoding your use of SetTopWindow or living with what may be incorrect (and possibly non-standard even on Mac) behavior for your app. I’d be happy to see some sort of add-on, maybe an event handler or mixin of some sort, created and maybe even have it put into wxPython for common behaviors (Cocoa-style default controllers FTW! ;-), but I don’t think we should alter wx under the hood to do this sort of thing. I know it’s nice for things to just work, but unless it’s certain to “just work” for everyone, I’d rather just make it easy to throw in. Thanks, Kevin > By the way, Editra 0.3.80 has this same issue, though If I drag and > drop a file onto the icon – the frame does get raised. > > Another note: I put the : > > if event.GetActive(): > > clause in, 'cause it seems to get an EVT_ACTIVATE_APP event when the > frame is minimized, too. > > -Chris > > > – > Christopher Barker, Ph.D. > Oceanographer

Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker@noaa.gov > _______________________________________________ > wxpython-users mailing list > wxpython-users@lists.wxwidgets.org > http://lists.wxwidgets.org/mailman/listinfo/wxpython-users ------------------------------ Message: 4 Date: Fri, 6 Feb 2009 02:32:20 +0100 From: Vlastimil Brom Subject: [wxpython-users] problems with wx.ComboBox and wx.ToolTip To: wxpython-users@lists.wxwidgets.org Message-ID: 9fdb569a0902051732o6493c90dp6fffc964a797b2a9@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi all, I just noticed a kind of strange behaviour of tooltips in connection with comboboxes in wxPython (win XPh, Python 2.5.4, wxPython 2.8.9.1). Basically, the combobox.ToolTip.SetTip(…) seems to only
have effect for the down-arrow of the widget; the text area continues to show the previously set ToolTip text. The next problem I found was setting the tooltip itself - under some circumstances an error is triggered for combobox.SetToolTip(…), namely for the minimised layout, wher the text control of the combobox isn’t shown (I recognize, that this isn’t a usual case, but such layouts are possible in my original aui app): The exception is: Traceback (most recent call last): File “[…]\test-wx-Combo-Tooltip.py”, line 10, in newToolTip comboBox3.SetToolTip(wx.ToolTip(u"new SetToolTip")) File “C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx_core.py”, line 10420, in SetToolTip return core.Window_SetToolTip(args, **kwargs) wx._core.PyAssertionError: C++ assertion “wxAssertFailure” failed at …..\src\msw\combobox.cpp(406) in wxComboBox::GetEditHWND(): not read only combobox without edit control? a simple code sample could be e.g.: (the second
combobox has different tooltips for the text field and arrow) the same can be reproduced on the 3rd combobox clicking at SetTip3. After reducing the window width - to hide the combo-text - an exception is thrown when adding new ToolTip … any hints are much appreciated, Vlasta ################################## #! Python # -- coding: utf-8 -*- import wx appl = wx.App(False) frm = wx.Frame(None, -1, “test wx.ComboBox + Tooltip”) pnl = wx.Panel(frm) def newToolTip(evt): comboBox3.SetToolTip(wx.ToolTip(u"new SetToolTip")) def SetTip(evt): comboBox3.ToolTip.SetTip(“SetTip only”) comboBox1 = wx.ComboBox(pnl, -1, u"combo 1", (-1, -1), (-1, -1), [“combo 1”], wx.CB_DROPDOWN) comboBox1.SetToolTip(wx.ToolTip(u"tooltip 1")) comboBox2 = wx.ComboBox(pnl, -1, u"combo 2", (-1, -1), (-1, -1), [“combo 2”], wx.CB_DROPDOWN) comboBox2.SetToolTip(wx.ToolTip(u"original tooltip 2")) comboBox2.ToolTip.SetTip(“CHANGED tooltip 2”) # by now the down-arrow shows shows the
changed tooltip, while the text control comboBox3 = wx.ComboBox(pnl, -1, u"combo 3", (-1, -1), (-1, -1), [“combo 3”], wx.CB_DROPDOWN) comboBox3.SetToolTip(wx.ToolTip(u"tooltip 3")) btn1 = wx.Button(pnl, -1, u"new ToolTip3", (-1, -1), (-1, -1)) btn1.Bind(wx.EVT_BUTTON, newToolTip) btn2 = wx.Button(pnl, -1, u"setTip3", (-1, -1), (-1, -1)) btn2.Bind(wx.EVT_BUTTON, SetTip) sizerFrm = wx.BoxSizer(wx.HORIZONTAL) sizerFrm.Add(btn1, 0) sizerFrm.Add(btn2, 0) sizerFrm.Add(comboBox1, 1) sizerFrm.Add(comboBox2, 1) sizerFrm.Add(comboBox3, 1) pnl.SetSizer(sizerFrm) frm.Show(1) appl.MainLoop() ------------------------------ Message: 5 Date: Thu, 5 Feb 2009 23:18:39 -0500 From: C M Subject: [wxpython-users] Re: experiment with Grady class for staticTexts on a gradient To: wxPython-users@lists.wxwidgets.org Message-ID: Content-Type: text/plain; charset=“iso-8859-1” [I’m re-posting this
because of at least one mistake and the unpleasant formatting, and to make it clearer.] I have like the effect of static text sitting on a gradient background, and so I thought it would be nice if I could put the code to do that in a class and then just pass the staticTexts to the class in a list, so that the class would set up that look automatically. I tried it, with partial success. The class, “Grady” (for gradient and in honor of the Whitman Mayo character), is passed a list of staticTexts, gets facts about each one–like size and position–and passes that to a drawing function which puts a gradient on their panel and draws each staticText’s label in the same position as the original staticText. It also hides each staticText, and attempts to replace each with a spacer of the same size, so that the sizing still works on the panel as it would if the staticTexts were not hidden. The problems with this approach, if anyone is interested, are: The spacer

I don’t know how to get the index of an item in a sizer, so I don’t know at which index to insert a spacer to “hold the place” of the hidden staticTextCtrl in the sizer. (For the attached example I am just hardcoding the insertion point). 2) In this example the height of the spacer is not enough to push the next control (the wxChoice) down to where it would be if the staticTextCtrl were not hidden. It should have the same height as the staticText it is replacing. I have hardcoded 20px more to the height attribut just to make the spacer large enough here. This is probably a simple mistake I am not seeing. Fonts The .SetFont() method of the DC I’m using to draw on the labels only accepts a limited family of fonts, not actual fonts. So I don’t think the DC can draw all the fonts that the staticText could. For staticTexts that are in a basic font like Tahoma, it is OK, but a less common font, like Chiller, isn’t going to be able to be drawn by the DC.
Text Distortion on Resizing The text distorts a bit during resizing the frame, though I’m sure this is just my using the drawing wrong. I had hoped the “Grady” class could work for other label-based widgets that don’t let the background shine through, like radioButton, but because of the image of the radiobutton itself, I don’t think that will be possible. As it is, it is not even working sufficiently well for just staticTextCtrls. In any case, I gave it a shot, and hoped it might provoke further thought. Sample attached. As is, it shows one of the static texts with a gradient and one without. You can comment out the line: Grady([self.staticText2, ]) and see both staticTextCtrls without a gradient, or you can add self.staticText1 to this list and see them both over a gradient. Che -------------- next part -------------- A non-text attachment was scrubbed… Name: grady_frame.py Type: application/x-python Size: 6026 bytes Desc: not available Url :
http://lists.wxwidgets.org/pipermail/wxpython-users/attachments/20090= 205/f0236149/grady_frame.bin ------------------------------ _______________________________________________ wxpython-users mailing list wxpython-users@lists.wxwidgets.org http://lists.wxwidgets.org/mailman/listinfo/wxpython-users End of wxpython-users Digest, Vol 12, Issue 26 **********************************************