Hi,
ok, I'm an newbie.
I'm looking for the Events to capture the "changed" Event on a
wxGrid.
Currently I've handled to get data via odbc into the grid, but for
writing them back it would be nice to know what has changed 
And btw: I've heard about the new wxdbGrid, are there
Python-Bindings available ? ( currently running ActivePython 2.2
with wxWindows 2.3 )
regards,
.klemens
Hi folks,
I'm back after a two-year-ish hiatus (my last post on the list was
Sept. 99), and trying to pick up my old python/wxPython code where
I left it lying at that time...
Amazingly, it still works 
I do have a (visual) problem though that I don't think was there with
the wxPython version I was using at the time.
This is a card game, like Solitaire. So it does a lot of dragging
around bitmaps (the cards) on a green background (0,128,0), with
old-fashioned double-buffered Blits (wxDragImage did not exist at
the time, and I'm too lazy to recode that part :).
What happens is this : when I start dragging a card or suite of
cards, I paint a temp DC of the same size with the background color
(drawrectangle), then blit any underlying card(s) on that, and use it
as the initial background for the drag-n-drop animation. However,
the background doesn't come out as solid green like the rest, but
rather as a lighter, "meshed" (?) color. And it's the only place in the
code where that happens, all other cases where I use that same
brush come out correctly (like while actually dragging).
I'm pretty sure this didn't happen two years ago, and I've run out of
places to look. Is it something that has changed subtly in
wxWindows since ? For all I know it could be my video card and/or
drivers (cause the PC has changed in between too :).
All suggestions welcome - I can post some code if necessary,
although that would really make me feel ashamed :-)))
TIA,
Fred
ok, I'm an newbie.
Everybody was at one point of time...
I'm looking for the Events to capture the "changed" Event on a
wxGrid.
Currently I've handled to get data via odbc into the grid, but for
writing them back it would be nice to know what has changed
GridSimple.py in the demo shows most of the grid events, the one you
probably want is EVT_GRID_CELL_CHANGE.
And btw: I've heard about the new wxdbGrid, are there
Python-Bindings available ? ( currently running ActivePython 2.2
with wxWindows 2.3 )
Not at this time. It's a possibility however.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
I'm back after a two-year-ish hiatus (my last post on the list was
Sept. 99), and trying to pick up my old python/wxPython code where
I left it lying at that time...
Welcome back.
Amazingly, it still works
Cool!
What happens is this : when I start dragging a card or suite of
cards, I paint a temp DC of the same size with the background color
(drawrectangle), then blit any underlying card(s) on that, and use it
as the initial background for the drag-n-drop animation. However,
the background doesn't come out as solid green like the rest, but
rather as a lighter, "meshed" (?) color. And it's the only place in the
code where that happens, all other cases where I use that same
brush come out correctly (like while actually dragging).I'm pretty sure this didn't happen two years ago, and I've run out of
places to look. Is it something that has changed subtly in
wxWindows since ?
Possible. Double check the parameters for all your draw methods, especially
the logical function used for drawing or blitting.
For all I know it could be my video card and/or
drivers (cause the PC has changed in between too :).All suggestions welcome - I can post some code if necessary,
although that would really make me feel ashamed :-)))
Sometimes the best way to solve a problem is to go through the effort to
duplicate the problem in a small sample to send to me. Often people
discover the problem themselves while doing that.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Yes, indeed! I can't tell you how many times that has happened for
me.
--- Robin Dunn <robin@alldunn.com> wrote:
Sometimes the best way to solve a problem is to go through the
effort to duplicate the problem in a small sample to send to
me. Often people discover the problem themselves while doing
that.
=====
Donnal Walter
Arkansas Children's Hospital
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
Robin said :
Welcome back.
Thanks 
> Amazingly, it still works
Cool!
Yes, especially as that code dates back to the time when wxPython
still had the "magic event handlers" (or something such). I fully
expected to be bitten by that, but it turns out I had actually heeded
your advice at the time and already put them in explicitely...
> I'm pretty sure this didn't happen two years ago, and I've run out of
> places to look. Is it something that has changed subtly in
> wxWindows since ?Possible. Double check the parameters for all your draw methods, especially
the logical function used for drawing or blitting.Sometimes the best way to solve a problem is to go through the effort to
duplicate the problem in a small sample to send to me. Often people
discover the problem themselves while doing that.
I can certainly relate to that - but it's probably a major undertaking in
this case :)... I'll resort to that if nothing else works. In the
meanwhile, it did have the merit to make me freshen up on the wxDC
API, and learn a few things I'd overlooked (or didn't exist at the time).
Preliminary findings : the problem is definitely with the wxCOPY
logical func and the DrawRectangle method, in that particular event
handler (left button down). wxCLEAR, for instance, works as
expected.
Also, if I use the exact same brush with SetBackground instead of
SetBrush, and wxDC.Clear() instead of wxDC.DrawRectangle(), the
problem (mostly) goes away.
At first I thought it was totally gone, but under intensive testing (ie
actually playing the game and shuffling a lot of cards around it
does sometimes occur, albeit rarely & randomly instead of
systematically. So I'm not ruling out some weird video/driver/timing
bug on my system just yet.
Right now I need to a) upgrade to the very latest wxPython on my
home system (I think I'm one rev behind), and b) bring the package
to work for testing on a couple of different platforms. If the problem
persists it'll be time for Plan B (Robin's :-).
Thanks for your help,
fred
Right now I need to a) upgrade to the very latest wxPython on my
home system (I think I'm one rev behind), and b) bring the package
to work for testing on a couple of different platforms. If the problem
persists it'll be time for Plan B (Robin's :-).
Well, it seems my hunch is confirmed : on this PC at work, the old
code works just as it used to, without any of these "phantom
backgrounds" effects. So it's probably a glitch on my home machine
after all - I should have checked that first before crying out, sorry
I may still keep the alternative code though - setbackground + clear
instead of setbrush+setpen+drawrectangle - as it seems a bit more
bulletproof and saves a few lines...
A real question for a change : does anyone know a place where I
could pilfer a good selection of ready-made bitmaps to build a
toolbar from ?
Thanks,
fred
A real question for a change : does anyone know a place where I
could pilfer a good selection of ready-made bitmaps to build a
toolbar from ?
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Robin said :
> A real question for a change : does anyone know a place where I
> could pilfer a good selection of ready-made bitmaps to build a
> toolbar from ?
Thanks. I was thinking specifically of bitmaps tailor-made for classic
toolbars (Windows-style), rather than regular icons which tend to be
a bit large for the job. However, a little searching shows this does not
seem to be a common resource on the Web. Considering my
artistic abilities, I guess my best bet is to dig out Resource Hacker
and go pilfer every toolbar-enabled executable I can find
Thanks. I was thinking specifically of bitmaps tailor-made for classic
toolbars (Windows-style), rather than regular icons which tend to be
a bit large for the job. However, a little searching shows this does not
seem to be a common resource on the Web.
These turn up a few sites:
http://www.google.com/search?q=16x15+icons
http://www.google.com/search?q=16x16+icons
Considering my
artistic abilities, I guess my best bet is to dig out Resource Hacker
and go pilfer every toolbar-enabled executable I can find
The site seems to be down right now but I really like these, although last I
checked the smallest were only 20x20. (But they look VERY nice.)
http://jfa.javalobby.org/index.html
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Robin said :
I was thinking specifically of bitmaps tailor-made for classic
> toolbars (Windows-style), rather than regular icons which tend to be
> a bit large for the job. However, a little searching shows this does not
> seem to be a common resource on the Web.These turn up a few sites:
16x15 icons - Google Suche
16x16 icons - Google Suche
Thanks again, Robin. I must admit that I had not thought of such
queries
The site seems to be down right now but I really like these, although last I
checked the smallest were only 20x20. (But they look VERY nice.)
http://jfa.javalobby.org/index.html
Yes, and it's stayed down since (although the rest of javalobby
seems to work). Hope it's not down for good, now that you've
whetted my appetite
> The site seems to be down right now but I really like these, although
last I
> checked the smallest were only 20x20. (But they look VERY nice.)
> http://jfa.javalobby.org/index.htmlYes, and it's stayed down since (although the rest of javalobby
seems to work). Hope it's not down for good, now that you've
whetted my appetite
There is a subset of them here:
http://www.vrjuggler.org/JExplorer/Dean_S._Jones_24x24_Images.html
If the jfa site doesn't come back up soon let me know and I can send you the
last .zip I downloaded from there.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Robin said :
http://www.vrjuggler.org/JExplorer/Dean_S._Jones_24x24_Images.
html
If the jfa site doesn't come back up soon let me know and I can send you the
last .zip I downloaded from there.
TIA, Robin. I am in no hurry whatsoever but if the site does stay
down for good I will take you up on your offer. These icons are
certainly way above the common fare found elsewhere : original,
good looking, and tasteful. I found the 20x20 gifs on that page work
quite well for my toolbar, so I'm mostly set for now. But I'm certainly
interested in seeing the rest...
Thanks,
fred
PS: I see from previous posts in the list that currently
wxToolbar.AddTool does not support the x,y parameters of the C++
version. Is this supposed to change in a future release ?
>
> If the jfa site doesn't come back up soon let me know and I can send you
the
> last .zip I downloaded from there.
TIA, Robin. I am in no hurry whatsoever but if the site does stay
down for good I will take you up on your offer.
Hopefully I won't get in trouble for this, but here they are:
http://alldunn.com/jfaicons.zip
PS: I see from previous posts in the list that currently
wxToolbar.AddTool does not support the x,y parameters of the C++
version. Is this supposed to change in a future release ?
That C++ method is deprecated and only kept for backwards compatibility.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Robin said :
Hopefully I won't get in trouble for this, but here they are:
http://alldunn.com/jfaicons.zip
Thanks a lot Robin. I promise I won't tell anyone
This guy is really gifted...
> PS: I see from previous posts in the list that currently
> wxToolbar.AddTool does not support the x,y parameters of the C++
> version. Is this supposed to change in a future release ?
That C++ method is deprecated and only kept for backwards compatibility.
We're actually talking about the same one, yes ? I meant this :
wxToolBarTool* AddTool(int toolId, const wxBitmap& bitmap1,
const wxBitmap& bitmap2 = wxNullBitmap, bool isToggle = FALSE,
long xPos = -1, long yPos = -1, wxObject* clientData = NULL, const
wxString& shortHelpString = "", const wxString& longHelpString =
"")
It doesn't say it's deprecated in the docs. Does that mean it is impossible to
place a toolbar button elsewhere than at the default position ?
> > PS: I see from previous posts in the list that currently
> > wxToolbar.AddTool does not support the x,y parameters of the C++
> > version. Is this supposed to change in a future release ?
> That C++ method is deprecated and only kept for backwards compatibility.We're actually talking about the same one, yes ? I meant this :
wxToolBarTool* AddTool(int toolId, const wxBitmap& bitmap1,
const wxBitmap& bitmap2 = wxNullBitmap, bool isToggle = FALSE,
long xPos = -1, long yPos = -1, wxObject* clientData = NULL, const
wxString& shortHelpString = "", const wxString& longHelpString =
"")It doesn't say it's deprecated in the docs.
It does in the source.
Does that mean it is impossible to
place a toolbar button elsewhere than at the default position ?
I don't think it was ever possible in the native toolbar, only in the
generic one which used to be used on a couple platforms. (It may still be,
I don't remember right now...)
There is InsertTool and wxPython's InsertSimpleTool that allows you to
specify the position as a relative ordering of the tool.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Robin said :
> We're actually talking about the same one, yes ? I meant this :
> wxToolBarTool* AddTool(int toolId, const wxBitmap& bitmap1,
> const wxBitmap& bitmap2 = wxNullBitmap, bool isToggle = FALSE,
> long xPos = -1, long yPos = -1, wxObject* clientData = NULL, const
> wxString& shortHelpString = "", const wxString& longHelpString =
> "")
> It doesn't say it's deprecated in the docs.It does in the source.
Oh, right
> Does that mean it is impossible to
> place a toolbar button elsewhere than at the default position ?I don't think it was ever possible in the native toolbar, only in the
generic one which used to be used on a couple platforms. (It may still be,
I don't remember right now...)
There is InsertTool and wxPython's InsertSimpleTool that allows you to
specify the position as a relative ordering of the tool.
OK. At one time when I saw the full syntax for AddTool, I wondered
if that could be used to make "split" toolbars like one sometimes
sees in Windows : most of the tools are left-aligned as usual, with
one or two icons to the far right (usually Exit and/or Help). But I
asked more to make sure I understood things properly than out of
actual need...
