Message Boards Message Boards

Don't understand why EventHandler obviates ImageSize within GraphicsRow

Greetings. First time to this group, so please forgive if I post anything that seems trivial.

I can't figure why EventHandler is changing the size of my graphics within GraphicsRow. Snippet below illustrates.

`data = Table[RandomReal[], {r, 1, 5}, {c, 1, 5}]; (* Create array of random reals, range 0-1 *)

g1 = ArrayPlot[data, ColorFunction -> Hue, ImageSize -> Small]; (* Draw same array, two different sizes *)

g2 = ArrayPlot[data, ColorFunction -> Hue, ImageSize -> Medium];

GraphicsRow[{g1, g2}, ImageSize ->Automatic] (* Now, display g1 and g2 with GraphicsRow, which works fine*)

enter image description here

   (* Below, wrap g1,g2 w EventHandler, which draws fine, but records clicks outside the boundary of the smaller figure (g1) *)

EventHandler[GraphicsRow[{g1, g2}, ImageSize ->Automatic], "MouseClicked" :> (Print["Mouse position =", MousePosition["Graphics"]]) ]

enter image description here

    (* Below, wrap only g2 in EventHandler. This blows away the pre-set sizes of g1 and g2, drawing them the same size *)

GraphicsRow[{g1, EventHandler[g2, "MouseClicked" :> (Print["Mouse position =", MousePosition["Graphics"]]) ]}, ImageSize ->Automatic]`

enter image description here

My question is: With just g2 wrapped in EventHandler, how can I get GraphicsRow to recognize g2's size settings? What I ultimately want to do is to wrap both g1 and g2 in separate event handlers, in order to filter out mouse clicks outside the boundaries of each.

Many thanks.

Bill
POSTED BY: William Knecht
2 Replies
Sort By:

Well, I would recommend that you point this behavior out to the developers-- i.e., file a bug report:

http://www.wolfram.com/support/contact/email/?topic=Feedback

the behavior that you observe, in my opinion, shouldn't happen.
POSTED BY: David Reiss

After a couple of frustrating days (welcome to Mathematica...), I solved my own problem.

Have to use Row[]. GraphicsRow simply doesn't work. GraphicsRow insists on making all graphic containers the same size when coupled with EventHandler. Like many MMCA functions, this probably just reflects many programmers having worked on MMCA over the years. The way one uses functions ends up being very much a product of the acumen, experience, and dedication of whatever programmer wrote that particular code for that particular function. And, like all programs, when there's a problem with functionality, but few users need that particular functionality, a problem like this may persist indefinitely.

While, I'm on my soapbox, let me add that I basically love MMCA, and will continue to use and love it, as I have for the past 20 years. But, it does mystify me why they don't go to OOP like Visual Studio. Double-click on a VS object, and a window opens up showing all parameters that can be changed, and lets you do it right there. No having to search Help or use Options[] to figure out what can and can't be changed, or what the default settings are. No having to search on the Web, or get on users' groups asking questions. No having to wonder whether a parameter is controlled as xxx-> , or xxx[yyy], or xxx->{yyy}, or xxx->{{yyy},{zzz}}--that kind of nonsense.

Of course, true to the system, maybe all this CAN be done, and I simply don't know how to set up the front end. That would be true to the Principle of Maximum Foolishness. If so, I'd be happy to have someone correct me.
POSTED BY: William Knecht
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract