wxcode-users Mailing List for wxCode - wxWidgets components (Page 46)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I've tracked down the bug and fixed it, see patch:
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1369702&group_=
id=3D51305&atid=3D462818

Regards,
Bryan Petty

Patches item #1369702, was opened at 2005-11-29 19:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462818&aid=1369702&group_id=51305

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan Petty (bpetty)
Assigned to: Nobody/Anonymous (nobody)
Summary: [wxTreeListCtrl] Bugfix for EnsureVisible on new items

Initial Comment:
The Bug: Positions stored in each wxTreeListItem are
not calculated on new items until OnPaint. This becomes
a problem if you want to scroll to the new item before
OnPaint after you've created it (ie: calling
EnsureVisible on your new item).

Without this patch, the current code doesn't check for
this and will scroll the window to (0,0) (the initial
position values for all new wxTreeListItems). While
there's a couple ways this could of been fixed, this
patch takes the non-obtrusive route fixing the problem
without requiring changes in code that uses
wxTreeListCtrl as well as avoiding any current API changes.

The Patch: This code simply adds a variable to
wxTreeListItem to keep track of when the positions have
been calculated. wxTreeListMainWindow was then changed
to update that value after calculating the positions
via either CalculatePositions() or during OnPaint()
(PaintLevel() to be specific). EnsureVisible() was then
changed to check if the item passed in has had it's
positions calculated. If it hasn't, it calculates them
(using CalculatePositions()), then continues to scroll
to the item. This should avoid adding any unnecessary
calculations slowing down existing code unless those
calculations are necessary to ensure an item is visible.

Please note that I didn't look through the rest of the
functions to check if any others are guilty of using
un-calculated wxTreeListItem positions like
EnsureVisible was, and it's possible other
functionality needs to be changed to do the same. So if
the same problem comes up elsewhere, this should be a
good place to look.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=462818&aid=1369702&group_id=51305

I'm having trouble getting EnsureVisible to work on any new items I've
just added to my wxTreeListCtrl. I've played with the sample, and
found that it also doesn't work with new items inserted into the
wxTreeListCtrl. The problem seems to be that m_x, m_y, etc haven't
been calculated on new items just inserted. EnsureVisible calls to
those items will actually scroll the window back to (0,0).

There is one case where it does work on a new item however (and those
wxTreeListItem values have been calculated). That's whenever the new
item added is the first child of a parent item (though I'm still not
sure why it works in this case).

I have been assuming the call to wxYieldIfNeeded() in EnsureVisible
(if m_dirty) is there to make sure those values are calculated on new
items, but it doesn't seem to help. I've also tried a call to
wxYield() in my code after inserting the new item, but before calling
EnsureVisible. Nothing so far has helped.

The behaviour is the same in both wxWidgets 2.6.1 as well as 2.6.2.
I've played with this on an older released version of wxTreeListCtrl
as well as CVS with no change (on that note, some kind of version info
would be nice to track changes of wxTreeListCtrl). This can all be
reproduced by adding an EnsureVisible call to the
AppFrame::OnInsertItem method in the wxTreeListCtrl sample in CVS on
the new wxTreeListItem returned from InsertItem().

Regards,
Bryan Petty

On 11/24/05, Otto Wyss <ott...@or...> wrote:
> Carl Godkin wrote:
>
> >Has anyone managed to implement dragging tree list control items around
> >with some sort of feedback?  The begin and end drag events seem to work,
> >but there's no visual feedback during the drag.
> >
> >
> >
> I've implemented drag&drop in the wyoFiler (see
> "http://wyodesktop.sourceforge.net/index.php?pade=3Dfilemgr.html"), there
> is a small rectangle attached to the cursor when dragging. This seems
> standard when a copy action is done.

Thanks very much for the great example!  It's just what I needed to see.

carl

Otto Wyss wrote:

> True, the root item should always be expanded if hidden. I've added 
> the above statements in the AddRoot function since this is IMO the 
> better place. So far it seems to work in the TorMgr.
>
I reworked the hidden root again so it stays expanded in all cases 
(hopefully). Please check again.

O. Wyss

-- 
Application guidelines: http://freshmeat.net/projects/wyoguide/
Cross-platform Editor: http://freshmeat.net/projects/wyoeditor/
Cross-platform Filemanager http://freshmeat.net/projects/wyofiler/

Carl Godkin wrote:

>Has anyone managed to implement dragging tree list control items around
>with some sort of feedback?  The begin and end drag events seem to work,
>but there's no visual feedback during the drag.
>
>  
>
I've implemented drag&drop in the wyoFiler (see 
"http://wyodesktop.sourceforge.net/index.php?pade=filemgr.html"), there 
is a small rectangle attached to the cursor when dragging. This seems 
standard when a copy action is done.

O. Wyss

-- 
Application guidelines: http://freshmeat.net/projects/wyoguide/
Cross-platform Editor: http://freshmeat.net/projects/wyoeditor/
Cross-platform Filemanager http://freshmeat.net/projects/wyofiler/

Hi,

Has anyone managed to implement dragging tree list control items around
with some sort of feedback?  The begin and end drag events seem to work,
but there's no visual feedback during the drag.

With a MSW tree control, you get very nice feedback showing kind of
a faint version of the item being dragged.  With the generic tree control, =
the
cursor changes to a target and that's about it, at least under Windows.
But with the tree list control, there is no feedback, at least in my progra=
m.

Has anyone done this?  Thanks,

carl

Carl Godkin wrote:

>    if (!HasFlag(wxTR_HIDE_ROOT) && (styles & wxTR_HIDE_ROOT))
>    {
>        // if we will hide the root, make sure children are visible
>        m_anchor->SetHasPlus();
>        m_anchor->Expand();
>    }
>
>  
>
True, the root item should always be expanded if hidden. I've added the 
above statements in the AddRoot function since this is IMO the better 
place. So far it seems to work in the TorMgr.

O. Wyss

-- 
Application guidelines: http://freshmeat.net/projects/wyoguide/
Cross-platform Editor: http://freshmeat.net/projects/wyoeditor/
Cross-platform Filemanager http://freshmeat.net/projects/wyofiler/

On 11/23/05, Otto Wyss <ott...@or...> wrote:
> Carl Godkin wrote:
>
> >When I create the control and populate it with more items than fit verti=
cally,
> >I don't get a scrollbar right away until I click on one of the items.  T=
his
> >happens both on Windows and Linux so I presume it's intentional.  Howeve=
r,
> >I'd like to always show the vertical scrollbar so that the user knows th=
ere are
> >more items below.
> >
> >
> >
> I've seen this as well lately and think it's something wrong within
> wxWidgets but I'm not sure. I haven't seen it in any of my old apps,
> only in the new TorMgr I write for the Tor GUI contest. So it might be a
> problem of 2.6.2, again I'm not sure.
>
> >Is there some way I can force this?

I looked into this and found the problem, I think.

The member function wxTreeListMainWindow::AdjustMyScrollbars()
calls GetSize() on the root item.  However wxTreeListItem::GetSize()
doesn't think the root item is expanded, so all you get is the (hidden)
root item's size.

I worked around this by adding Expand(rootId) after I populate the tree
initially and now the vertical scrollbar appears as I think it should.

This even makes sense to me.  I wondered if this problem would
happen in the generic tree control which was apparently  the model
for the tree list control but found that there is a little code we might wa=
nt
to add to avoid this problem.  Notice the difference here:

void wxTreeListMainWindow::SetWindowStyle (const long styles) {
    // right now, just sets the styles.  Eventually, we may
    // want to update the inherited styles, but right now
    // none of the parents has updatable styles
    m_windowStyle =3D styles;
    m_dirty =3D true;
}

void wxGenericTreeCtrl::SetWindowStyle(const long styles)
{
    if (!HasFlag(wxTR_HIDE_ROOT) && (styles & wxTR_HIDE_ROOT))
    {
        // if we will hide the root, make sure children are visible
        m_anchor->SetHasPlus();
        m_anchor->Expand();
        CalculatePositions();
    }

    // right now, just sets the styles.  Eventually, we may
    // want to update the inherited styles, but right now
    // none of the parents has updatable styles
    m_windowStyle =3D styles;
    m_dirty =3D true;
}

(Note that m_anchor in the generic tree control is the same as m_rootItem
in the tree list control.)

Thanks,

carl

Carl Godkin wrote:

>When I create the control and populate it with more items than fit vertically,
>I don't get a scrollbar right away until I click on one of the items.  This
>happens both on Windows and Linux so I presume it's intentional.  However,
>I'd like to always show the vertical scrollbar so that the user knows there are
>more items below.
>
>  
>
I've seen this as well lately and think it's something wrong within 
wxWidgets but I'm not sure. I haven't seen it in any of my old apps, 
only in the new TorMgr I write for the Tor GUI contest. So it might be a 
problem of 2.6.2, again I'm not sure.

>Is there some way I can force this?
>
>  
>
Either try to use the vertical scroll bar style for always showing it or 
send a size event to it, maybe a simple SetSize outside the constructor 
might be sufficiant.

>By the way, I am using the wxTR_HIDE_ROOT style in my interface.  I mention
>this since there used to be some bugs related to this style at one time.
>
>  
>
Ditto I, so far all my trees use this style.

O. Wyss

-- 
Application guidelines: http://freshmeat.net/projects/wyoguide/
Cross-platform Editor: http://freshmeat.net/projects/wyoeditor/
Cross-platform Filemanager http://freshmeat.net/projects/wyofiler/

Hi,

I'm using wxTreeListCtrl on both Linux and Windows with wx 2.6.1.

There is one problem I can't quite figure out though I have to admit I
have not looked into it in detail yet but was hoping someone would
know immediately what I was doing wrong.

When I create the control and populate it with more items than fit vertical=
ly,
I don't get a scrollbar right away until I click on one of the items.  This
happens both on Windows and Linux so I presume it's intentional.  However,
I'd like to always show the vertical scrollbar so that the user knows there=
 are
more items below.

Is there some way I can force this?

By the way, I am using the wxTR_HIDE_ROOT style in my interface.  I mention
this since there used to be some bugs related to this style at one time.

Thanks,

carl

I forgot to say that %WXWIN% doesn't do anything useful on linux since that syntax is not 
used at all to expand variables.

Maybe that adding a

     -I$(wx-config --prefix)/share/bakefile/presets

to your Bakefiles.bkgen will do the trick on linux, but I think it's much more easier to 
install bakefile system-wide and let it search its default folder 
/usr/local/share/bakefile/presets...

Francesco

Hi,

John Labenski wrote:
> On 11/20/05, Angelo's Gmail <ama...@gm...> wrote:
>> These are more or less snippets of code that can be used for different
>>things, and not necessarily all used together.  Maybe we should have a
>>special area called wxSnippets.  Though it appears someone had this idea
>>last year: http://sourceforge.net/projects/snippets/  We
>>could still have a snippets component I think.
> 
> 
> That is a weird project, the code snippets are for all sorts of
> arbitrary things and every conceivable language. Almost all of my
> stuff depends on wxWidgets.
anyway the idea of a wxSnippets component is not so bad...

> It is an interesting idea though. I think it *might* make sense to
> create a some components for projects that are at most two source and
> header files that would be open to anyone.
I know that Jorgen has a "code dump" section on the wxForum where this kind of very-small 
snippets can be placed.

I think it's not easy to maintain code in a forum but many people seem to do it:
     http://wxforum.shadonet.com/viewforum.php?f=20
this is also probably because their code doesn't need much maintainance...

I think that to host wxWidgets code one currently can choose among:
1) The Code dump in wxForum for very small pieces of code
2) wxCode for medium components
3) a new SF.net project for large projects

Francesco

Hi,

John Labenski wrote:
> I just downloaded bakefile 1.9.1 for linux configured, make, make
> installed it and and when I try to run bakefile_gen I get this error
> for the component wxstedit that I've copied all the stuff from
> wxCode/build from.  I can run bakefile_gen using bakefile in DOS.
> 
> (note: I installed it to the same directory that I tgunziped it, this
> used to work w/ bakefile 1.8)
> 
> [john@localhost build]$ export
> WXWIN=/home/john/wx/wxWidgets/wxCVS_26/wxWidgets
> [john@localhost build]$ ~/lib/bakefile-0.1.9.1/bin/bakefile_gen
> [1/7] generating watcom from stedit.bkl
> /home/john/cvs/wxCode/wxCode/build/bakefiles/wxhacks.bkl:20: error:
> can't find file 'presets/wx.bkl' in
> /home/john/cvs/wxCode/wxCode/build/bakefiles:/home/john/lib/bakefile-0.1.9.1/share/bakefile/rules:/home/john/lib/bakefile-0.1.9.1/share/bakefile/output:/home/john/lib/bakefile-0.1.9.1/share/bakefile:%WXWIN%/build/bakefiles/wxpresets
>     included from /home/john/cvs/wxCode/wxCode/build/bakefiles/wxhacks.bkl:20
>     included from /home/john/cvs/wxCode/wxCode/build/bakefiles/defaults.bkl:78
>     included from
> /home/john/cvs/wxCode/wxCode/components/wxstedit/build/stedit.bkl:11
> [bakefile_gen] error: bakefile exited with error
the problem is that you should have wxpresets installed in your bakefile folder.
That is, you should have wx.bkl, wx_unix.bkl and wx_win32.bkl in

    ~/lib/bakefile-0.1.9.1/presets

Wehn installing wxWidgets, since version 2.6.1, it copies the wxpresets in

    $prefix/share/bakefile/presets

which usually is the folder where bakefile is installed.
If you use bakefile from a local folder like ~/lib/bakefile-0.1.9.1, then you need to 
manually copy the wxpresets in its presets folder.

In any case I strongly suggest you to
1) run "make install" in bakefile folder so that you have it installed system-wide
2) copy in /usr/local/share/bakefile/presets the very latest wxpresets taken from 
wxWidgets CVS as they fix some bugs from previous versions.

Francesco

On 11/21/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi all,
>
>    I would like to inform everyone using acregen.sh script that I committ=
ed to the build\
> folders of all bakefile-based components the new acregen.sh script.
> So, do a cvs update on your repositories before using it ;)

Cool.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I just downloaded bakefile 1.9.1 for linux configured, make, make
installed it and and when I try to run bakefile_gen I get this error
for the component wxstedit that I've copied all the stuff from
wxCode/build from.  I can run bakefile_gen using bakefile in DOS.

(note: I installed it to the same directory that I tgunziped it, this
used to work w/ bakefile 1.8)

[john@localhost build]$ export
WXWIN=3D/home/john/wx/wxWidgets/wxCVS_26/wxWidgets
[john@localhost build]$ ~/lib/bakefile-0.1.9.1/bin/bakefile_gen
[1/7] generating watcom from stedit.bkl
/home/john/cvs/wxCode/wxCode/build/bakefiles/wxhacks.bkl:20: error:
can't find file 'presets/wx.bkl' in
/home/john/cvs/wxCode/wxCode/build/bakefiles:/home/john/lib/bakefile-0.1.9.=
1/share/bakefile/rules:/home/john/lib/bakefile-0.1.9.1/share/bakefile/outpu=
t:/home/john/lib/bakefile-0.1.9.1/share/bakefile:%WXWIN%/build/bakefiles/wx=
presets
    included from /home/john/cvs/wxCode/wxCode/build/bakefiles/wxhacks.bkl:=
20
    included from /home/john/cvs/wxCode/wxCode/build/bakefiles/defaults.bkl=
:78
    included from
/home/john/cvs/wxCode/wxCode/components/wxstedit/build/stedit.bkl:11
[bakefile_gen] error: bakefile exited with error

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Unfortunately bakefile_gen doesn't understand -I to add include dirs?

[john@localhost build]$ ~/lib/bakefile-0.1.9.1/bin/bakefile_gen -I
/home/john/wx/wxWidgets/wxCVS_26/wxWidgets

usage: bakefile_gen [options]
bakefile_gen: error: no such option: -I

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Does any use bakefile_gen in linux or just DOS?

Thanks,
    John Labenski

That is a good idea. I like to go into the setup.h and remove the stuff I
never use. I suspect your setup.h would work in the same fashion. Great
idea!

--angelo

On 11/21/05, John Labenski <jla...@gm...> wrote:
>
> > INHO, the best thing should be including all the components into a
> dynamic
> > library,
> > you can manitain a single object, and users will share a single
> component.
>
> I've changed my mind, I now think that it best to just have one
> library as you say. It'll really be a lot easier for me to maintain
> and use. There will just be a single library and the linker can strip
> out the unused stuff.
>
> I can also use #if USE_SOMECLASSNAME and a setup.h file to let people
> pick and choose what they want. There's a discussion about how best to
> use a setup.h file on wx-users and wxlua-users...
>
> Regards,
> John Labenski
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id=16845&opclick
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>

> INHO, the best thing should be including all the components into a dynami=
c
> library,
> you can manitain a single object, and users will share a single component=
.

I've changed my mind, I now think that it best to just have one
library as you say. It'll really be a lot easier for me to maintain
and use. There will just be a single library and the linker can strip
out the unused stuff.

I can also use #if USE_SOMECLASSNAME and a setup.h file to let people
pick and choose what they want. There's a discussion about how best to
use a setup.h file on wx-users and wxlua-users...

Regards,
    John Labenski

Hi all,

   I would like to inform everyone using acregen.sh script that I committed to the build\ 
folders of all bakefile-based components the new acregen.sh script.
So, do a cvs update on your repositories before using it ;)

This adds two useful features:
1) it checks the aclocal version you are using and if < 1.9.6, then it tells you to update 
your automake package. In fact, since 1.9.6 is quite new many probably still have older 
versions (which do not work). This will help not to loose time against the strange error 
message given out by aclocal < 1.9.6

2) ability to be run from any dir: instead of always doing:

cd build
./acregen.sh
cd ..
./configure

to try out the new configure script, you can now do just

build/acregen.sh
./configure

Hope this will be useful,
Francesco

>I have a project that has a variety of different classes, data
> containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
> button, etc
>
> http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt
>
> I would hate to add each as their own little one or two file project
> (more maintenance for me),  does anyone have any thoughts on how we
> should approach this? Does it make sense for me to just add this as
> is.

INHO, the best thing should be including all the components into a dynamic 
library,
you can manitain a single object, and users will share a single component.

Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.koansoftware.com    |    www.klinux.org

On 11/20/05, Angelo's Gmail <ama...@gm...> wrote:
> What about wxGizmos?  wxExtras?

Gizmos is already in wxWidgets in the contrib dir and wxExtras, like
wxThings, is probably too vague.

>  These are more or less snippets of code that can be used for different
> things, and not necessarily all used together.  Maybe we should have a
> special area called wxSnippets.  Though it appears someone had this idea
> last year: http://sourceforge.net/projects/snippets/  We
> could still have a snippets component I think.

That is a weird project, the code snippets are for all sorts of
arbitrary things and every conceivable language. Almost all of my
stuff depends on wxWidgets.

It is an interesting idea though. I think it *might* make sense to
create a some components for projects that are at most two source and
header files that would be open to anyone. The problem is that you can
loose control over it easily. By control, I mean that as wxWidgets
changes so too should all the files in these components and if some of
the files stop compiling the whole component is dead. If the original
author disappears, the maintenance falls on the others. Maybe this
wouldn't happen, but if did it could become a headache to have to
maintain others work. To be frank, I'd be wary of it, but it could
work if every member of the component was reasonably active.

Regards,
    John Labenski

What about wxGizmos? wxExtras?

These are more or less snippets of code that can be used for different
things, and not necessarily all used together. Maybe we should have a
special area called wxSnippets. Though it appears someone had this idea las=
t
year: http://sourceforge.net/projects/snippets/ We could still have a
snippets component I think.

--angelo

On 11/20/05, John Labenski <jla...@gm...> wrote:
>
> On 11/20/05, Francesco Montorsi <f18...@ya...> wrote:
> > >>I have a project that has a variety of different classes, data
> > >>containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
> > >>button, etc
> > >>
> > >>http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt
> > >>
> > >>I would hate to add each as their own little one or two file project
> > >>(more maintenance for me), does anyone have any thoughts on how we
> > >>should approach this? Does it make sense for me to just add this as
> > >>is.
> > >
> > > I would propose to add wxThings as is, since you can assign to it all
> > > categories that wxThings fits in.
> > hmmm, I think that wxThings is really *too* generic; I strongly suggest
> to split up the
> > things in two components: one for data containers and one for controls.
>
> That's probably best.
>
> > I cannot think to any suitable name for such components, though... :-(
>
> Heh, my wxThings was originally called wxWidgets when wxWidgets was
> wxWindows.
>
> These are pretty generic names, maybe just wxdata and wxcontrols?
> They're not taken yet. :)
>
> -John
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id=16845&opclick
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
>

On 11/20/05, Francesco Montorsi <f18...@ya...> wrote:
> >>I have a project that has a variety of different classes, data
> >>containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
> >>button, etc
> >>
> >>http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt
> >>
> >>I would hate to add each as their own little one or two file project
> >>(more maintenance for me),  does anyone have any thoughts on how we
> >>should approach this? Does it make sense for me to just add this as
> >>is.
> >
> > I would propose to add wxThings as is, since you can assign to it all
> > categories that wxThings fits in.
> hmmm, I think that wxThings is really *too* generic; I strongly suggest t=
o split up the
> things in two components: one for data containers and one for controls.

That's probably best.

> I cannot think to any suitable name for such components, though... :-(

Heh, my wxThings was originally called wxWidgets when wxWidgets was wxWindo=
ws.

These are pretty generic names, maybe just wxdata and wxcontrols?
They're not taken yet. :)

-John

Hi,

Ulrich Telle wrote:
>>I have a project that has a variety of different classes, data
>>containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
>>button, etc
>>
>>http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt
>>
>>I would hate to add each as their own little one or two file project
>>(more maintenance for me),  does anyone have any thoughts on how we
>>should approach this? Does it make sense for me to just add this as
>>is.
> 
> 
> I would propose to add wxThings as is, since you can assign to it all 
> categories that wxThings fits in.
hmmm, I think that wxThings is really *too* generic; I strongly suggest to split up the 
things in two components: one for data containers and one for controls.

I cannot think to any suitable name for such components, though... :-(

Francesco

> I have a project that has a variety of different classes, data
> containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
> button, etc
> 
> http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt
> 
> I would hate to add each as their own little one or two file project
> (more maintenance for me),  does anyone have any thoughts on how we
> should approach this? Does it make sense for me to just add this as
> is.

I would propose to add wxThings as is, since you can assign to it all 
categories that wxThings fits in.

Regards,

Ulrich Telle
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341

I have a project that has a variety of different classes, data
containers, a spinctrl, a popup combobox for bitmaps, bitmap toggle
button, etc

http://www.lehigh.edu/~jrl1/wxwidgets/wxThings/README.txt

I would hate to add each as their own little one or two file project
(more maintenance for me),  does anyone have any thoughts on how we
should approach this? Does it make sense for me to just add this as
is.

Regards,
    John Labenski

2004	Jan	Feb	Mar (5)	Apr (7)	May (11)	Jun (19)	Jul (9)	Aug (5)	Sep (6)	Oct (18)	Nov (9)	Dec (20)
2005	Jan (8)	Feb (1)	Mar (5)	Apr (1)	May (1)	Jun (73)	Jul (128)	Aug (39)	Sep (91)	Oct (24)	Nov (42)	Dec (37)
2006	Jan (8)	Feb (22)	Mar (15)	Apr (44)	May (13)	Jun (9)	Jul (19)	Aug (35)	Sep (28)	Oct (53)	Nov (19)	Dec (29)
2007	Jan (28)	Feb (37)	Mar (86)	Apr (14)	May (48)	Jun (2)	Jul (20)	Aug (19)	Sep (19)	Oct (8)	Nov (11)	Dec (11)
2008	Jan (3)	Feb (1)	Mar (22)	Apr (7)	May (3)	Jun	Jul (16)	Aug (10)	Sep (5)	Oct (3)	Nov (24)	Dec (9)
2009	Jan (14)	Feb (4)	Mar (16)	Apr (13)	May (22)	Jun (3)	Jul (3)	Aug (8)	Sep (20)	Oct (18)	Nov (5)	Dec (11)
2010	Jan (4)	Feb (4)	Mar (7)	Apr (5)	May (41)	Jun (15)	Jul (3)	Aug (2)	Sep (9)	Oct (7)	Nov (8)	Dec (3)
2011	Jan (28)	Feb (29)	Mar (3)	Apr (7)	May (3)	Jun (1)	Jul (1)	Aug (2)	Sep	Oct (4)	Nov (7)	Dec
2012	Jan (3)	Feb (4)	Mar (3)	Apr (3)	May (2)	Jun (2)	Jul (3)	Aug (3)	Sep (2)	Oct (3)	Nov	Dec (1)
2013	Jan	Feb	Mar (4)	Apr (1)	May	Jun	Jul	Aug (2)	Sep	Oct	Nov (7)	Dec (5)
2014	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (5)	Dec
2015	Jan (7)	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2019	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec

wxcode-users Mailing List for wxCode - wxWidgets components (Page 46)

wxcode-users — Submission, Questions, Information