Re: portabilty of programs written under IDL3.6.1 to IDL5.2

[David Foster <foster(at)bial1.ucsd.edu>]

William Thompson wrote:
> 
> David Foster <foster@bial1.ucsd.edu> writes:
> 
> >Bart -
> 
> >Porting your programs shouldn't be much of a problem, though you
> >will have to change your WIDGET_BASE() calls for top-level bases,
> >as well as calls to XMANAGER, in your widget programs. RSI introduced
> >the /NO_BLOCK keyword which gives you back your command-line after
> >registering a widget, and this necessitates the above changes. Also,
> >RSI changed the behavior of modal widgets, and moved this /MODAL
> >keyword. The changes are minimal, but if you have a large collection
> >of widget programs it may take some time to update them. Be aware
> >that until you do most of your widget programs won't work.
> 
> Is this really true?  Although the recommendation now is to put /MODAL in the
> call to WIDGET_BASE instead of XMANAGER, doing it the old way does still work.
> We had some problems with modal widgets that called non-modal subwidgets, but
> RSI gave us a simple fix to xmanager.pro that solved that problem.  (It's a
> good thing, too, because the newly recommended way of implementing modal
> widgets is simply unacceptably limited, IMHO.)  I'd be glad to share that
> modified xmanager.pro with anybody who wants it.

I still maintain that if one is going to upgrade to IDL 5.x, they
should be prepared for the worst. In our case, the problem you 
mention about modal widgets calling non-modal widgets led to about
60% of our software being unusable until minor changes were made
to each widget module. I agree that their newer implementation
of modal widgets is very limiting, and I'm glad you found a way
around this. It sounds like the modified XMANAGER.PRO may make
Bart's life a bit easier.

Dave Foster

> 
> ===============================================================================
> >Vekemans Bart wrote:
> >>
> >> Years ago our Institute purchased IDL3.6.1 and since then
> >> I am working on a program that simultaneously can control
> >> several hardware cards by means of CALL_EXTERNAL, which
> >> invokes functions of the DLL libraries delivered with
> >> the various cards. Until now I was using 16-bit DLLs, as
> >> this version of IDL is restricted to calls to 16-bit DLLs
> >> in Windows.
> >> Unfortunately, new cards are now delivered with 32-bit DLLs,
> >> and as such I cannot use the delivered libraries of these
> >> new cards. I have now the following question. Is my program
> >> portable from IDL3.6.1 to IDL5.2 or has the programming
> >> environment changed so much that I have to rewrite my
> >> whole program when I want to upgrade to IDL5.2 ?
> >> I want to try to find someone who experienced the same problems,
> >> and I would be very gratefull to her/him if she/he wants
> >> to share her/his experience about this problem.
> >>
> >> Waiting for someone to answer,
> >>
> >> greetings from Antwerpen (Belgium, Europe),
> >>
> >>                         Bart Vekemans

-- 

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    David S. Foster         Univ. of California, San Diego
     Programmer/Analyst     Brain Image Analysis Laboratory
     foster@bial1.ucsd.edu  Department of Psychiatry
     (619) 622-5892         8950 Via La Jolla Drive, Suite 2240
                            La Jolla, CA  92037
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~