Implementing a wx.TreeCtrl Built With User Input

wxPython Users
1

tacao,

   That's nice. I had no idea how to organize the widgets and your suggestion
will certainly meet the need. I think that I'll just use a horizontal box
sizer for the TreeCtrl and ListCtrl rather than a splitter window. There's no
need to resize the two windows.

   The one needed addition is a second add button for top-level categories. It
might also make it easier to provide add/delete buttons for each side; that
is, one set for categories/sub-categories and the other set for components.
That would eliminate a potential source of confusion and error.

   Excellent thinking. Thank you very much.

Rich

···

On Fri, 25 Nov 2005, E. A. Tacao wrote:

+---------------------------------------+
> ToolBar (buttons): Add, Delete |
+-------------------+-------------------+
> Splitter (left): | Splitter (right): |
> TreeCtrl | ListCtrl |
+-------------------+-------------------+

TreeCtrl is the tree of categories; the ListCtrl lists the components under
the category that's currently selected on the treectrl.

If the tree has focus, clicking on "Add" will add a sub-category to the
tree under the category currently selected on the tree. If the ListCtrl has
focus, a new component will be added to the category/sub-category currently
selected. "Delete" has an analogous behavior.

To make things fancier you could further implement drag'n'drop operations,
context menus, etc.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

2

> +---------------------------------------+
> > ToolBar (buttons): Add, Delete |
> +-------------------+-------------------+
> > Splitter (left): | Splitter (right): |
> > TreeCtrl | ListCtrl |
> +-------------------+-------------------+
>
> TreeCtrl is the tree of categories; the ListCtrl lists the components under
> the category that's currently selected on the treectrl.
>
> If the tree has focus, clicking on "Add" will add a sub-category to the
> tree under the category currently selected on the tree. If the ListCtrl has
> focus, a new component will be added to the category/sub-category currently
> selected. "Delete" has an analogous behavior.
>
> To make things fancier you could further implement drag'n'drop operations,
> context menus, etc.

tacao,

   That's nice. I had no idea how to organize the widgets and your suggestion
will certainly meet the need. I think that I'll just use a horizontal box
sizer for the TreeCtrl and ListCtrl rather than a splitter window. There's no
need to resize the two windows.

You would be surprised when people want to resize window sections.
Switching between the two is not that difficult if you find yourself
wanting/needing to.

   The one needed addition is a second add button for top-level categories. It
might also make it easier to provide add/delete buttons for each side; that
is, one set for categories/sub-categories and the other set for components.
That would eliminate a potential source of confusion and error.

Not really. If you have a 'category' selected on the left side, then
stuff on the right are the contents, and adding a 'sub-category' would
obviously add a sibling to the contents on the right side. If you have
a 'sub-category' selected on the right side, and you add, then it would
again make sense to create a sibling of the stuff on the right side
(think of how file managers work).

If you REALLY want to differentiate based on what is selected, you can
use obj.FindFocus()==treectrl, etc., to discover which side actually has
the focus, and what, if any, is selected.

- Josiah

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Fri, 25 Nov 2005, E. A. Tacao wrote:

3

You would be surprised when people want to resize window sections.
Switching between the two is not that difficult if you find yourself
wanting/needing to.

Josiah,

   Nothing surprises me any longer about what people want or do.

Not really. If you have a 'category' selected on the left side, then stuff
on the right are the contents, and adding a 'sub-category' would obviously
add a sibling to the contents on the right side. If you have a
'sub-category' selected on the right side, and you add, then it would again
make sense to create a sibling of the stuff on the right side (think of how
file managers work).

   I did not communicate well.

   If there's no category shown, then the Add button will obviously add a new
category. But, if there are already categories listed, and the Add button is
clicked, how does the application know if it is to be a new category or a
sub-category of the one highlighted that is to be added? That's why I think
there needs to be two Add buttons: Category and Sub-Category.

If you REALLY want to differentiate based on what is selected, you can use
obj.FindFocus()==treectrl, etc., to discover which side actually has the
focus, and what, if any, is selected.

   Germane to your initial point about what people want, keep in mind that
when it comes to the competition between artificial intelligence and natural
stupidity, the latter wins every time. :slight_smile:

   Without doubt, someone will have the cursor on the wrong side and be upset
that the "stupid application" didn't know what he meant to do.

Rich

···

On Fri, 25 Nov 2005, Josiah Carlson wrote:

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

4

> Not really. If you have a 'category' selected on the left side, then stuff
> on the right are the contents, and adding a 'sub-category' would obviously
> add a sibling to the contents on the right side. If you have a
> 'sub-category' selected on the right side, and you add, then it would again
> make sense to create a sibling of the stuff on the right side (think of how
> file managers work).

   I did not communicate well.

   If there's no category shown, then the Add button will obviously add a new
category. But, if there are already categories listed, and the Add button is
clicked, how does the application know if it is to be a new category or a
sub-category of the one highlighted that is to be added? That's why I think
there needs to be two Add buttons: Category and Sub-Category.

Anything selected on the left side should have a sub-category created
from the selected category when the add button is clicked. Note that I
use 'category' to reference the currently selected tree element on the
left, and 'sub-category' to reference its immediate children which are
displayed on the left AND on the right.

It also slipped my mind that the moment you click the 'add' button, you
would lose all focus information on whether the tree or list were
selected. With some EVT_FOCUS work, you can discover which was the last
of the two which were selected...

Now, this brings up the problem that if you have more than just the
button, tree, and list control, people may not be going directly from
the list/tree to that add button, so may forget what was most recently
selected, which re-affirms that whatever item is selected on the left
side, the 'add' button should add a child to it, REGARDLESS of what is
selected on the right side.

> If you REALLY want to differentiate based on what is selected, you can use
> obj.FindFocus()==treectrl, etc., to discover which side actually has the
> focus, and what, if any, is selected.

   Germane to your initial point about what people want, keep in mind that
when it comes to the competition between artificial intelligence and natural
stupidity, the latter wins every time. :slight_smile:

And trying to come up with a slightly different human interface than
what has already existed is not the best idea. Stick with what people
know.

You could have two buttons. On the left, it would read "add child", on
the right it would read "add sibling", but both would do the exact same
thing, add a child to the tree item selected on the left.

   Without doubt, someone will have the cursor on the wrong side and be upset
that the "stupid application" didn't know what he meant to do.

Be explicit with your button labels and help text, "clicking this button
will add a child to the currently selected item on the tree to the left,
effectively adding a sibling to the items on the right".

So, I'm sure you are getting tired of discussing this, so I would
suggest you implement what you think is intuitive. If/when this is
found to be unintuitive by you and/or your users, change it. If not,
then people apparently find the behavior of basically every modern file
manager to be unintuitive.

- Josiah

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Fri, 25 Nov 2005, Josiah Carlson wrote:

5

Hi to all,

As all of you know, one can build a dialog with an Information icon and an 'Ok' button the way below:

dlg = wx.MessageDialog(parent, message, title, style=wx.OK | wx.ICON_INFORMATION)

So I thought that I can get access to the system Icons through wxPython. Has someone the way for doing it?

I would like to use it in a wx.StaticBitmap or whatever permits it.

Thank you

Daniel

6

Look into wx.ArtProvider - it has a function called GetBitmap() that returns a bitmap of the specified built-in icon. There are a whole series of constants in the format wx.ART_* that will list the available icons.

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

···

On Nov 25, 2005, at 4:15 PM, Daniel Crespo wrote:

As all of you know, one can build a dialog with an Information icon and an 'Ok' button the way below:

dlg = wx.MessageDialog(parent, message, title, style=wx.OK | wx.ICON_INFORMATION)

So I thought that I can get access to the system Icons through wxPython. Has someone the way for doing it?

I would like to use it in a wx.StaticBitmap or whatever permits it.

7

I tried this:

wx.ArtProvider.GetBitmap("wx.ICON_INFORMATION")
but doesn't get the Bitmap :frowning:

I have this:

I'm retrieving a bitmap object from an xrc.

self.bmpInformacion =XRCCTRL(self,"bmpInformacion")
self.bmpInformacion.SetBitmap(wx.ArtProvider.GetBitmap("wx.ICON_INFORMATION"))

So I want the Information Icon be my bitmap.

It doesn't show any bitmap. When I get its size, I get wx.Size(0,0).

Any suggestions?

Daniel

···

----- Original Message ----- From: "Ed Leafe" <ed@leafe.com>
To: <wxPython-users@lists.wxwidgets.org>
Sent: Friday, November 25, 2005 5:26 PM
Subject: Re: [wxPython-users] How to use the predefined wx images

On Nov 25, 2005, at 4:15 PM, Daniel Crespo wrote:

As all of you know, one can build a dialog with an Information icon and an 'Ok' button the way below:

dlg = wx.MessageDialog(parent, message, title, style=wx.OK | wx.ICON_INFORMATION)

So I thought that I can get access to the system Icons through wxPython. Has someone the way for doing it?

I would like to use it in a wx.StaticBitmap or whatever permits it.

    Look into wx.ArtProvider - it has a function called GetBitmap() that returns a bitmap of the specified built-in icon. There are a whole series of constants in the format wx.ART_* that will list the available icons.

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

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

8

I tried this:

wx.ArtProvider.GetBitmap("wx.ICON_INFORMATION")
but doesn't get the Bitmap :frowning:

     That's because wx.ICON_INFORMATION isn't one of the wx.ART_* constants.

I'm retrieving a bitmap object from an xrc.

self.bmpInformacion =XRCCTRL(self,"bmpInformacion")
self.bmpInformacion.SetBitmap(wx.ArtProvider.GetBitmap("wx.ICON_INFORMATION"))

So I want the Information Icon be my bitmap.

It doesn't show any bitmap. When I get its size, I get wx.Size(0,0).

     That's not one of the icons provided currently by the ArtProvider class. I believe that it is a system icon on most platforms, not a wx-supplied icon. I don't think that there is any way to do this.

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

···

On Nov 25, 2005, at 4:58 PM, Daniel Crespo wrote:

9

Friday, November 25, 2005, 11:23:10 AM, Rich Shepard wrote:

I think that I'll just use a horizontal box sizer for the TreeCtrl
and ListCtrl rather than a splitter window. There's no need to
resize the two windows.

Perhaps. But if there's a lot of sub-sub-sub-subcategories one would
miss the ability of resizing the windows. Also, the app itself would
have to some magic with the TreeCtrl's horizontal scrollbar.

-- tacao

No bits were harmed during the making of this e-mail.

10

tacao,

   You're definitely correct. I've not explained the context because I don't
see the relevance of that. It's a specialized modeling application that will
not be in general use and there will be no more than one level of
sub-category.

   In most situations, we will be running this application on behalf of
clients because the most difficult and complex part is determining the core
structure. In some applications, the structure of the model changes with each
project. In other applications, the form of the model does not change, but
the specific input data do.

Rich

···

On Sat, 26 Nov 2005, E. A. Tacao wrote:

Perhaps. But if there's a lot of sub-sub-sub-subcategories one would miss
the ability of resizing the windows. Also, the app itself would have to
some magic with the TreeCtrl's horizontal scrollbar.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863