wxruby users - Sep 2006 - problem with TextCtrl#get_insertion_point

I''m trying to un-ignore TextCtrl#get_selection. The typemaps work fine,
but in the process it breaks get_insertion_point.

This is because (on Mac, tho not GTK), get_insertion_point calls 
get_selection internally and simply returns the first value. I think the 
return value is being converted from a long to a ruby int twice, because 
when get_selection is wrapped, it works fine but the value for 
get_insertion_point becomes a gobbledygook integer.

Is there a bit of SWIG magic to stop the values being unwrapped twice 
for this function?

thanks
aelx

Try these patches.

I think I''m becoming convinced that the right way to wrap these since
we
are already including our own .h files instead of SWIGing from the 
wxWidgets source is to modify the signatures of the functions as follows:

    virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;

If we do this, we don''t have to have the %apply in the .i files.  Check
out the .h file that comes with wxScintilla as an example of a properly 
prepared .h file.

The patch I''ve included does -not- change the .h file since we
haven''t
committed to this yet.

I also patched wxTextCtrl.rbw to show get_selection and added a comment 
about how it works differently on the PC.  I didn''t mention that
setting
TE_RICH2 /should/ allow it to work correctly on all platforms (maybe 
this is only correct if it''s a text control v. 3.0 on Windows?)

Roy

Alex Fenton wrote:
> I''m trying to un-ignore TextCtrl#get_selection. The typemaps work
fine,
> but in the process it breaks get_insertion_point.
>
> This is because (on Mac, tho not GTK), get_insertion_point calls 
> get_selection internally and simply returns the first value. I think the 
> return value is being converted from a long to a ruby int twice, because 
> when get_selection is wrapped, it works fine but the value for 
> get_insertion_point becomes a gobbledygook integer.
>
> Is there a bit of SWIG magic to stop the values being unwrapped twice 
> for this function?
>
> thanks
> aelx
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>   
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typemap.i.patch
Url:
http://rubyforge.org/pipermail/wxruby-users/attachments/20060922/705ad622/attachment.pl
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TextCtrl.i.patch
Url:
http://rubyforge.org/pipermail/wxruby-users/attachments/20060922/705ad622/attachment-0001.pl
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxTextCtrl.rbw.patch
Url:
http://rubyforge.org/pipermail/wxruby-users/attachments/20060922/705ad622/attachment-0002.pl

Roy Sutton wrote:
> Try these patches.
Committed, thanks.
> I think I''m becoming convinced that the right way to wrap these
since
> we are already including our own .h files instead of SWIGing from the 
> wxWidgets source is to modify the signatures of the functions as follows:
I''m inclined to agree - when relatively few methods are affected, I 
think it''s clearer to have the mapping done with the method, rather
than
through the global and rather obscure ''apply''
technique.
>  I didn''t mention that setting TE_RICH2 /should/ allow it to work 
> correctly on all platforms (maybe this is only correct if it''s a
text
> control v. 3.0 on Windows?)
I think TE_RICH2 makes it work correctly across all platforms. I don''t 
know if there are any circumstances where TE_RICH alone is more useful?

alex

Roy Sutton wrote:
> I think I''m becoming convinced that the right way to wrap these
since we
> are already including our own .h files instead of SWIGing from the 
> wxWidgets source is to modify the signatures of the functions as follows:
> 
>    virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;
I like the concept, but am not quite happy with the details. From 
looking at the signature above, I have no idea what each of the two 
parameters mean (X, Y? start, end?).

Can we come up with a way to mark them as output without losing any 
information? If not, then I think I would favor simply having one SWIG 
directive for each method. (I''m not fond of having a generic SWIG 
directive that applies to a signature if that signature is ambiguous and 
could happen in cases that we don''t want to affect.

Kevin

Roy Sutton wrote:
>      def on_test_get_selection(event)
> -        text = @tc.get_string_selection()
> -        @log.write_text("get_string_selection(): " + text)
> +        start, stop = @tc.get_selection
> +        text = @tc.get_string_selection   # On WXMSW, is you select text
using
> +                                          #  the results of get_selection
you
> +                                          #  must replace \r\n\ with \n
before
> +                                          #  taking your selection
> +        @log.write_text("get_string_selection [#{start}..#{stop}]:
" + text)
>      end
Again, thanks for all your work recently! I''m sorry I have again been 
somewhat unavailable.

I would slightly prefer this formatting:


     start, stop = @tc.get_selection

     # On WXMSW, is you select text using the results of get_selection
     # you must replace \r\n\ with \n before taking your selection
     text = @tc.get_string_selection

     @log.write_text("get_string_selection [#{start}..#{stop}]: " +
text)


There is also a typo ("is" should be "if).

 From that wording though, it is not clear to me whether this code, as 
is, will work on MSW. It sounds like it won''t. But I''m not
sure. Would I
need to do something before the @tc.get_selection call, or before the 
@tc.get_string_selection call, or later in the program?

Thanks,

Kevin

Kevin Smith wrote:
> Roy Sutton wrote:
>   
>> I think I''m becoming convinced that the right way to wrap
these since we
>> are already including our own .h files instead of SWIGing from the 
>> wxWidgets source is to modify the signatures of the functions as
follows:
>>
>>    virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;
>>     
>
> I like the concept, but am not quite happy with the details. From 
> looking at the signature above, I have no idea what each of the two 
> parameters mean (X, Y? start, end?).
>
> Can we come up with a way to mark them as output without losing any 
> information? If not, then I think I would favor simply having one SWIG 
> directive for each method. (I''m not fond of having a generic SWIG 
> directive that applies to a signature if that signature is ambiguous and 
> could happen in cases that we don''t want to affect.
>
>   
Unfortunately you can''t apply (most) swig directives by method.  Only
by
parameters.  I would say that anyone using our copy of the header files 
to figure out what the parameters do is probably not doing himself a 
favor anyhow.

The other alternative is doing this:

#ifdef SWIG

virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;
#else
virtual void GetSelection(long* from, long* to) const;
#endif

Roy Sutton wrote:
> Unfortunately you can''t apply (most) swig directives by method. 
Only by
> parameters.  I would say that anyone using our copy of the header files 
> to figure out what the parameters do is probably not doing himself a 
> favor anyhow.
> 
> The other alternative is doing this:
> 
> #ifdef SWIG
> 
> virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;
> #else
> virtual void GetSelection(long* from, long* to) const;
> #endif
Ugh. That''s worse.

How about:


virtual void GetSelection(long* from_OUTPUT, long* to_OUTPUT) const;

It would still require adding a specific directive for each method. I 
view that as both an advantage (avoids accidental misinterpretation of 
other methods) and disadvantage (more work and maintenance).

Thoughts?

Kevin

Kevin Smith wrote:
> Roy Sutton wrote:
>   
>> Unfortunately you can''t apply (most) swig directives by
method.  Only by
>> parameters.  I would say that anyone using our copy of the header files
>> to figure out what the parameters do is probably not doing himself a 
>> favor anyhow.
>>
>> The other alternative is doing this:
>>
>> #ifdef SWIG
>>
>> virtual void GetSelection(long* OUTPUT, long* OUTPUT) const;
>> #else
>> virtual void GetSelection(long* from, long* to) const;
>> #endif
>>     
>
> Ugh. That''s worse.
>
> How about:
>
>
> virtual void GetSelection(long* from_OUTPUT, long* to_OUTPUT) const;
>
> It would still require adding a specific directive for each method. I 
> view that as both an advantage (avoids accidental misinterpretation of 
> other methods) and disadvantage (more work and maintenance).
>
> Thoughts?
My initial thought is:  Let''s shelve this until we figure out how 
wxPython has it all sorted out.  If we someday move to some sort of XML 
post-processing I don''t want to have spent even more time on this than 
necessary.  I already feel like a lot of my SWIG work will be obviated 
by whatever new method we choose.

Roy

Roy Sutton wrote:
> My initial thought is:  Let''s shelve this until we figure out how 
> wxPython has it all sorted out.  If we someday move to some sort of XML 
> post-processing I don''t want to have spent even more time on this
than
> necessary.  I already feel like a lot of my SWIG work will be obviated 
> by whatever new method we choose.
I am inclined to agree, assuming shelving it means that the .h files 
won''t be modified. If we were going to spin through them modifying all 
the parameter names to OUTPUT then I would like to discuss it further, 
because that would be effort spent destroying potentially valuable 
information.

Thanks,

Kevin

Kevin Smith wrote:
> From that wording though, it is not clear to me whether this code, as 
> is, will work on MSW. It sounds like it won''t. But I''m
not sure. Would I
> need to do something before the @tc.get_selection call, or before the 
> @tc.get_string_selection call, or later in the program?
>
>
>   
Try this one instead.  It''s much clearer and even more correct.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wxTextCtrl.rbw.patch
Url:
http://rubyforge.org/pipermail/wxruby-users/attachments/20060927/1e845fb7/attachment.pl