comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Home » Public Forums » archive » Re: Reverse engineering the new graphics PLOT() margin property?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend  		Return to the default flat view Create a new topic Submit Reply
Re: Reverse engineering the new graphics PLOT() margin property? [message #79926 is a reply to message #79924] Fri, 13 April 2012 13:46 Go to previous message
Jim Pendleton is currently offline  Jim Pendleton
Messages: 165
Registered: November 2011
Senior Member
On Thursday, April 12, 2012 11:37:45 AM UTC-6, Sean Davis wrote:
> I was wondering if anyone has figured out how the default margins are determined in new graphics?
>
> On a related note, it is infuriating that there is no way to return the values of INIT properties like margin, position, etc. (unless I'm missing something!)
>
> What I'd really like to be able to do is the following --
>
> p = plot(findgen(20))
>
> print, p.margin

If you are fearless, don't mind rolling up your sleeves and perhaps your pantlegs, and enjoy the thought of diving deep (well, just 6 routines deep) into the "internal" .pro routines, it's pretty straightforward to answer the question "How?"

If you have none of these qualities, remain ashore and read no further. Contact support@exelisvis.com with a feature request, and return to the safety of your home.

There's no reverse engineering since the .pro code is exposed. But there is hacking.

You have set sail to Terra Incognita, where a secret dialect is fluently spoken only by the natives known as The Second Floor*. Here there be undoc'ed IDL.

As a shortcut to getting to the crux of your question, execute the following slightly illegal statement from the Workbench

IDL> p = plot(/test, margin=[0,0,0], /debug)

This will cause IDL to stop on an error
% MARGIN must have 1 or 4 elements.

All the display geometry calculation is in an editor window showing the routine in which you've stopped.

Set a breakpoint in the method, recompile, RETALL, then rerun with some valid input.

If you have the mad IDL debugging skilz, you'll see that the MARGIN value is likely discarded when other values are derived from it. By itself it never appears to be stored as a property of your plot object, such as in an obvious member variable.

If you back your way slowly and carefully out of the call stack (Show no fear! New Graphics can smell fear!), you may be able to discern how the derived values are used in subsequent calculations.

Of course the harder questions to answer are, "How do I change this to do what I want?" and the more generic "Why was it implemented this way?" These are exercises left for the reader.

Jim P.

*I'm on the third floor. We don't get capitalization up here.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Map Function Question
Next Topic: Re: speed-up computation of kernel-based "statistics"

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 20:50:34 PDT 2025

Total time taken to generate the page: 0.16223 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.7.
Copyright ©2001-2013 FUDforum Bulletin Board Software