comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: widgets and objects
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: widgets and objects [message #10185] Thu, 30 October 1997 00:00
savoie is currently offline  savoie
Messages: 68
Registered: September 1996
Member
NOTE: what follows is valid for idl 4 (I don't have 5 yet, so I can't
tell you if there's a better way to do this with pointers, I'd imagine
so)

> I am trying to figure out widgets and I don't know if what i am trying
> to do is even possible - maybe it's just the wrong way to go about it.
> I have an object, during the initialization of that object I have a
> widget come up that has some checkboxes and an OK button for the use to
> select some choices during initialization.

You want to launch a widget, and it's event handler before initialization.


> Where i am encountering problems is when i call xmanager is still
> continues with initialization. Do i even want to call xmanager? And
> how do i pass back the choices that the user chose?

Sounds like you might want a /modal widget (blocking), but if you're
only launching one small widget, it shouldn't matter.

Code before initialize
code that launches widget
code that initializes




> There doesn't seem to be an easy way to pass variables around with
> widget events. Is the only way to do this is by using UVALUE?

Matthew, you're very perceptive, there are no easy ways to pass
variables around in widgets. There are a few tricks with UVALUE, but
for what you want to do, it might be easiest to do something like
this.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;
;; make the event handler for the launched widget.

PRO example_event, event

;; get the data handle.
widget_control, event.top, get_uval=sdh

;; get the uval from the event.id
widget_control, event.id, get_uval=uv

CASE uv OF
'b1' : BEGIN
message_in_here = 'Button One was pressed: plan accordingly'
END
'b2' : BEGIN
message_in_here = 'Button Two was pressed: give up. '
END
'ok' : BEGIN
;; leave this mess
widget_control, event.top, /destroy
END
ELSE: message_in_here, 'something broke'
ENDCASE

;; if the widget still exists, store the data in the sdh(handle).
IF widget_info(event.top, /valid) then $
handle_value, sdh, message_in_here, /set
END


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;
pro example
;;; example on how to pass variables to widges
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;

;;code to set up widgets
tlb = widget_base(/column)
but = widget_button(tlb, value='BUTTON 1', uval='b1')
but2 = widget_button(tlb, value='BUTTON 2', uval='b2')
ok = widget_button(tlb, value='OK', uval='ok')

widget_control, tlb, /realize

;; introduce the varaible into scope here
secret_data_handle = handle_create()

;; set it to the uval of the top level base (tlb)
widget_control, tlb, set_uvalue=secret_data_handle


;; use the /Modal keyword to keep from proceeding in this routine.
xmanager, 'example', tlb, event_handler='example_event', $
/modal

;; and here the scope is still valid here.
handle_value, secret_data_handle, what_was_there

print, 'the button last pushed before exiting gave this string:'
print, what_was_there

END ;; example
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;


> It looks as if you have to set UVALUE to some variable (structure,
> vari, or otherwise) and you can then retrieve and set it during the
> event procedure. But then how can i retrieve it later? When the
> widget comes up the initialization function finishes. Then the
> variables that hold the choices go out of scope and are inaccessible
> to any other procedure. Do i have this all wrong? -matt

I think the above example explains this pretty well.


Hope this helps.

Mattie

--
Matthew H. Savoie Systems Technology Associates
Systems Analyst Supporting NOAA Profiler Network
ph. 303.497.6642 Demonstration Division/FSL/ERL
mailto: savoie@fsl.noaa.gov <URL:http://www-dd.fsl.noaa.gov/online.html>
Re: widgets and objects [message #10186 is a reply to message #10185] Thu, 30 October 1997 00:00 Go to previous message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Matthew Hanson (matt@ktaadn.com) writes:

> I am trying to figure out widgets and I don't know if what i am trying
> to do is even possible - maybe it's just the wrong way to go about it.
> I have an object, during the initialization of that object I have a
> widget come up that has some checkboxes and an OK button for the use to
> select some choices during initialization. The choices available are
> dependent on data files read in during initialization and affects what
> happens next in initialization (data is being read in and the way it is
> organized is based on the users choices).
> Where i am encountering problems is when i call xmanager is still
> continues with initialization. Do i even want to call xmanager? And
> how do i pass back the choices that the user chose? I have it set up to
> call an event when the OK button is pressed. If the choices are valid
> in the checkboxes it closes the widget and returns the choices to the
> initialization. There doesn't seem to be an easy way to pass variables
> around with widget events. Is the only way to do this is by using
> UVALUE? It looks as if you have to set UVALUE to some variable
> (structure, vari, or otherwise) and you can then retrieve and set it
> during the event procedure. But then how can i retrieve it later? When
> the widget comes up the initialization function finishes. Then the
> variables that hold the choices go out of scope and are inaccessible to
> any other procedure.
> Do i have this all wrong?

I don't think you have it all wrong. I think you have
explored this enough to understand the problems, you just
haven't discovered the solution yet.

What you need is a modal or blocking widget that can collect
information from the user and return it to the program that
called it. This kind of widget is sometimes called a "pop-up
dialog" or "form" widget and it is usually written as a
function that returns the "form" information as the
function result.

Frankly, most people who write these kinds of widgets use
common blocks to communicate between program modules. But
because common blocks always make widget programs less useful,
I don't like to use them. In this case, I prefer to use a
pointer to store the information collected by the pop-up
dialog. Since pointers are global in scope, they are not
destroyed when the modal widget is destroyed.

Modal widgets essentially block when they get to the
XManager call in the widget definition module. So any
code below the XManager call will get executed only
after the widget is destroyed. This is where you need
to collect the information that the program's event
handler stored in the global pointer location and
return to the caller of the program.

A good example of a widget of this kind is GetImage
from my web page.

This, by the way, is just one of many IDL programming
techniques that will be taught at my IDL Programming
Techniques course Nov 18-21. There are just a few
seats left. :-)

Cheers,

David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: IDL and C interface
Next Topic: How can I make an asynchronous contact an IDL process.

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

Current Time: Wed Oct 08 13:43:52 PDT 2025

Total time taken to generate the page: 0.00594 seconds