topic Re: Can JMP graphics have this effect? in Discussions

Can JMP graphics have this effect?

lala — Sun, 10 Nov 2024 03:12:21 GMT

This is the HTML effect.
Can JMP graphlet achieve this effect?

Thanks!

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 09:58:08 GMT

via JSL, yes.

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 12:31:42 GMT

via (JSL-free) Graph Builder: not yet. Maybe in a future release?

More and more competitor programs provide this type of annotations, so I guess it will also be implemented in JMP.

You can go to and support @shampton82 's wish.

Re: Can JMP graphics have this effect?

Craige_Hales — Sun, 10 Nov 2024 13:16:35 GMT


dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
gb = dt << Graph Builder(
	Show Control Panel( 0 ),
	Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) )
);
fb = Report( gb )[FrameBox( 1 )];
xx = yy = 0;
fb << addgraphicsscript(//
	Mousetrap(
		xx = x;
		yy = y;
	);
	V Line( xx );
	// at this point you can highlight all the values near xx
	For( irow = 1, irow <= N Rows( dt ), irow += 1,
		If( Abs( dt:height[irow] - xx ) < 0.5, // big class height step is 1, <.5 selects a single column of weights
			Marker( Marker State( 4 ), {dt:height[irow], dt:weight[irow]} )
		)
	);
	xwidth = X Range();
	xmidpoint = X Origin() + xwidth / 2;
	If( xx < xmidpoint,
		Text( {xx + xwidth / 100, yy}, "height " || Char( Round( xx ) ) || "\!nmore" )//
	,
		Text( right justified, {xx - xwidth / 100, yy}, "height " || Char( Round( xx ) ) || "\!nmore" )
	);
	//	
);

edit: Line 18 now says xx rather than x. Must have been something left over in my namespace. Thanks @lala @hogi

(view in My Videos)

Re: Can JMP graphics have this effect?

lala — Sun, 10 Nov 2024 11:30:17 GMT

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 13:36:48 GMT

@Craige_Hales , nice, very smooth! : )

Almost too smooth: I hope this example will not stop the developers from implementing a non-JSL approach.
some arguments for a native support via Graph Builder:

- make native Graph Builder more powerful

- make the non-JSL users happy as well

- show the automatic fancy annotations even without mouse clicks
-> allow the users to use the mouse as usual to select data points
(with the current "JSL" approach, one might add some toggle buttons to choose the correct mode - like it's implemented for )

It took me a while to understand the error message!

Names default to here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
gb = dt << Graph Builder(
	Show Control Panel( 0 ),
	Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) )
);
// x=y=60;
fb = Report( gb )[FrameBox( 1 )];
fb << addgraphicsscript(//
	If(Not( Is Empty( x ) ), // if the mouse did not yet enter the graph -> do nothing.
		Mousetrap("nothing to do");
		V Line(x);
	// at this point you can highlight all the values near xx
		For( irow = 1, irow <= N Rows( dt ), irow += 1,
			If( Abs( dt:height[irow] - x ) < 0.5, // big class height step is 1, <.5 selects a single column of weights
				Marker( Marker State( 4 ), {dt:height[irow], dt:weight[irow]} )
			)
		);
		xwidth = X Range();
		xmidpoint = X Origin() + xwidth / 2;
		If( x < xmidpoint,
			Text( {x + xwidth / 100, y}, "height " || Char( Round( x ) ) || "\!nmore" )//
		,

			Text(
				right justified,
				{x - xwidth / 100, y},
				"height " || Char( Round( x ) ) || "\!nmore"
			)
		);
	)
	//	
);

Re: Can JMP graphics have this effect?

lala — Sun, 10 Nov 2024 13:38:43 GMT

Looks like adding a hover drill script.

For(iFrame=1,iFrame<=N Items(framelist),iFrame+=1,frame=framelist[iFrame]; Eval(Eval Expr(frame<<Addgraphicsscript(Mousetrap({},
……//？？
)))););

Thanks Experts!

Re: Can JMP graphics have this effect?

Craige_Hales — Sun, 10 Nov 2024 13:36:32 GMT

@hogi MouseTrap is a strange thing in JSL. It is a function that does nothing when executed and doesn't matter if it is executed or not or (mostly) where it is positioned in the script. When a mouse move happens on the graph, the coordinates are sent to the script in x,y which need to be copied into globals as shown.

Handle, and the various Drag variants, have a position associated with them and will only activate if close enough. The order does matter, a little, because the first one encountered in the script that is close enough (a few pixels) will get the update.

I can't fully explain why it works with your change. X really shouldn't exist... it appears it escapes the mousetrap!

I repaired the script in my first post.

Re: Can JMP graphics have this effect?

lala — Sun, 10 Nov 2024 13:42:25 GMT

I SEE

Hold down the left button to move automatically change.

Thank Craige!

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 14:22:43 GMT

I just found this information in the Scripting Index:

the coordinates x and y are stored as global variables for the execution of the script.

And any pre-existing global variables x & y are restored after executing the script.

Here is where the story could end.

Uncommenting the

// x=y=60;

lets the graph start with a line at x = 60. -> the script uses the local variable from the Here namespace.
What surprised me:
When I try to drag the line to another location, it works!

Why is this surprising:
x inside the Here namespace stays at 60. And the script will prefer the variables from the Here namespace over the variables from the global namespace. [Edit: for the global variables the original values should be "restored" at this point of time: after executing MouseTrap]. So, why does the script work ?!

Seems that inside the script there are local variable x & y which are preferentially used - instead of the variables from the Here namespace. It this interpretation correct?

Then, under the line, it's very kind that JMP does the extra effort with the global variables. This way even functions which live outside of the context of the Graphics Script (myfunctions:xy ) can access the variables :)

maybe interesting to check:
Graphics scripts of one FrameBox - do they share a common namespace or does every graphics script use it's own ...

Re: Can JMP graphics have this effect?

hogi — Wed, 24 Dec 2025 12:53:13 GMT

~~Ok, ONE shared Namespace per Framebox - separate from the global Namespace~~

~~- and separate from the Namespace of the other FrameBoxes.~~

edit: wow, quite wrong interpretation of the finding.

::x= 5;
(Report( gb )<< xpath("//FrameBox")) << add graphics script(//
	If(Not( Is Empty( x ) ), // if the mouse did not yet enter the graph -> do nothing.
		Caption("global x is "|| Char(::X));
		V Line(x+3);
	)
	//	
);

(view in My Videos)

Another finding - at the end of the video:
rescaling the window triggers a reset of the plot with the original values from the Here namespace.

How do I access this namespace?

Both:

Report(gb)[FrameBox(1)]  << get namespace() ;
(Report(gb)[FrameBox(1)] << find seg(TopSeg (1))) << get namespace();

produce a new namespace.

Re: Can JMP graphics have this effect?

Craige_Hales — Sun, 10 Nov 2024 15:47:30 GMT

you can use function arguments instead of x,y

Names Default To Here( 1 );
New Window( "Example",
	trapx = 20;
	trapy = 50;
	handx = 70;
	handy = 80;
	trapcolor="blue";
	handcolor="blue";
	Graph Box(
		Frame Size( 200, 200 ),
		handle( handx, handy, // any handle(s) must come before Mousetrap
			Function( {a, b}, handx=a; handy=b;
				Write( Eval Insert( "\!nhand drag ^a^ ^b^" ) );
				handcolor="magenta"; )
		, // the mouse-up handler 
			Function( {a, b}, handx=a; handy=b;
				Write( Eval Insert( "\!nhand release ^a^ ^b^" ) );
				handcolor="cyan"; ) 			
		);
		Mousetrap( // should not be more than one Mousetrap, the first one captures all clicks
			Function( {a, b}, trapx=a; trapy=b;
				Write( Eval Insert( "\!ntrap drag ^a^ ^b^" ) );
				trapcolor="red"; )
		, // the mouse-up handler 
			Function( {a, b}, trapx=a; trapy=b;
				Write( Eval Insert( "\!ntrap release ^a^ ^b^" ) );
				trapcolor="green"; ) 
		);
		// the drawing occurs outside of the mousetrap or handle
		pencolor(trapcolor);
		pensize(3);
		Circle( {0, 0}, Sqrt( trapx * trapx + trapy * trapy ) );
		pencolor(handcolor);
		pensize(3);
		Circle( {0, 0}, Sqrt( handx * handx + handy * handy ) );
		
	)
);

If you need one or more handles, they must appear before the mousetrap because a click will be consumed by the mousetrap if no previous handle took it.

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 18:24:53 GMT

Re: Can JMP graphics have this effect?

hogi — Sun, 10 Nov 2024 17:11:15 GMT

Interesting. Why is the handle not tied to the x/y coordinate system?
It still works after resizing the plot, but there is a significant offset:

(view in My Videos)

Re: Can JMP graphics have this effect?

Craige_Hales — Sun, 10 Nov 2024 23:22:03 GMT

The handle is. The circle is not. I *think* the perfectly round circle on the non-square grid has its radius defined in Y axis coordinates.

Re: Can JMP graphics have this effect?

hogi — Mon, 11 Nov 2024 05:35:02 GMT

Ouch, sure -

Re: Can JMP graphics have this effect?

hogi — Mon, 11 Nov 2024 22:18:21 GMT

@hogi wrote:

How do I access this namespace?
Both:
Report(gb)[FrameBox(1)]  << get namespace() ;
(Report(gb)[FrameBox(1)] << find seg(TopSeg (1))) << get namespace();
produce a new namespace.

... I asked JMP support: TS-00173810

unfortunately:

You cannot access the graphics script namespace externally.

Re: Can JMP graphics have this effect?

martindemel — Sat, 16 Nov 2024 04:45:49 GMT

Slightly changed the script to display weight values instead of more:

names default to here(1);
dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
gb = dt << Graph Builder(
	Show Control Panel( 0 ),
	Variables( X( :height ), Y( :weight ), Overlay( :sex ) ),
	Elements( Points( X, Y, Legend( 1 ) ), Smoother( X, Y, Legend( 2 ) ) )
);
fb = Report( gb )[FrameBox( 1 )];
xx = yy = 0;
valuesMatrix = :height << Get Values; //***new*** Get column values for height
fb << addgraphicsscript(//
	Mousetrap(
		xx = x;
		yy = y;
	);
	V Line( xx );
	// at this point you can highlight all the values near xx
	For( irow = 1, irow <= N Rows( dt ), irow += 1,
		If( Abs( dt:height[irow] - xx ) < 0.5, // big class height step is 1, <.5 selects a single column of weights
			Marker( Marker State( 4 ), {dt:height[irow], dt:weight[irow]} )
		)
	);
	
	valuesRows = char(:weight[loc(valuesMatrix,round(xx))]); //***new*** write to char weight values for all rows of height at position round(xx)
	xwidth = X Range();
	xmidpoint = X Origin() + xwidth / 2;
	If( xx < xmidpoint,
		Text( {xx + xwidth / 100, yy}, "height " || Char( Round( xx ) ) || "\!nweight " || valuesRows  )////***new*** exchanged "more" with weigth and list of weight values for that location of height
	,
		Text( right justified, {xx - xwidth / 100, yy}, "height " || Char( Round( xx ) ) || "\!nweight " || valuesRows )
	);
	//	
);

you may even could add sorting the values ascending/descending.

(view in My Videos)

Re: Can JMP graphics have this effect?

hogi — Wed, 24 Dec 2025 13:28:07 GMT

Hm, I think many of my conclusions were wrong.

Another try:

Maybe the does not mean "after running the [drag] script" but rather "with the mouseUp".
And very important. If there is no need to update a Framebox, it doesn't get updated.

So,

when the mouse is moved, new coordinates are saved to x & y
(
? No - in the Here namespace because we used Names default to HERE (1))
... and the values can be used within the Here namespace - even outside of the Mousetrap(). This puzzled @Craige_Hales , and I put another foot into this trap: Making-a-drag-amp-drop-script
After the update of the variables, JMP gets a trigger to redraws THE Framebox with the graphics script and the current x and y values.
Other Frameboxes don't get updated:
If we move the mouse in the left frame box, the center one is not updated – and vice versa.
This creates the illusion of two separate namespaces. So it's no wonder that users can't access the namespace of a frame box — there isn't one. It's just the shared Here namespace in combination with local Framebox updates.
After releasing the mouse button, x and y .
However, no update of the frame boxes is triggered. Therefore, the user does not notice this reset of the variables in the Here' namespace.
Just when the graph gets updated the next time (e.g. resized, or some data points selected), the graphics script is executed again and reveals that the values were reset (some time ago).

(view in My Videos)