wxruby development - Jun 2007 - Wx::ToolBar#insert_tool

Hey guys,

Wx::ToolBar#insert_tool, is either not referenced right, or needs to be
updated.

1.)  Wx::ToolBar#insert_tool(size_t
pos, ToolBarToolBase tool) comes up with a No overloading function
type error, AKA 404 Not Found
2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap bitmap1,
Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object clientData nil,
String shortHelpString = "", String longHelpString = "") 
Should have a
reference also in the parameters to String label just after Integer toolId,
to conform with Wx::ToolBar#add_tool().

Just thought I''d give you guys a heads up on some of the stuff I found.
 More to come when I find it.

Mario Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-development/attachments/20070619/46f0cc9c/attachment.html

Hi Mario

As elsewhere, apologies for the delay in replying (on holiday, off line).

Mario Steele wrote:
> 1.)  Wx::ToolBar#insert_tool(size_t 
> pos, ToolBarToolBase tool) comes up with a No overloading function type
error, AKA 404 Not Found
>
This has been commented out in the SWIG source headers. I guess this is 
because we don''t support the ToolBarToolBase class.

I''m inclined to keep it this way and remove it from the documentation, 
rather than add a ToolBarTool class. With SWIG''s per-class overhead, 
porting all the C++ struct-like classes like this one is a source of 
bloat, IMO.
> 2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap 
> bitmap1, Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object 
> clientData = nil, String shortHelpString = "", String
longHelpString =
> "")  Should have a reference also in the parameters to String
label
> just after Integer toolId, to conform with Wx::ToolBar#add_tool().
>
Good spot. Looking at the 2.8.4 docs at

http://www.wxwidgets.org/manuals/2.8.4/wx_wxtoolbar.html#wxtoolbarinserttool

this appears to be documented wrongly in wxWidgets, but the actual wx 
headers are correct and include the label param. We''ve inherited that 
error, and I''ll correct it.
> Just thought I''d give you guys a heads up on some of the stuff I 
> found.  More to come when I find it.
It''s much appreciated - please keep sending them in.

cheers
alex

On 6/22/07, Alex Fenton <alex at pressure.to>
wrote:
>
> Hi Mario
>
> As elsewhere, apologies for the delay in replying (on holiday, off line).

Not a problem Alex, I understand the need to be away from the
computer, and on a vaca.

Mario Steele wrote:
> > 1.)  Wx::ToolBar#insert_tool(size_t
> > pos, ToolBarToolBase tool) comes up with a No overloading function
type
> error, AKA 404 Not Found
> >
> This has been commented out in the SWIG source headers. I guess this is
> because we don''t support the ToolBarToolBase class.
>
> I''m inclined to keep it this way and remove it from the
documentation,
> rather than add a ToolBarTool class. With SWIG''s per-class
overhead,
> porting all the C++ struct-like classes like this one is a source of
> bloat, IMO.
>
I can understand that, the only reason why I was looking into this, is cause
I''m working on a MUD/MUCK/MUSH/MUX/MOO (Refered to
here<http://en.wikipedia.com/wiki/MUCK>)
and I was creating my own Help Viewer, similar to Microsoft''s Old
HelpView32
system.  Part of the problem I was running into, was the fact that the Hide
button on the toolbar, needed to change text to Show, once the user hidden
the Sidebar that shows the search for topics, and Contents pages.  But, I
was getting fustrated with it, to the point that I finally just decided to
clean out the Toolbar, and re-create it, based upon the toggle of the page.
 Which seemed to work quite well.
> 2.) Wx::ToolBar#insert_tool(size_t pos, Integer toolId, Bitmap
> > bitmap1, Bitmap bitmap2 = NullBitmap, Boolean isToggle = false, Object
> > clientData = nil, String shortHelpString = "", String
longHelpString > > "")  Should have a reference also in the
parameters to String label
> > just after Integer toolId, to conform with Wx::ToolBar#add_tool().
> >
> Good spot. Looking at the 2.8.4 docs at
>
>
>
http://www.wxwidgets.org/manuals/2.8.4/wx_wxtoolbar.html#wxtoolbarinserttool
>
> this appears to be documented wrongly in wxWidgets, but the actual wx
> headers are correct and include the label param. We''ve inherited
that
> error, and I''ll correct it.

Yeah, seeing that now in wxWidgets'' documentation, I won''t
hold you to
the problem on that.  Oviously not your fault. LOL
> Just thought I''d give you guys a heads up on some of the stuff I
> > found.  More to come when I find it.
> It''s much appreciated - please keep sending them in.

While we''re on that subject, I was working on an XRC Dialog I created
for
Editing worlds in my client, and I had it setup with a TreeCtrl, and several
edit text fields.  For some reason, when I added the entry to the TreeCtrl,
with an Image List assigned, it would not display the images I had in the
list, no matter which method I went with.  I looked through all of the
demos, and they work fine in the Demos, but mine just wouldn''t work
with it.
 I tried directly creating the Bitmap, with
Wx::Bitmap.new("./path/to/image.png")
PNG or GIF being the format, and tried going the round about way, with Wx::
Image.new("./path/to/image.png") and then doing
Wx::Bitmap.new(theImage).
 Neither seemed to work.  Finally broke down, and decided to create a
ListCtrl in Icon Mode to set it up with, and make it more like a Windows
explorer type interface, with right click
editing properties on it for a Popup Menu.  Anything to add to what is up
with that?

And finally, another part of the problem, seem to also incure some kind of
segfault that I could not trace back to the source through GDB, that dealt
with the fact that when switching between items in the TreeCtrl, it would
set the value of an Item to the associated fields I had on the window.  It
also seemed to crash at random places, but always after so many times
switching between the items in the TreeCtrl.  I checked the debug, and it
always seemed to crash somewhere where Ruby was trying to get the text, and
set the value of it.  But the text was in a custom Structure I created for
the class.  Didn''t make much sense, since I know, that it was available
with
the information in the struct listing.

Anyways, thought I''d let ya know of thoes other two errors that I
picked up,
before working around them.

Talk with ya later Alex,

Mario Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-development/attachments/20070623/b6d3662e/attachment-0001.html

Hey Mario

Mario Steele wrote:
> I was creating my own Help Viewer, similar to Microsoft''s Old 
> HelpView32 system. 
Out of interest, did you take a look at
Wx::HtmlHelpViewer?
> Part of the problem I was running into, was the fact that the Hide 
> button on the toolbar, needed to change text to Show, once the user 
> hidden the Sidebar that shows the search for topics, and Contents 
> pages.  But, I was getting fustrated with it, to the point that I 
> finally just decided to clean out the Toolbar, and re-create it, based 
> upon the toggle of the page.  Which seemed to work quite well.
I gave the Toolbar class a pretty thorough working over, plus updated it 
to support the 2.8 API (inc clear_tools ;)). I decided to make the 
methods that in Wx return a ToolBarTool return the position that the 
Tool''s been added in. Hopefully should be reasonably convenient to use.
> While we''re on that subject, I was working on an XRC Dialog I
created
> for Editing worlds in my client, and I had it setup with a TreeCtrl, 
> and several edit text fields.  For some reason, when I added the entry 
> to the TreeCtrl, with an Image List assigned, it would not display the 
> images I had in the list, no matter which method I went with. 
...
>  Anything to add to what is up with that?
Couple of suggestions:

1) Make really sure that the path to the image is correct. If it''s not,
creating a Bitmap or Image fail silently in recent versions; in C++ 
you''re supposed to check that the image returns true to is_ok/ok before
using it. In current SVN, if an image is created from a bad path it''ll 
raise an exception.

2) I used to have hassle with PNGs of bigger bit depths with the old 
wxruby 0.6.0 to the point that I gave up and used XPMs. But I haven''t 
had so many problems with this in wxruby2.
>
> And finally, another part of the problem, seem to also incure some 
> kind of segfault that I could not trace back to the source through 
> GDB, that dealt with the fact that when switching between items in the 
> TreeCtrl, it would set the value of an Item to the associated fields I 
> had on the window.  It also seemed to crash at random places, but 
> always after so many times switching between the items in the 
> TreeCtrl.  I checked the debug, and it always seemed to crash 
> somewhere where Ruby was trying to get the text, and set the value of 
> it.  But the text was in a custom Structure I created for the class. 
>  Didn''t make much sense, since I know, that it was available with
the
> information in the struct listing. 
Remind me what OS you''re working on?

If it''s happening a bit randomly, it might be a GC issue - something is
getting hoovered up by Ruby when it shouldn''t be. Feel free to post a 
stack trace.

cheers
alex

On Sat, 23 Jun 2007 15:58:21 -0500, Alex Fenton <alex at pressure.to>
wrote:
> Hey Mario
>
> Out of interest, did you take a look at Wx::HtmlHelpViewer?
I have, but didn''t know if I wanted to deal with the specs behind it. 
I
think this is more trial and error, to see what else can be bunched up  
when designing these things.  Ya know, find the bugs that I can find. :P

> I gave the Toolbar class a pretty thorough working over, plus updated it
> to support the 2.8 API (inc clear_tools ;)). I decided to make the
> methods that in Wx return a ToolBarTool return the position that the
> Tool''s been added in. Hopefully should be reasonably convenient to
use.
That''s good to hear, seeing as I''ve been looking over things
ensuring that
anything that is findable, I can find, and let ya know about.  But so far,  
the solutions that I have come up with, haven''t generated any other  
problems, as of yet.
>> While we''re on that subject, I was working on an XRC Dialog I
created
>> for Editing worlds in my client, and I had it setup with a TreeCtrl,
>> and several edit text fields.  For some reason, when I added the entry
>> to the TreeCtrl, with an Image List assigned, it would not display the
>> images I had in the list, no matter which method I went with.
> ...
>>  Anything to add to what is up with that?
> Couple of suggestions:
>
> 1) Make really sure that the path to the image is correct. If it''s
not,
> creating a Bitmap or Image fail silently in recent versions; in C++
> you''re supposed to check that the image returns true to is_ok/ok
before
> using it. In current SVN, if an image is created from a bad path
it''ll
> raise an exception.
>
> 2) I used to have hassle with PNGs of bigger bit depths with the old
> wxruby 0.6.0 to the point that I gave up and used XPMs. But I
haven''t
> had so many problems with this in wxruby2.
Reviewing these two suggestions, I''ve looked at the way I was doing it
in
both my TreeCtrl, and ListCtrl versions of the dialog I was using to "Edit
Worlds", and from my understanding, I''m using the same exact
method in
both.  While the ListCtrl will display the Images with no problems, the  
TreeCtrl does not.  No matter which method I go with, it simply refuses to  
display the image in the TreeCtrl.  Though I haven''t tried XPM, cause I
don''t have a Image to XPM converter laying around since I did the  
re-format on my computer.

I''ve settled for now, to work with a ListCtrl, as it seems to be
working
just as good, if not better, for my purposes.  And it makes things alot  
easier to navigate for some reason.  Oh well, as they say, Ce la Vie.
> Remind me what OS you''re working on?
>
> If it''s happening a bit randomly, it might be a GC issue -
something is
> getting hoovered up by Ruby when it shouldn''t be. Feel free to
post a
> stack trace.
I''m thinking it''s an GC issue, but seems to be cropping up in
the most
in-oppurtune places, that I cannot simply figure out why.  But what I have  
traced it down to, is that it only occurs when you do an  
EditCtrl#set_value() execution.  Don''t have a stack trace, since
I''ve
switched to working with a different format, and I''m using both Windows
and Linux to work on my project.  For linux, I''m using PCLinuxOS, which
is
an Mandrivia derivitive.

Right now, I''m comming to terms with learning how ListCtrl works, and  
found it to be alot easier to work with, so I am there fore going to keep  
with this method for now, as it seems to be the best method to work with  
for me at this time.  And it also seems to give me the path for least  
resistance.  If I can, I''ll see about setting up a seperate sample of
the
dialog I was working with, and see if I can get the same error.  If I can,  
I''ll forward it to ya, so you can test it out for yourself.
> cheers
> alex
> _______________________________________________
> Wxruby-development mailing list
> Wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
BTW, any news on the Socket wrapping?  I found that I had to do a work  
around myself to prevent the freezing of my app, by using a Timer to  
periodically check for data that is incoming to my client.  It''s a  
temporary solution, but one that I''d rather not have to do with this  
Client, as it can have Multiple Connections going at the same time. 
It''s
a lot easier to get an event that tells me when data is available, then to  
pro-activly check for the data.  Guess it''s the lazy programmer in me.
LOL

Cheers,
Mario


-- 
Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/

Mario Steele wrote:
>> Out of interest, did you take a look at Wx::HtmlHelpViewer?
>>     
>
> I have, but didn''t know if I wanted to deal with the specs behind
it.
Yeah, the format''s not explained that well, took me a bit of trial and 
error to figure it out. But it works nicely with that
done.
> I  
> think this is more trial and error, to see what else can be bunched up  
> when designing these things.  Ya know, find the bugs that I can find. :P
>
>   
That''s good for us ;)
> Reviewing these two suggestions, I''ve looked at the way I was
doing it in
> both my TreeCtrl, and ListCtrl versions of the dialog I was using to
"Edit
> Worlds", and from my understanding, I''m using the same exact
method in
> both.  While the ListCtrl will display the Images with no problems, the  
> TreeCtrl does not.  No matter which method I go with, it simply refuses to
> display the image in the TreeCtrl.  
Very weird...
> Right now, I''m comming to terms with learning how ListCtrl works,
and
> found it to be alot easier to work with, so I am there fore going to keep  
> with this method for now, as it seems to be the best method to work with  
> for me at this time.  And it also seems to give me the path for least  
> resistance.  If I can, I''ll see about setting up a seperate sample
of the
> dialog I was working with, and see if I can get the same error.  If I can,
> I''ll forward it to ya, so you can test it out for yourself.
Great, please do.
> BTW, any news on the Socket wrapping?  I found that I had to do a work  
> around myself to prevent the freezing of my app, by using a Timer to  
> periodically check for data that is incoming to my client.  
No news so far. I buy the rationale for it, but there''s a fair number
of
Socket classes to do and it''s just not very far up my priority list at 
the moment.

At the moment I''m keen to ship a beta quality release with largely the 
classes we have at the moment. I''d also like to figure out some way to 
break up the functionality into different libraries like you suggested, 
as the core lib is getting a bit overweight with SWIG bloat.

cheers
alex