| Re: large info structure? [message #56107] |
Wed, 03 October 2007 01:06  |
Wox
Messages: 184
Registered: August 2006
|
Senior Member |
|
|
On Tue, 02 Oct 2007 15:10:57 -0000, markb77@gmail.com wrote:
> I've finished writing the front end and now I'm in the process of
> adding some analysis. What I'm noticing is that the info structure
> that gets passed around between event handlers is getting to be very
> large. Mine is up to 130 variables, at the moment.
How does this "info structure gets passed around between event
handlers?" Where is this stored? Are you worried by the program
copying this large structure on every event?
I'm not sure what your situation is, but suppose you have the info
structure stored in the top level widget, you can access it without
copying, like this:
pro event_handler,ev
widget_control,ev.top,get_uvalue=infostruct,/NO_COPY
...[handle event: make sure there is no return here!]...
widget_control,ev.top,set_uvalue=infostruct,/NO_COPY
end
If you don't like the /NO_COPY idea, you can for example have a
pointer (created with ptr_infostruct=ptr_new(infostruct) ) to your
info structure as UVALUE of the top level widget:
pro event_handler,ev
widget_control,ev.top,get_uvalue=ptr_infostruct
...[handle event: reffer to fields as (*ptr_infostruct).(i) ]...
end
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: large info structure? [message #56119 is a reply to message #56118] |
Tue, 02 October 2007 10:52  |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On Oct 2, 9:10 am, mark...@gmail.com wrote:
> Hi,
>
> I'm writing a widget application which will serve as a data analysis
> platform for scientific image data. The idea is that after loading
> the image, there are many different types of analysis that the user
> may wish to run on it, and this application will support them all.
> There will be an 'Analysis' dropdown menu, for instance, with several
> options. I also want to make it easy to add new analysis methods to
> the program.
>
> I've finished writing the front end and now I'm in the process of
> adding some analysis. What I'm noticing is that the info structure
> that gets passed around between event handlers is getting to be very
> large. Mine is up to 130 variables, at the moment.
>
> Does anyone have a strategy to suggest for dealing with this type of
> situation? I'm worried that this info data will spiral out of
> control. I was thinking that I could break down the info data into a
> bunch of smaller structures, and hold pointers to each of those
> structures in one higher level info structure..
>
> thanks,
> Mark
Not sure what you are storing, but you can eliminate storing any
widget identifiers by giving each widget you want to store a UNAME:
myWidget = widget_draw(parent, uname='my_uname', ...)
and then using:
widgetID = widget_info(event.top, find_by_uname='my_uname')
to get the ID later when you need it.
Mike
--
www.michaelgalloy.com
|
|
|
|
| Re: large info structure? [message #56120 is a reply to message #56119] |
Tue, 02 October 2007 09:56 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
David Fanning wrote:
> markb77@gmail.com writes:
>
>> I'm writing a widget application which will serve as a data analysis
>> platform for scientific image data. The idea is that after loading
>> the image, there are many different types of analysis that the user
>> may wish to run on it, and this application will support them all.
>> There will be an 'Analysis' dropdown menu, for instance, with several
>> options. I also want to make it easy to add new analysis methods to
>> the program.
>>
>> I've finished writing the front end and now I'm in the process of
>> adding some analysis. What I'm noticing is that the info structure
>> that gets passed around between event handlers is getting to be very
>> large. Mine is up to 130 variables, at the moment.
>>
>> Does anyone have a strategy to suggest for dealing with this type of
>> situation?
>
> Ahhmumm, may I suggest writing your widget program as an object? :-)
>
> It doesn't solve the "lots of info" problem, but it
> does mean you don't have to pass anything around anymore.
> It is ALL built right into the fabric of the program.
>
> And the "lots of info" problem eventually gets sorted out
> into a "several objects" solution, which tends to compartmentalize
> the functionality and keep things from breaking when adding new
> functionality.
>
> There is a danger to this kind of programming, however. It is
> easy (WAY too easy!) to make your objects "clever". Which is
> good, don't get me wrong. But clever objects make it almost
> impossible to follow the programming flow.
Huh. I read something similar about ruby code the other day also. The real cleverly
written ruby codes tends to have many methods that don't seem to actually *do* anything -
they just call other methods, which call others, etc..
Of course, I'm mostly still in the monolithic block-o-code stage wrt ruby. :o(
cheers,
paulv
|
|
|
|
| Re: large info structure? [message #56124 is a reply to message #56120] |
Tue, 02 October 2007 08:42 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
markb77@gmail.com writes:
> I'm writing a widget application which will serve as a data analysis
> platform for scientific image data. The idea is that after loading
> the image, there are many different types of analysis that the user
> may wish to run on it, and this application will support them all.
> There will be an 'Analysis' dropdown menu, for instance, with several
> options. I also want to make it easy to add new analysis methods to
> the program.
>
> I've finished writing the front end and now I'm in the process of
> adding some analysis. What I'm noticing is that the info structure
> that gets passed around between event handlers is getting to be very
> large. Mine is up to 130 variables, at the moment.
>
> Does anyone have a strategy to suggest for dealing with this type of
> situation?
Ahhmumm, may I suggest writing your widget program as an object? :-)
It doesn't solve the "lots of info" problem, but it
does mean you don't have to pass anything around anymore.
It is ALL built right into the fabric of the program.
And the "lots of info" problem eventually gets sorted out
into a "several objects" solution, which tends to compartmentalize
the functionality and keep things from breaking when adding new
functionality.
There is a danger to this kind of programming, however. It is
easy (WAY too easy!) to make your objects "clever". Which is
good, don't get me wrong. But clever objects make it almost
impossible to follow the programming flow. (Have you ever tried
to figure out how something works in the iTool system?) So I would
resist the clever solution whenever possible and write really, really
simple solutions. Six months from now, you will be VERY glad you
did! :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: large info structure? [message #56165 is a reply to message #56110] |
Fri, 05 October 2007 08:01 |
Mike[2]
Messages: 99
Registered: December 2005
|
Member |
|
|
On Oct 2, 5:35 pm, David Fanning <n...@dfanning.com> wrote:
> mark...@gmail.com writes:
>> David - thanks for the advice, btw, but I'm just getting my head
>> around widget programming.. not quite ready for full on OO programming
>> yet
>
> Well, I can tell you are headed in that direction. :-)
Yes - it is inevitable that all will be assimilated!
Mark - A suggestion for those who are interested, but are hesitating
to go down the object path:
Pick a project that you are in the process of implementing, or even
better, something that you wrote a while back and have to update.
Make sure that it is relevant - not just a toy code, but something
that you will actually use - some library of non-trivial calculations
for example. If you are passing around lots of variables and/or large
structures and finding adding new variables to be a real pain, that
would be perfect.
Do some reading and studying up on objects (not about IDL objects, but
object orientation in general - objects are not about implementation
details and syntax, but about design). I got a lot out of reading
"Object Oriented Software Construction" by Meyer, but I'm sure there
are other things available as well. I think it is key to learn the
background without getting locked into some particular language's
implementation and syntax.
Then learn the IDL details and syntax for objects and rewrite or
extend your code using them (or whatever language you are using -
originally I did this with python).
I'll bet you'll get hooked and learn enough to be fully ready for it.
Mike
|
|
|
|
| Re: large info structure? [message #56181 is a reply to message #56107] |
Thu, 04 October 2007 15:40 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
> pro event_handler,ev
> widget_control,ev.top,get_uvalue=infostruct,/NO_COPY
> ...[handle event: make sure there is no return here!]...
> widget_control,ev.top,set_uvalue=infostruct,/NO_COPY
> end
Or, more aptly:
; make sure there is no return here, or any error or other stoppage
The problem with this NO_COPY method is that if any sort of stop,
including an error, happens while the event is being handled, your widget
program is "broken" and must be restarted, since the info UVALUE has gone
missing. If instead you store state information in a permanent place,
like on the pointer or object heap, you can easily patch up your broken
event code, retall, and continue where you left off. *So* much nicer for
development. I vote to ban /NO_COPY from general recommendation. It's a
bit more cumbersome to replace infostruct.x with (*infoptr).x, which is of
course why object widgets are so attractive (self.x).
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
