From: Nick Stokes on
dpb <none(a)non.net> wrote in message <hskiu8$d9b$2(a)news.eternal-september.org>...

>
> OK, I'll do so instead... :)
>
> Have you considered it just simply may not be possible to a user app in
> Matlab

Yes, thanks! That would be an answer indeed.. Unfortunate, but an answer nevertheless.

> and that ML internals are available to ML itself in an obviously
> much more intimate manner than at the m-file level?
>

But is that /really/ the case? Isn't there even an undocumented, unsupported, low-level, platform-specific way?
From: dpb on
Nick Stokes wrote:
> dpb <none(a)non.net> wrote in message
> <hskiu8$d9b$2(a)news.eternal-september.org>...
>
>>
>> OK, I'll do so instead... :)
>>
>> Have you considered it just simply may not be possible to a user app
>> in Matlab
>
> Yes, thanks! That would be an answer indeed.. Unfortunate, but an
> answer nevertheless.
>> and that ML internals are available to ML itself in an obviously much
>> more intimate manner than at the m-file level?
>>
>
> But is that /really/ the case? Isn't there even an undocumented,
> unsupported, low-level, platform-specific way?

I have no idea (I don't do windows/gui's even if had a current version
of Matlab to futz with so anything that did would have any bearing
whatsoever).

But, it strikes me that even if you were to find such a back door you
would have invested a great deal of time and effort into an undocumented
hack that could change behavior at any release.

I have no idea what your target is here but to invest what appears to be
a significant amount of effort for such an undocumented feature seems a
risky business model for anything other than simply for speculation to
prove a point.

--
From: us on
"Nick Stokes" <nickstokes5(a)gmail.com> wrote in message <hski50$71p$1(a)fred.mathworks.com>...
> @us
>
> > well...
> > firstly, some replies have NOT been sarcastic at all...
> > second, NOW things seem more clear as you explain them in better MLbbers terms,
> > because the way you first phrased it, CSSMers got the impression that you don't
> > want to use the mouse AT ALL...
>
> I still don't understand why and how come you can talk for everyone else in the list with such certainty, but anyhow...
>
> > to achieve the above demonstrated functionality, look at this callbacks
> > set(gcf,'windowbuttonmotionfcn',@your_callback);
> > % eg,
> > plot(1:10);
> > fh=@(varargin) disp(sprintf('%d %d',get(gcf,'currentpoint')));
> > set(gcf,'windowbuttonmotionfcn',fh);
> > % now, move your mouse and look at the command window...
>
> This is useless!! None of this code tells anything about what OBJECT is under the currentpoint! Of course we'd be implementing 'windowbuttonmotionfcn' at some point for the interactive example I'd posted, but that is totally irrelevant.
>
> > % your callback would be more intelligent, of course...
>
> yes! and I tried to spare you all this when I was asking the question to begin with. Now hopefully that we are on the same page, and now that we have the cursor position via get(gcf,'currentpoint') in some kind of callback or whatever, let's move on:
>
> How do I determine which object is at that point? And, although interesting thought (and thanks for posting earlier), we do not want to call the "robot" to do the clicking because (1) it is not elegant (2) we don't want to update figure's currentobject (3) it doesn't answer the question.
>
> (and please, please, do not answer if you don't know the exact answer to this. spare me the irrelevant)

there is no need for you to get brash and flippant at all, and i will show you why

*** 05/11: you start this thread with a simple one liner
....Is there a way to detect which object (line, patch, etc..) is at a given cursor position?...

*** 05/11, exactly two hours later: i respond with a simple one liner
show an example...

for three days, several excellent (certainly not me) people have tried to find out how to help you...

however, it takes you four (4) fuzzy replies until - finally - on
*** 05/14: you bother to give the example you could have given in the OP
....Fwiw, let me show an example of an interactive visualization where such functionality would be essential:...

note: you use the term 'FWIW', which is pretty 'cool' given the fact that some people spent their time to find out what your particular problem is...

given your track record of one OP in this NG (i realize, it's just this particular email address) you sound a bit too condescending for what you deliver yourself - a behaviour not boding well for your future here at CSSM...

us
From: Jan Simon on
Dear Nick!

> plot( a_lot_of_lines );
> set(gcf, 'windowbuttonmotionfcn', @foo );
> function foo(s,e)
> persistent hPrev
> x = get(s,'currentpoint');
> h = pixel2handle (s, x); % the magic
> if isempty( h ) return;
> stand( h ); % annotate, bring forward, or change color, or something
> if ~isempty(hPrev) sit( hPrev ); % revert original style
> hPrev = h;
> end

If you want PIXEL2HANDLE to be simple, use the robot to simulate a click and let the callback function of the objects solve the rest.
If you do not want to change the figure's current object (and you have any reason for that), then let the robot restore the former current object afterwards.

Or specify which objects hould be affected by the operation - Pixel2LineHandle should be much simpler. There must be some example code in the measurement utilities of Matlab, which find the nearest line inside a certain distance, when the mouse is clicked.

Or you can use a simple mechanism which uses left-&right mouse clicks instead of hover&left click. It is not worth to spend a lot of time to develop a GUI which differs from the expectations and experiences of standard users.

Or if you are really fond of your Java example, why don't you use it and omit the translation to Matlab?

Or you can give each object an individual color and recognize the object by using the Java robot again: get the color of the current point... Ugly, I know.

Good luck, Jan
From: Yair Altman on
> to achieve the above demonstrated functionality, look at this callbacks
> set(gcf,'windowbuttonmotionfcn',@your_callback);
> % eg,
> plot(1:10);
> fh=@(varargin) disp(sprintf('%d %d',get(gcf,'currentpoint')));
> set(gcf,'windowbuttonmotionfcn',fh);
> % now, move your mouse and look at the command window...
[...]
> @ "Doug Schwarz'
>
> > Perhaps you can modify overobj.m to do what you want.
>
> This was a good lead! Thank you. But it seems to work only for objects that are immediate children of a figure. In particular, it is a simplistic code that checks for bounding box of the objects, and determines whether current point is underneath. Probably very useful for UI, but not general line, patch, etc.. (no bounding box trick will work there).

Aside from overobj being undocumented, it also has some limitations, one of which you mentioned (it only searches direct figure children, not inner descendants, so anything contained within a uipanel, uibuttongroup etc. cannot be found).

Another limitation is that it uses the findobj function which is relatively slow and so it is not recommended to use overobj in a complex figure&#8217;s WindowButtonMotionFcn callback (http://www.mathworks.com/matlabcentral/newsreader/view_thread/27539#68650 ).

Also, it assumes the root and figure units are both &#8216;pixel&#8217;: often they are not. Also, it only searches visible objects: hidden axes are not retrieved. Finally, it would be a great benefit to have an overobj variant in which the Type argument is optional, so the function would return the handle of the first object found, of whichever type.

So, I have written a variant of overobj that fixes all these issues, except the slowness. Note that overobj and overobj2 only work on objects having a Position property, and so cannot be used for axes plot children:

function h = overobj2(varargin)
%OVEROBJ2 Get handle of object that the pointer is over.
% H = OVEROBJ2 searches all objects in the PointerWindow
% looking for one that is under the pointer. Returns first
% object handle it finds under the pointer, or empty matrix.
%
% H = OVEROBJ2(FINDOBJ_PROPS) searches all objects which are
% descendants of the figure beneath the pointer and that are
% returned by FINDOBJ with the specified arguments.
%
% Example:
% h = overobj2('type','axes');
% h = overobj2('flat','visible','on');
%
% See also OVEROBJ, FINDOBJ

% Ensure root units are pixels
oldUnits = get(0,'units');
set(0,'units','pixels');

% Get the figure beneath the mouse pointer, and mouse pointer pos
fig = get(0,'PointerWindow');
p = get(0,'PointerLocation');
set(0,'units',oldUnits);

% Look for quick exit (if mouse pointer is not over any figure)
if fig==0, h=[]; return; end

% Compute figure offset of mouse pointer in pixels
figPos = getpixelposition(fig);
x = (p(1)-figPos(1));
y = (p(2)-figPos(2));

% Loop over all figure descendants
c = findobj(get(fig,'Children'),varargin{:});
for h = c',
% If descendant contains the mouse pointer position, exit
r = getpixelposition(h);
if ( (x>r(1)) && (x<r(1)+r(3)) && (y>r(2)) && (y<r(2)+r(4)) )
return
end
end
h = [];


An alternative to overobj or overobj2 is to use the undocumented hittest built-in function &#8211; separate cases may dictate preferring one alternative to the other:
hObj = hittest(hFig);

Yair Altman
http://UndocumentedMatlab.com