Re: [wxPython-users] Digest for wxpython-users@googlegroups.com - 7 updates in 3 topics

12 views
Skip to first unread message

Digest recipients

unread,
Apr 14, 2017, 1:34:24 PM4/14/17
to wxpytho...@googlegroups.com
braide...@gmail.com: Apr 13 04:57AM -0700

One really important difference between 2.8 and Phoenix deals with the
backend handling of GridCellAttr(). It appears that in 2.8, it is possible
just to simply create the object and then override specific properties. In
Phoenix, it appears that
 
my_attr=GridCellAttr()
 
creates an object with few or none of its attributes initialized.
 
Questions:
 
1. Is there some "best practice" way to fully populate the attributes?
2. Once these are created, should we do anything special during destruction?
 
Many Thanks, Eric
braide...@gmail.com: Apr 14 06:47AM -0700

Lesson - always remember to look at both wxPython and wxWidgets docs.
 
To POSSIBLY answer my own question 1:
 
gr=My wx.Grid Object
 
dch,dcv=gr.GetDefaultCellAlignment()
dcbgc=gr.GetDefaultCellBackgroundColour()
dcf=gr.GetDefaultCellFont()
dctc=gr.GetDefaultCellTextColour()
dce = gr.GetDefaultEditor()
dcr = gr.GetDefaultRenderer()
result = GridCellAttr() #new instance of GridCellAttr
#Go through steps to decide whether or not to use default or
override
#must make sure to set these props, default or otherwise
#renderer and editor require .IncRef(), according to my one
example???
 
The good news for me, fully populating attributes eliminates the errors
related to Null colors or Null Fonts or ...
 
The bad news, I am now getting an abrupt segfault, though this time it
complains about refcounts - oops, different thread
James Scholes <ja...@jls-radio.com>: Apr 14 01:21AM +0100

Hi folks,
 
Just a quick question: I have an accelerator table set for my
application's main panel, and the shortcuts in it should be active
pretty much everywhere in the program. But they include some keystrokes
that are usually reserved for moving the cursor and selecting text
inside text fields (Ctrl+Left/Right for moving by word, Shift+Left/Right
for text selection).
 
How can I suspend processing of those accelerators while inside a
TextCtrl so that they carry out their normal functions? I tried setting
an accelerator table for the TextCtrl itself, and doing an event.Skip()
inside the wx.EVT_MENU handler. While this does prevent the keys from
triggering their panel-wide functions, they don't actually do what
they're supposed to do either. E.g. Ctrl+Left doesn't move by word, it
just leaves the cursor where it is.
 
Unsetting the accelerator table on focus seems like a bad idea, and
wouldn't work very well here as there are other shortcuts registered on
the table which should do something no matter the focused control type
 
Thanks in advance for any suggestions.
--
James Scholes
http://twitter.com/JamesScholes
Claudia Frank <cfran...@gmail.com>: Apr 12 02:47PM -0700


> Web search the '[xcb] ...' messages you saw and you'll soon find
> that this is a frequent problem, and not an issue with wxPython/GTK
> specifically.
 
I see, thank you for clarification.
 
Cheers
Claudia
Claudia Frank <cfran...@gmail.com>: Apr 12 03:05PM -0700

Hello James,
 
thank you to you as well.
I do see, that supporting multiple platforms comes with
... don't know how to say ... drawbacks (not exactly but I guess you know
what I mean.)
I wanted to avoid using ctypes because of the cross platform code.
Currently I'm running it only on my ubuntu machines but who knows maybe one
day
it will run on different os.
I guess I will try using IdleEvent.
 
Thank you very much
Claudia
Tim Roberts <ti...@probo.com>: Apr 12 10:41PM -0700

>> used in such a case?
 
> Yes - consider the whole library to not have thread safety and
> coordinate access to it appropriately.
 
This note deserves comment, because it misplaces the blame. This is not a WX problem. The issue is the underlying operating systems. On Windows, you can do quite a lot of GUI stuff from other threads. On MacOS, you can do GUI stuff on bitmaps, as long as you protect it with locks. On Linux, NOTHING works from a secondary thread.

Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
James Scholes <ja...@jls-radio.com>: Apr 13 10:31AM +0100

Tim Roberts wrote:
> This note deserves comment, because it misplaces the blame. This is not a WX problem. The issue is the underlying operating systems.
 
I did point this out later in the same email, as well as quoting the
official wxWidgets docs which say the same thing. But as wx is designed
to be a cross-platform library, the end-result is often the same - wx
cannot be considered to be thread-safe.
--
James Scholes
http://twitter.com/JamesScholes
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to wxpython-user...@googlegroups.com.

Digest recipients

unread,
Apr 14, 2017, 1:34:56 PM4/14/17
to wxpytho...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages