| Re: Beginer question about the @ usage [message #44993 is a reply to message #44850] |
Wed, 27 July 2005 13:09   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul Van Delst writes:
> The usual exception to the each-function-in-its-own-file rule is things like widget code where event
> handlers are placed in the same file as the widget creation code, e.g. mywidget.pro contains:
>
> PRO Exit_Event, Event
> WIDGET_CONTROL, Event.Top, /DESTROY
> END
>
> PRO mywidget
> Top_Level_Base_ID = WIDGET_BASE( COLUMN = 1, $
> MAP = Map, $
> MBAR = Menu_Bar_ID, $
> TITLE = 'MyWidget' )
> File_Menu_ID = WIDGET_BUTTON( Menu_Bar_ID, $
> VALUE = 'File', $
> /MENU )
> File_Exit_ID = WIDGET_BUTTON( File_Menu_ID, $
> VALUE = 'Exit', $
> EVENT_PRO = 'Exit_Event', $
> /SEPARATOR, $
> UVALUE = 'Exit' )
> WIDGET_CONTROL, Top_Level_Base_ID, MAP = Map, $
> REALIZE = 1, $
> UPDATE = 1
> XMANAGER, 'mywidget', Top_Level_Base_ID
>
> END
>
>
> Note that the MAIN routine, mywidget, is AFTER the event handler. This ensures that the dependent
> "Exit_Event" routine is compiled whenever the "mywidget" procedure is invoked. If you put the event
> handler after the main routine, it would not get compiled.
Paul is certainly correct, but I do wish he had named
that event handler MYWIDGET_EXIT_EVENT. Giving
arbitrary names to utility routines (for, in fact,
this is what any module in the file *before* the main
or command module is) will lead you, eventually, to
spending a long week trying to figure out why your
code works perfectly sometimes and not at all other
times. :-)
Here is an article if you are interested in learning
more:
http://www.fanning.com/tips/namefiles.html
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
