Some ideas ... Data-aware controls?

Hi all,

Now that I am working on my first python application, I find a lot of
things that are very common for every application, and I wonder if
effort couldn't be put in creating controls or wrappers for existing
controls that are data-aware?

How often do you need to;

- Restore the data from a db / file
- List it in a wx.ListCtrl / wx.ListBox / wx.Choice etc
- Edit the data
- Store it back

Those actions are so common, yet for every GUI you are stuck writing
the data sync methods to get the data inside the GUI controls and
back, not to mention every data sort routine needs to be
re-implemented, or if you want your columns to be customized, etc.

I am busy with wxPython for about a month now, and I do know it is a
language that lends itself perfectly for controls and classes that are
more elegant in use towards data management.

For example, a kind of provider class could get special accessor
methods (like a facade or an interface) that can be used with (for
example) a wx.data.listctrl (choice, combo, grid, listbox, etc). Which
is a wrapper for wx.ListCtrl but much more intelligent as most actions
can be 'automated', like:

- Create the wx.ListCtrl with a number of columns
- Fill the control with class data
- Implement native sorting on column headers
- Implement view manipulation like column ordering / removing / adding
of new columns

So for example, if one has a data class like:

# trivial person object
class Person(object):
  def __int__(self):
    self.mName = ''
    self.mAge = 30

And a provider class like;

class PersonDataProvider(wx.data.AbstractDataProvider):
  def __init__(self):
    self.__mColumnCount = 2 # e.g name, age

  # return amount of columns in the data view
  def getColumnCount(self):
    return self.__mColumnCount

  # returns column name for every column
  def getColumnName(self, colidx):
    if colidx < self.__mColumnCount:
      if colidx = 0: return 'Name'
      elif colidx = 1: return 'Age'

  # gets the amount of records
  def getRecordCount(self):
     return 1

  # gets the value per cell
  def getCellValue(self, recordidx, columnidx):
    # get object in list
    if columnidx == 0: return mPersonList[recordidx].mName
    elif columnidx == 1: return mPersonList[recordidx].mAge

The above provider suggestion is not very 'pythonic' I still lack all
the knowledge to make it look slick, so it might look C+'ish .. anyway
the basic idea would be giving a wx.data.ListCtrl (as example for the
name) a *provider* class instance, which would act as an abstract
interface to initialize the columns inside the internal wxListCtrl,
let it fill itself by asking the records.

For example;

# instantiate a provider class, give it a pointer to my persons list
p = PersonDataProvider(self.__mMyPersons)

# create a list ctrl
lc = wx.data.listctrl(self, ...)
lc.provider = p

# show same options in a choice somewhere else
ch = wx.data.choice(self, ..)
ch.provider = p

And by passing the provider to the data aware list ctrl, the columns
are automatically created, records are filled in the list, and if
needed column ordering and sorting is restored from a previous
setting. For the choice, the items are dumped in a choice box.

By introducing data aware or data feeding controls, the same
dataprovider can be used to fill listboxes, listctrls, choices, grids
etc with data that is retrieved from the provider. By making a few
methods in the provider act like an interface to any data aware
component that wxPython could offer in the future, one is freed of the
ever repeating tasks of creating wx.ListCtrl objects, initializing
them, painstakingy filling them with the crappy interface that is
provided.

The basic goal could be is providing a a set of controls that are
max-data aware, and provide the following automated features:

- Auto filling with data in the preferred (or last used) sort order
- Column sorting by clicking on it
- Column re-ordering by dragging columns or even introducing new columns
- Filtering of data to be added
- Auto updating of data records by telling the provider class that
data is changed
- Auto signaling back that the user has selected an item inside the
control so that the application can react upon it

A lot of these things can be automated, if not more things. I work
with Delphi a lot and one it also uses data aware controls. A very
good example is DeveloperExpress. We use those components to fill the
tables with data and with little effort the controls allow us to move
around columns, sort, edit, even switch between column mode view, and
row mode view, all because of one class, a data provider.

I'm working on yet another app, and realized it would be a good
addition to wxPython. I just wanted to get the discussion going, maybe
one day I can contribute to this, as I am sure nobody likes to fight
with wx.ListCtrl and wx.Grid to show over and over again a list of
data, which would be trivial to implement in a provider class, but
once again a lot of work to manually add them to all controls in your
view.

Sorry it got so long. ... :slight_smile:
- Jorgen

Might I suggest taking a look at Dabo? This is exactly what it is designed to do. It wraps wxPython with a more Pythonic (IMO) API, and has data-binding built into the controls. It is a complete 3-tier application framework that uses wxPython for the GUI.

  You might want to check out some of our screencasts. They are listed at:

http://dabodev.com/documentation

  Of particular interest to you may be:

Building a Database Application using the Dabo Class Designer (Parts 1 & 2)
Create a Database Application in Less Than a Minute
Populating a Grid Using Business Objects

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On Apr 18, 2007, at 8:39 AM, Jorgen Bodde wrote:

Now that I am working on my first python application, I find a lot of
things that are very common for every application, and I wonder if
effort couldn't be put in creating controls or wrappers for existing
controls that are data-aware?

Hi Ed,

I looked at Dabo and it is not exactly what I meant.

First of all, it is a bit over the top to redesign a whole app to use
a dabo form / form designer, dabo controls etc. Second, I see no
wxListCtrl for example, which can do what I suggested:

- Sorting columns natively
- Ordering columns to user preference

I do see that the grid does this, but it is not the way I meant using
a dataprovider. Sometimes it need to blend in more elegantly with the
native controls, for example I have a selector for my items on the
right in a fairly small sidebar. Whenever I need to put a grid there
it would screw up my whole GUI design.

Sometimes you do not want a three tier solution, business objects,
you simply want to use a provider to quickly list some data, from
whatever source.

Basically DABO would be suited for heavy data apps but has a steeper
learning curve then using a class that acts like a provider, and where
you only need to override 3 or so methods from to get a filled
wx.ListCtrl

So what I was thinking of is providing an interface / facade to
objects that are already in wxWidgets which benefit from one class and
do not care where the data is 'provided' from.

Anybody else has some views on this?
- Jorgen

Jorgen Bodde wrote:

So what I was thinking of is providing an interface / facade to
objects that are already in wxWidgets which benefit from one class and
do not care where the data is 'provided' from.

You might want to check out http://wiki.wxpython.org/index.cgi/ModelViewController. Combining this type of architecture with wxPython's pubsub module I think will get you great results (why don't they use it on that wiki page? I think it would be much nicer and simpler). Pubsub is very elegant and simple and I recently used it when adding a GUI layer on top of a command line application, which basically was just a Controller on top of a Model.

It really makes communication a breeze. Basically in your model or whatever, whenever you change a piece of data you do pubsub.Publisher().sendMessage("new song", data), for example. Then in the init of a widget that cares about a new song, you do pubsub.Publisher().subscribe(myMethodToUpdateMyselfBasedOnANewSong, "new song"). That method will then be called when you send the message, with the data you gave it.

Hopefully this helps,
- Mike

I agree with Christopher's observation in general, and do indeed feel
that it applies to you. You took a brief look at something, formed an
opinion that it didn't do exactly what you wanted, and then refused to
reconsider even when it was pointed out to you that you can simply use

Ok, no problem. This is what my impression was;

When looking at Dabo and the demo, I saw NO wxWidgets anymore.
Everything is encapsulated in a Dabo framework. Am I correct? Using
parts of it individually or not.

Which would have meant my apps would be Dabo GUI based and no longer
wx based. If I look at the wxPython-Demo dir, or the Dabo demo dir,
correct me if I am wrong, I only see dabo.ui.* controls.I searched for
"wx." as a term to see how much native wx components were still used
inside the GUI, and found *none*. Only dabo.ui.dPanel, dabo.ui.dLabel,
dabo.ui.dWhatever ... So, I came to the conclusion, Dabo must be a
whole framework where the main key is not exposing wxWidgets to the
users anymore, but wrapped controls, even if those might still be
mixed together I don't know. But that was my first impression.

Well like I am repeating myself for the 3rd time this is not what I
*meant* by my suggestion about native wx data aware controls (mind the
word native, as in part of wxPython)

I do not wish to rewrite large parts of my whole app to use only
dabo.ui.* classes, and frankly, using GUI designers out of the Dabo
framework would only allow me to generate 'foreign' controls, or the
most part of it. I saw there was a whole UI designer to be used for
Dabo, I like to stay as close to the native side of wxWidgets meaning
thin wrapped classes using wx as namespace, and which offer me the
strength of the original classes, THAT is what I proposed and looked
for, and that is not what Dabo seems to give me.

the UI portion, and when the author himself offered to work with you
to implement your requests. For that reason, I think it best that you
go your own way instead of benefiting from the hard work of others,
which it doesn't seem you appreciate very much.

I appreciate hard work, but I still believe you are comparing apples
and oranges here. I might be wrong, Dabo is built on top of wxPython.
I am suggesting something that is built *for* wxPython or next to
python, like the dozen of add-on classes. And I do not like to get
flamed for not using one thing or the other, or respecting or not
respecting hard work, so let's keep this constructive.

Also, the name is 'Dabo', not 'DABO'. I know it seems petty, but it
doesn't seem that you have any problems getting capitalization right
with anything else in your posts.

I hardly believe that is an issue in the discussion here, but I am
sorry I offended you by capitalizing incorrectly.

Anyway, I might have been over enthousiastic about an idea. It
happens. I hoped for a debate to see if something small and elegant
could be made that would be part of the wxPython distrib, instead of
something written on top of wxPython which would mean everyone using
this approach would have to use Dabo as well, which is not what I had
in mind.

- Jorgen

Hi all,

[snip]

I think Ed has done some excellent work, and honestly I hope to see Dabo succeed because of it, but this is the wxPython-users list and I think suggesting a feature like this for wxPython should not be so controversial. Any improvements to wxPython can, and hopefully will, lead to improvements in all the frameworks that derive from it. And how is that not a good thing?

BTW, I just noticed I only mentioned Ed's work rather than mentioning Paul and the other Dabo contributors as well. I meant to say "the Dabo developers" but for some reason I didn't. Sorry about that! ;-/

Kevin

···

On Apr 19, 2007, at 9:16 AM, Kevin Ollivier wrote:

Regards,

Kevin

- Jorgen

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

@ Peter Decker:

When looking at Dabo and the demo, I saw NO wxWidgets anymore.
Everything is encapsulated in a Dabo framework. Am I correct? Using
parts of it individually or not.

Yes, because one of Dabo's goals was to provide an API that is
independent of your UI-toolkit choice. So you could use tk or qt or
any other toolkit, and still have the same API.

Exactly. And as I said, that was not what I had in mind. I am glad
finally it was understood what I meant. Dabo is great, but I want to
offer a solution to everyone else who would not directly use Dabo. We
have a lot of controls in wxPython that represent data in some kind,
but no layer that actually handles data more intelligently so
everytimethe developer has to add the columns, fill the data, sort the
data, etc themselves. One class that provides enough information to
let them auto-initialize was what I meant ... And Dabo would be on top
of that using such a provider for example to show the BizObjects to
the user, shielding as much of wx as possible.

@ Kevin:

wxPython? Personally, I think it'd be great to have one
implementation that Dabo and wxPython could share, so that all our
users could benefit from it, and so that it will get more testing and
stability. After all, if we don't want to "re-invent the wheel" and
have every abstraction layer offer competing implementations of data-
aware controls, the best way to solve the problem would be to solve
it at a level common to all the frameworks, which would be, well,
wxPython. So, personally, I think your approach is the one that makes
it so that no-one need re-invent the wheel.

Exactly. I am always facing this. A lot of code that is present in an
application is duplication of something that could be centralized.
Basically what is taken away from the developer is:

- Add columns to the wxListCtrl / Grid
- Filling the data
- Implementing custom sort on the columns
- Implementing custom column display
- Implementing persistence on the view
- Responding on an edit of a field in the grid / list ctrl
- Adding extra data, updating existing data

All that he/she needs to do is fill in a few methods in the derived
provider class and the rest could be programmed into the control
itself ..

I will try to get something as a proof of concept, basically create a
ProviderBase class, and a specialized RecordProvider. The record
provider can be used for filling wx.LIstCtrl, wx.Grid, wx.Choice,
wx.Combobox.

The wx.ListCtrl could have columns that look like the ones in
Thunderbird, they have a set of columns defined by the provider class,
and the last column is a small icon that provides
a menu when clicked, adding more columns or sorting the ones that are shown.

Eventually the data aware wx.ListCtrl can have a popup menu / toolbar
automatically created (if desired) which allows the user to add more
data, delete the data or modify it. If the menu is selected an event
is fired from the control, so the user can take the appropiate
actions.

@ Don Dwiggins:

Here's a straw man to get started: a data-aware control has at least the
following characteristics:
- It can be "connected" to a source of data items;
- The source may be read-only (strictly a source), or may be able to
accept data items back from the control (with the intent that an item
returned by the control is intended to replace the item in the source);

Indeed. The sources could be single edit like providing a wx.TextCtrl
with a single record and a way to send the source with an update if
changed, or multi record based. The editing could be done with an
event giving the user full control, but also in-control which means
the control itself will provide the user the means to add data in the
form of a new row. This one is more tricky as you also have to provide
the source with the type of data the column is, like a string,
integer, choice, boolean. Python is very good in identifying types at
runtime so passing it a dictionary or a list of choices to edit should
not be too difficult

- The source must be compatible with the nature of the control, in that
the kind of data supplied by the source must naturally fit what the
control can display, and what the control can return to the source
(example of a mismatch: a paragraph of text sent to a choice box);

That's true. So I would derive from a base provider class, with as
derived classes a RecordProvider, TextProvider, and maybe a
ListProvider which is a subset of the RecordProvider, as a list of
choices can be seen as only displaying a single column

- The source-to-control flow of data may be either pull- or push-driven,
or a mix (both control and source must be able to accept itens at the
other's initiation).

Which could be events sending out OnAddData, OnDeleteData,
OnModifyData, or the controls pushing out data to the provider after
the user did an in-control modify on a record, or deleted data rhat
needs to be deleted from the main source right?

We might be on to something here :wink:

- Jorgen

Hi Jorgen,

[snip]

@ Kevin:

wxPython? Personally, I think it'd be great to have one
implementation that Dabo and wxPython could share, so that all our
users could benefit from it, and so that it will get more testing and
stability. After all, if we don't want to "re-invent the wheel" and
have every abstraction layer offer competing implementations of data-
aware controls, the best way to solve the problem would be to solve
it at a level common to all the frameworks, which would be, well,
wxPython. So, personally, I think your approach is the one that makes
it so that no-one need re-invent the wheel.

Exactly. I am always facing this. A lot of code that is present in an
application is duplication of something that could be centralized.
Basically what is taken away from the developer is:

- Add columns to the wxListCtrl / Grid
- Filling the data
- Implementing custom sort on the columns
- Implementing custom column display
- Implementing persistence on the view
- Responding on an edit of a field in the grid / list ctrl
- Adding extra data, updating existing data

Yes, I agree these would be some great features. :slight_smile: That reminds me I need to look again at how to implement the native Mac ListCtrl's ability to rearrange columns using drag and drop.

As a side note, IMHO persistence should be implemented at the wx.Window level, as it's really desirable for just about any window/control under any situation. e.g. we'd have some base methods like LoadState() and SaveState, which would use wxConfig and save/load any persistent properties when called. Controls like wxListCtrl or your subclass would then override the method and add the persistent properties you want to store.

All that he/she needs to do is fill in a few methods in the derived
provider class and the rest could be programmed into the control
itself ..

I will try to get something as a proof of concept, basically create a
ProviderBase class, and a specialized RecordProvider. The record
provider can be used for filling wx.LIstCtrl, wx.Grid, wx.Choice,
wx.Combobox.

Thanks! :slight_smile:

The wx.ListCtrl could have columns that look like the ones in
Thunderbird, they have a set of columns defined by the provider class,
and the last column is a small icon that provides
a menu when clicked, adding more columns or sorting the ones that are shown.

BTW, on Mac, column show/hide and sorting features are typically implemented via a popup menu when you click on column headers, along with usually "Show Columns -> <column list>" and "Sort Columns" menu items in the View menu. (Although the idea is that you shouldn't have to manually re-sort the columns.) None of the native apps have an icon for it, or if they do, it's a regular toolbar icon. Since we're talking about wx here, it'd be nice if the default (on Mac at least) was to go with the popup menu on right click, along with maybe a getShowColumnsMenu() method that you could just plug into your View menu. I don't mind if there's an option for the icon, but I'd like to make sure there's a way not to use that icon in order to get 100% native LNF.

Eventually the data aware wx.ListCtrl can have a popup menu / toolbar
automatically created (if desired) which allows the user to add more
data, delete the data or modify it. If the menu is selected an event
is fired from the control, so the user can take the appropiate
actions.

@ Don Dwiggins:

Here's a straw man to get started: a data-aware control has at least the
following characteristics:
- It can be "connected" to a source of data items;
- The source may be read-only (strictly a source), or may be able to
accept data items back from the control (with the intent that an item
returned by the control is intended to replace the item in the source);

Indeed. The sources could be single edit like providing a wx.TextCtrl
with a single record and a way to send the source with an update if
changed, or multi record based. The editing could be done with an
event giving the user full control, but also in-control which means
the control itself will provide the user the means to add data in the
form of a new row. This one is more tricky as you also have to provide
the source with the type of data the column is, like a string,
integer, choice, boolean. Python is very good in identifying types at
runtime so passing it a dictionary or a list of choices to edit should
not be too difficult

- The source must be compatible with the nature of the control, in that
the kind of data supplied by the source must naturally fit what the
control can display, and what the control can return to the source
(example of a mismatch: a paragraph of text sent to a choice box);

That's true. So I would derive from a base provider class, with as
derived classes a RecordProvider, TextProvider, and maybe a
ListProvider which is a subset of the RecordProvider, as a list of
choices can be seen as only displaying a single column

- The source-to-control flow of data may be either pull- or push-driven,
or a mix (both control and source must be able to accept itens at the
other's initiation).

Which could be events sending out OnAddData, OnDeleteData,
OnModifyData, or the controls pushing out data to the provider after
the user did an in-control modify on a record, or deleted data rhat
needs to be deleted from the main source right?

BTW, wx.Validator has TransferDataToWindow and TransferDataFromWindow methods, which seem to have been designed for this purpose. To be honest, despite the odd name choice, I think wx.Validator might provide a good base class for the control <-> source data transfer and validation classes. You might want to take a look. (Maybe we could do "wx.DataField = wx.Validator" so that the class will have a more appropriate sounding name. :wink: The use of validators might also provide for easy subclassing, such as having EmailDataField deriving from TextDataField, etc., and moreover, you can just 'plug' them into any wx.Window derived class with no extra glue code.

This is just some brainstorming, though, I haven't thought about this too seriously. :wink:

Thanks,

Kevin

···

On Apr 20, 2007, at 2:11 AM, Jorgen Bodde wrote:

We might be on to something here :wink:

- Jorgen

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

[snip]

As a side note, IMHO persistence should be implemented at the
wx.Window level, as it's really desirable for just about any window/
control under any situation. e.g. we'd have some base methods like
LoadState() and SaveState, which would use wxConfig and save/load any
persistent properties when called. Controls like wxListCtrl or your
subclass would then override the method and add the persistent
properties you want to store.

If you go this direction, please don't use wxConfig. Under certain
circumstances it is not thread safe and can cause segfaults.

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:47769:200602:nmkejbkeoodckphegicd

- Josiah

···

Kevin Ollivier <kevino@theolliviers.com> wrote:

Hi Josiah,

[snip]

As a side note, IMHO persistence should be implemented at the
wx.Window level, as it's really desirable for just about any window/
control under any situation. e.g. we'd have some base methods like
LoadState() and SaveState, which would use wxConfig and save/load any
persistent properties when called. Controls like wxListCtrl or your
subclass would then override the method and add the persistent
properties you want to store.

If you go this direction, please don't use wxConfig. Under certain
circumstances it is not thread safe and can cause segfaults.

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:47769:200602:nmkejbkeoodckphegicd

Since I can't get access to your code example from the above link, I can't really see what exactly was going on in your case, but do you mean to say that you can't call wx.Config from threads (which I somewhat expected, as very little of wx is thread-safe), or that wx.Config causes problems in a threaded app even when you're 100% sure you don't call it from any threads?

I use wx.Config and threads in my own apps and I've never run into any difficulty, so are you certain the issue wasn't specific to your own code?

Regards,

Kevin

···

On Apr 20, 2007, at 12:37 PM, Josiah Carlson wrote:

Kevin Ollivier <kevino@theolliviers.com> wrote:

- Josiah

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Josiah Carlson wrote:

[snip]

As a side note, IMHO persistence should be implemented at the wx.Window level, as it's really desirable for just about any window/ control under any situation. e.g. we'd have some base methods like LoadState() and SaveState, which would use wxConfig and save/load any persistent properties when called. Controls like wxListCtrl or your subclass would then override the method and add the persistent properties you want to store.

If you go this direction, please don't use wxConfig. Under certain
circumstances it is not thread safe and can cause segfaults.

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:47769:200602:nmkejbkeoodckphegicd

I think an abstract model would be better as then the source of the data values could be anything. There could always be a sample implementation of the model that uses a wx.Config.

Also, I like the idea of using a set of mix-in classes for handling this. That way it would be super easy to combine the data awareness with any standard or custom widget. For example, you could have a wx.data.ListBox class, and in the wx.data module all you would need for it is something like:

class ListBox(wx.ListBox, TabularStringDataMixin):
  pass

The various data aware mix-in classes can provide a method to associate the widget with a data model and a value or collection of values in the model. Once that is called then it can also set up whatever plumbing is needed to handle the data transfer. Using validators for this would be one way to approach it, but then the programmer would not be able to use their own validator for it's other capabilities (validation and key filtering). So perhaps we should just use pubsub right out of the gate, and define a pubsub protocol that all models should conform to in order to be compatible with these standard data mixins.

···

Kevin Ollivier <kevino@theolliviers.com> wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi Josiah,

>
> [snip]
>> As a side note, IMHO persistence should be implemented at the
>> wx.Window level, as it's really desirable for just about any window/
>> control under any situation. e.g. we'd have some base methods like
>> LoadState() and SaveState, which would use wxConfig and save/load any
>> persistent properties when called. Controls like wxListCtrl or your
>> subclass would then override the method and add the persistent
>> properties you want to store.
>
> If you go this direction, please don't use wxConfig. Under certain
> circumstances it is not thread safe and can cause segfaults.
>
> http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:
> 47769:200602:nmkejbkeoodckphegicd

Since I can't get access to your code example from the above link, I
can't really see what exactly was going on in your case, but do you
mean to say that you can't call wx.Config from threads (which I
somewhat expected, as very little of wx is thread-safe), or that
wx.Config causes problems in a threaded app even when you're 100%
sure you don't call it from any threads?

It's the latter. wx.FileConfig is only used in the GUI thread, while a
secondary thread uses compiler.parse() repeatedly. By replacing
wx.FileConfig, I was able to prevent the crash in my own code that may
do more or less continual compiler.parse() calls.

I've attached the code that I used over a year ago.

I can't seem to massage it into crashing using Python 2.3.5 and wxPython
2.8.3, but it reliably kills wxPython 2.6.3 . Maybe the issue was fixed
somewhere. I suspect that it may or may not have been an issue with the
stc parsing rutines being asked to stop before they were finished
parsing the data after a style change, but again, being that the error
went away when I implemented a wx.FileConfig variant in Python, I'm not
certain either way.

I use wx.Config and threads in my own apps and I've never run into
any difficulty, so are you certain the issue wasn't specific to your
own code?

I've attached the code that was used, which is fewer than 60 lines. If
you can find where the code that I wrote was in error, please let me
know.

- Josiah

kill_gui.zip (18 KB)

···

Kevin Ollivier <kevino@theolliviers.com> wrote:

On Apr 20, 2007, at 12:37 PM, Josiah Carlson wrote:
> Kevin Ollivier <kevino@theolliviers.com> wrote:

Hi Josiah,

[snip]

I use wx.Config and threads in my own apps and I've never run into
any difficulty, so are you certain the issue wasn't specific to your
own code?

I've attached the code that was used, which is fewer than 60 lines. If
you can find where the code that I wrote was in error, please let me
know.

Sorry, I should have phrased my question better. What I meant to ask was whether you found that any threading code at all would lead to a crash when using wxFileConfig, or if only running this specific threading code would cause the crash. i.e. I was trying to determine if you had isolated what particular functions/calls or code paths that were leading to the crash. I don't think there was an error on your part, but there's a big difference between "this code won't work at all if you use Python threads" and "in this specific instance, something is causing wx.FileConfig to crash".

In any case, it does seem the problem is fixed in 2.8, which is good to hear. I'm not stuck on using wx.Config or anything, I was more curious about figuring out how prevalent this wx.FileConfig + threads problem was since I hadn't run into it myself.

Thanks,

Kevin

···

On Apr 20, 2007, at 5:30 PM, Josiah Carlson wrote:

- Josiah
<kill_gui.zip>
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

I could only get it to reliably crash when using compiler.parse(), the
STC, and wx.FileConfig. I suspected at the time that it was a
malloc/free interaction between wx.FileConfig and the compiler module,
but now I think it may also have been an issue with the StyledTextCtrl's
parser. It's hard to tell for sure, but removing wx.FileConfig seemed
to fix it, and I wasn't able to force a crash otherwise when using
threads with wxPython (as long as I was using proper synchronization).

- Josiah

···

Kevin Ollivier <kevino@theolliviers.com> wrote:

Hi Josiah,

On Apr 20, 2007, at 5:30 PM, Josiah Carlson wrote:

[snip]

>
>> I use wx.Config and threads in my own apps and I've never run into
>> any difficulty, so are you certain the issue wasn't specific to your
>> own code?
>
> I've attached the code that was used, which is fewer than 60
> lines. If
> you can find where the code that I wrote was in error, please let me
> know.

Sorry, I should have phrased my question better. What I meant to ask
was whether you found that any threading code at all would lead to a
crash when using wxFileConfig, or if only running this specific
threading code would cause the crash. i.e. I was trying to determine
if you had isolated what particular functions/calls or code paths
that were leading to the crash. I don't think there was an error on
your part, but there's a big difference between "this code won't work
at all if you use Python threads" and "in this specific instance,
something is causing wx.FileConfig to crash".

Jorgen Bodde wrote:

...
We might be on to something here :wink:

I think so too!

I won't be any help in coding something like this, but would be very interested in replacing my home made spaghetti code using validators with something like this.

Very wiling to help testing this.

It would be nice if it can be done in a way that GUI generators like Boa "can use it", i.e. provide access to setting whatever needs to be set in the property inspector for e.g. a ListCtrl or a TextCtrl etc.

Werner