Hey Alex, I was looking into figuring out a way to create a truely Asynchronis Socket type for Ruby, and thought I''d go down to the bare minimal implementation of it, to start creating a socket, and then I got to thinking. Looking at the wxWidgets C/C++ Code, it doesn''t do much different then what I''m doing, only in Ruby, so I thought maybe, as a way to avoid having to wrap wxSocket, and various other classes that wxWidgets has, that is asynchronis, I was looking at possibly writting a Pure Ruby implementation of the wxSocket classes. Now, I''ve already started re-creating GSocket.cpp in ruby, as GSocket.rb, and doing it in a way that works the best, in other words, the Ruby way. This will be the foundation for the rest. But this brings up a question, especially with the recent changes in the way Events are worked. I was wondering if there was a way I can create Custom Events to use for the Ruby implementation of wxSocket? Any insight, much appreciated. Mario Steele -- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/
Hi Mario Mario Steele wrote:> I thought maybe, as a way > to avoid having to wrap wxSocket, and various other classes that wxWidgets > has, that is asynchronis, I was looking at possibly writting a Pure Ruby > implementation of the wxSocket classes. >Sounds like a good idea. I''ve seen a couple of recent messages on the wx list which have slightly cooled me on the idea of wrapping the Socket classes, eg http://groups.google.com/group/comp.soft-sys.wxwindows/browse_frm/thread/66609edd4c017fe0/90b57e6c2742ace1?tvc=1#90b57e6c2742ace1> other words, the Ruby way. > This will be the foundation for the rest. But this brings up a question, > especially with the recent changes in the way Events are worked. I was > wondering if there was a way I can create Custom Events to use for the > Ruby implementation of wxSocket? >Yes, for sure. It goes something like this: # create an event class with an id, and register the type class SocketEvent < Wx::Event EVT_SOCKET_CLOSE = Wx::Event.new_event_type Wx::EvtHandler.register_class(self, EVT_SOCKET_CLOSE, ''evt_socket_close'', 1) def initialize(obj) super(EVT_SOCKET_CLOSE) set_event_object(obj) end end # create the event-firing class class Socket def close evt = SocketEvent.new(self) get_event_handler.process_event(evt) end end # in the event-handling class evt_socket_close(a_socket) { | e | .... } Have a look at the evthandler HTML doc, and from there perhaps also lib/wx/classes/evthandler.rb and swig/classes/EvtHandler.i. I''m planning to expand the event handling tutorial soon. I''ve only really used this with CommandEvent-like custom events used with custom controls, so there are likely some wrinkles to work out. In particular, because wxWidgets does lots of Clone-ing inside the event handling code, there''s currently no guarantee that the handled event will be the same as that passed to process_event. This means that instance variables etc set in the original event may be lost. So if you have a chance to work with this do let us know how it can be improved. alex
Hey Alex, Sorry that I haven''t been able to respond till now. I''ve been working on the problem at hand, and so far, what I have gotten, is a base layout, trying to emulate everything that is in wxBaseSocket class to start, then build up from there. I''m working out the stuff that currently is supported by Ruby''s Socket class, and go from there. If I do get this working, will this be included with the Full Distro of wxRuby, and not the wxSugar package? Reason why I ask, is cause I''d rather it go into wxRuby core package, cause it''s going to be mirroring the wxWidget''s API to the letter, so to say, and really isn''t meant for the wxSugar package. Hopefully, I''ll have something together, and some tests to try out, and see if it will work or not soon. TTFN, Mario Steele On 8/2/07, Alex Fenton <alex at pressure.to> wrote:> > Hi Mario > > Mario Steele wrote: > > I thought maybe, as a way > > to avoid having to wrap wxSocket, and various other classes that > wxWidgets > > has, that is asynchronis, I was looking at possibly writting a Pure Ruby > > implementation of the wxSocket classes. > > > Sounds like a good idea. I''ve seen a couple of recent messages on the wx > list which have slightly cooled me on the idea of wrapping the Socket > classes, eg > > > http://groups.google.com/group/comp.soft-sys.wxwindows/browse_frm/thread/66609edd4c017fe0/90b57e6c2742ace1?tvc=1#90b57e6c2742ace1 > > other words, the Ruby way. > > This will be the foundation for the rest. But this brings up a > question, > > especially with the recent changes in the way Events are worked. I was > > wondering if there was a way I can create Custom Events to use for the > > Ruby implementation of wxSocket? > > > > Yes, for sure. It goes something like this: > > # create an event class with an id, and register the type > class SocketEvent < Wx::Event > EVT_SOCKET_CLOSE = Wx::Event.new_event_type > Wx::EvtHandler.register_class(self, EVT_SOCKET_CLOSE, > ''evt_socket_close'', 1) > def initialize(obj) > super(EVT_SOCKET_CLOSE) > set_event_object(obj) > end > end > > # create the event-firing class > class Socket > def close > evt = SocketEvent.new(self) > get_event_handler.process_event(evt) > end > end > > # in the event-handling class > evt_socket_close(a_socket) { | e | .... } > > Have a look at the evthandler HTML doc, and from there perhaps also > lib/wx/classes/evthandler.rb and swig/classes/EvtHandler.i. I''m planning > to expand the event handling tutorial soon. > > I''ve only really used this with CommandEvent-like custom events used > with custom controls, so there are likely some wrinkles to work out. In > particular, because wxWidgets does lots of Clone-ing inside the event > handling code, there''s currently no guarantee that the handled event > will be the same as that passed to process_event. This means that > instance variables etc set in the original event may be lost. So if you > have a chance to work with this do let us know how it can be improved. > > alex > > > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20070815/5d0df1f7/attachment-0001.html
Mario Steele wrote:> Sorry that I haven''t been able to respond till now. I''ve been working > on the problem at hand, and so far, what I have gotten, is a base > layout, trying to emulate everything that is in wxBaseSocket class to > start, then build up from there.Good work.> I''m working out the stuff that currently is supported by Ruby''s Socket > class, and go from there. If I do get this working, will this be > included with the Full Distro of wxRuby, and not the wxSugar package? > Reason why I ask, is cause I''d rather it go into wxRuby core package, > cause it''s going to be mirroring the wxWidget''s API to the letter, so > to say, and really isn''t meant for the wxSugar package.If it rounds out the WxRuby API and provides functionality where Ruby''s core classes don''t cut it, I''m not against it going into the core. cheers alex