Arved Sandstrom <Arved_37@chebucto.ns.ca> writes: >I'm new on the list, but I've scanned the last 6 months of archives and >don't think that some things related to the Controls Toolbox module have >been clarified, or whatever. Alan Fry had a question about passing procs >to TrackControl that I never saw an answer for, posted anyhow. See Alan's reply regarding that. >To get everything working I ended up modifying Controls::track() a fair >bit, too, mainly to save the old control value before calling >TrackControl(), and then passing it to hit(). Not quite sure what you modified and why you thought it necessary. Can you send me a diff ? > While we're at it, I'm curious about the logic in TextEdit::click(), where >the PtInRect test doesn't encapsulate TEClick, I did not want to hamper TextEdit's creativity :-) There are situations where mouse action outside the viewRect is meaningful to a TextEdit record (e.g. autoscrolling), and with special input methods, possibly other situations, too, although, admittedly, IM:Text does it otherwise. For the return value, however (i.e. "This pane handled the click"), PtInRect should be good enough. >and in TextEdit::redraw(), the InsetRect + FrameRect sequence sure looks >like a debugging holdover. :-) Why? >To get to the subject Alan raises, though, let me point out some dubious >aspects of TrackControl as it appears in Controls.xs. One, the > >if (part > 127 || part < 250) > >test is never going to fail. So maybe && was intended. Right, that's fixed in the beta release. > In any case, what's leading to the error above is the function > "looks_like_number(actionProc)". Fixed as well. >It seems to me that just the SvNIOK macro should do the trick. That's how >I implemented it. No, that's not quite sufficient. The test I use now (and should have used right away) is: !SvROK(actionProc) && looks_like_number(actionProc) This handles function references (by the SvROK) and uses the looks_like_number just for disambiguating strings. SvNIOK is no good for strings. >I'll leave it at that, since I have no way of knowing whether this has >been addressed. My solution involved fixing a MacPerl .xs file, so apart >from my own projects I can't take it any further. Hey, if you can fix .xs files, wouldn't you be interested in getting involved with MacPerl module building? Matthias -- Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri "If people are boasting that they use the best tools, you can figure that they can't find any competitive advantage to using those tools, or else they wouldn't be presenting them as a competitive advantage." -- Dave Winer ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch