comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: IDL Programming Odditites

IDL Programming Odditites
type: item
description: Hi Folks, As you know, the best way to learn something new about IDL is to post code to this newsgroup. My latest offering, which I made a week or so ago, is no exception. Here is a preliminary list of some new things I learned. I hasten to point out (in the interest of boosting my Microsoft shares) that FEW of these errors were present in my Windows version of IDL. :-) 1. There is an undocumented minim un window size for an IDL object graphics window on all (?) platforms other than Windows. I'm not sure exactly what that size is, but I do know that the window I was creating in my program was too small. This manifests itself as one or both of these errors: Program caused arithmetic error: floating divide by 0. Program caused arithmetic error: floating illegal operand. 2. There appears to be a bug in some (all?) X Windows devices that prevents object graphics windows from being resized and then having the view displayed properly: theWindow->Dimensions=[event.x, event.y] The view is always mapped into the old window dimensions, even if you try to update the view mapping. The only work-around is to destroy the old window object and create a new one in the right size. 3. The very useful RSTRPOS function, which searches a string from back to front, has been made obsolete. In IDL 5.3 you should use the STRPOS function with the REVERSE_SEARCH keyword set. 4. Don't bother trying to set the size of a droplist widget after the widget has been created on X displays. The new value is totally ignored. This is bad news for those of us who like to create a professional looking layout in our widget programs. 5. All bets are off if you are using object graphics windows and hardware rendering on 8-bit display devices. Those of us who have worked with object graphics for a while have realized from the beginning that all bets are pretty much off on *any* 8-bit device, but this is a warning that this is *especially* true when using hardware rendering (the default setting). I'd say that …
creator: davidf
date: 2000-01-24T08:00:00-00:00