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

Home » Public Forums » archive » portabilty of programs written under IDL3.6.1 to IDL5.2
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
portabilty of programs written under IDL3.6.1 to IDL5.2 [message #14447] Thu, 04 March 1999 00:00 Go to next message
Vekemans Bart is currently offline  Vekemans Bart
Messages: 1
Registered: March 1999
Junior Member
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


Bart Vekemans
University of Antwerpen, Department of Chemistry
Universiteitsplein 1, B-2610 Wilrijk
Tel: +32-3-8202363
E-mail: vekemans@uia.ua.ac.be
Re: portabilty of programs written under IDL3.6.1 to IDL5.2 [message #14530 is a reply to message #14447] Wed, 10 March 1999 00:00 Go to previous messageGo to next message
thompson is currently offline  thompson
Messages: 584
Registered: August 1991
Senior Member
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'm not saying you shouldn't modify your code to conform to currently accepted
practice. I'm just saying that, for most things, previously written software
should still work as before, so it may not be as big a job porting the software
as it sounds, so long as you don't mind missing out on some of the newer
features such as /NO_BLOCK.

Unfortunately, I don't have any experience of using CALL_EXTERNAL in a Windows
environment, so I can't comment on the original question about programming
calls to DLLs.

William Thompson

============================================================ ===================
> 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
Re: portabilty of programs written under IDL3.6.1 to IDL5.2 [message #14539 is a reply to message #14447] Tue, 09 March 1999 00:00 Go to previous messageGo to next message
David Foster is currently offline  David Foster
Messages: 341
Registered: January 1996
Senior Member
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

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.

Dave


--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
Re: portabilty of programs written under IDL3.6.1 to IDL5.2 [message #14637 is a reply to message #14447] Tue, 16 March 1999 00:00 Go to previous message
David Foster is currently offline  David Foster
Messages: 341
Registered: January 1996
Senior Member
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: read_jpeg and write_jpeg for pv_wave.
Next Topic: device,decomposed=1 question

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

Current Time: Wed Oct 08 15:10:16 PDT 2025

Total time taken to generate the page: 0.00747 seconds