| Re: HELP! Annoying IDL glitches... [message #6212] |
Sat, 18 May 1996 00:00 |
dean
Messages: 55
Registered: March 1993
|
Member |
|
|
deb <summa@lanl.gov> wrote:
> 2. Why does XLOADCT update color tables in real time on the Mac
> but not on the PC?
The PC does update the color tables in real time.....However, I have
seen PC's running IDL that don't and their MS Windows color settings
are setup for 64k to optimize the results for the digital scanner
attached to it.
I work with IDL 4.0.1 on Windows NT 3.51 and the color tables update
once I make a selection in XLoadCT. ( It also updates on the beta version
of Windows NT 4.0b ). My PC has the MS Windows color setting for 256
colors.
> 4a. Along similar lines, why is it that on te Mac i can set graphics
> preferences to 256 colors and it works whereas on the PC i set the
> preferences to 256 colors and !D.n_colors still comes up with many more?
THe Windows most likely are set to 64k and not 256. You most setup Windows
to handle 256 if you want your Window applications to handle 256 colors.
Kelly Dean
CSU/CIRA
|
|
|
|
| Re: HELP! Annoying IDL glitches... [message #6217 is a reply to message #6212] |
Fri, 17 May 1996 00:00  |
hahn
Messages: 108
Registered: November 1993
|
Senior Member |
|
|
deb <summa@lanl.gov> wrote:
> Here are some questions I'm hoping seasoned IDL users will be able to
> help me out with.
> 1. Why does STRMID always give a non-fatal error announcing that
> it cannot convert the given string to type Long? The function
> itself appears to extract the string expression properly.
You didn't give us an example, so I can only come up with a few
guesses:
The first parameter of STRMID is the string to extract from. Any
kind of type is allowed but the data will be converted to type
String. The other parameters of STRMID are required to be of
type Long: The position of the first character and the number of
bytes to extract. So it would be good to check what is passed as
second and third parameter.
> 2. Why does XLOADCT update color tables in real time on the Mac
> but not on the PC?
MS Windows leaves only 236 colors on a 256 color graphics board.
If you supply more than 236 colors interpolations take place.
Nevertheless, this should also occur in realtime...
> shouldn't it just pad the variable with blanks? Is there a way to read
> say 3 variables off a single line when one really only knows the format
> of the first two? ie, instead of readf,unit,format='(a34,F5.3,a80)',a,b,c,
> can one leave off that a80 and still expect to read 3 variables
> off the line (with the third variable being a string of arbitrary length)?
Your format statements forces IDL to read 34 bytes into variable a,
5 characters into variable b and 80 characters into variable c.
You can omit the field width if there aren't any blanks among the
34 characters or among the 80 characters in the third field.
Thus if you write format='(A,F5.3,A)' the first variable will get all
characters from the begining of the line up to and excluding the
first blank. If there are less than 34 characters in the first "word"
those characters are transmitted to the variable a and it length
will be adjusted.
> 4a. Along similar lines, why is it that on te Mac i can set graphics
> preferences to 256 colors and it works whereas on the PC i set the
> preferences to 256 colors and !D.n_colors still comes up with many more?
With MS Windows you can have either 236, 64k, or 16M colors.
256 colors are not available.
> Has anyone else run into similar problems and how did you fix them? ANy
> other
> pointers (no pun intended) on file i/o and/or Mac vs PC things to watch
> out for?
> Many thanks,
> -Deb Summa
> summa@lanl.gov
Norbert Hahn
|
|
|
|
| Re: HELP! Annoying IDL glitches... [message #6224 is a reply to message #6217] |
Thu, 16 May 1996 00:00 |
Robert Moss
Messages: 74
Registered: February 1996
|
Member |
|
|
I can answer a couple of these...
deb wrote:
>
> Here are some questions I'm hoping seasoned IDL users will be able to
> help me out with.
>
*snip*
>
> 3. Why does XYOUTS, when called with the keyword TEXT_AXES = 3
> rotate text such that it's mirror imaged of what one would expect for
> a regular y-axis label?
TEXT_AXES = 3 writes text as if the Y axis was the horizontal axis,
and the X axis was the vertical axis. I'm pretty sure thats why it
looks the way it does to you. You can use the ORIENTATION keyword
to flip it around if you want, of use a different value for TEXT_AXES.
Its all in the XYOUTS help file.
>
*snip*
>
> 5. Can one open a single (large) graphics window with scroll bars?
> (Not the same as the SLIDE_IMAGE command, but along the lines of the
> scroll window which is incorporated into that)
>
Piece of cake. Suppose you want a 1000x1000 window, with a 512x512
viewable area, with scroll bars. Try this:
base = widget_base()
draw = widget_draw( base, xsize = 1000, ysize = 1000, $
x_scroll_size = 512, y_scroll_size = 512 )
widget_control, base, /realize
widget_control, draw, get_value = win_num
wset, win_num
There you have it
> 6. Suppose one opens a datafile which contains an ascii header and then
*snip*
> work ok. When the binary junk is not stripped out, sometimes a STRPOS
> command finds the tag but frequently IDL chokes; when using a simple readf
> command,the error message says the input line is too long for the input
> buffer,
> even though it really isn't anywhere near 32767 characters long. Why?
> How does
> one get around this?
Well, the I/O buffer size is platform specific. For example, on
SunOS machines it defaults to 2048 bytes. From you comments I'd say
this is the root of your problem. All you need to do is use the BUFSIZ
keyword to OPENR, setting it to an appropriate large value:
OPENR, ilun, "foo.bar", BUFSIZ = 32767, /GET_LUN
As to your more general problem of finding the ASCII tag before your
data, I'm sure there are at least as many ways of doing this as there
are people to answer your question. I suggest reading the whole thing
in as a byte array (or some sufficiently large portion of it, if
reading the whole thing is unreasonable) and using the READS procedure
to parse it into whatever bits of whatever type you want.
>
> -Deb Summa
> summa@lanl.gov
Good luck. Feel free to contact me via email if you have any questions.
--
Robert M. Moss, Ph.D. - mossrm@texaco.com
------------------------------------------------------------ -
This does not necessarily reflect the opinions of Texaco Inc.
|
|
|
|
| Re: HELP! Annoying IDL glitches... [message #6225 is a reply to message #6224] |
Thu, 16 May 1996 00:00 |
Liam Gumley
Messages: 473
Registered: November 1994
|
Senior Member |
|
|
deb <summa@lanl.gov> wrote:
> 2. Why does XLOADCT update color tables in real time on the Mac
> but not on the PC?
You probably are using a PC display driver with more than 256 colors.
The same thing happens on my SGI workstation when I run it in 24 bit mode.
Try the following commands on the PC immediately after you start IDL:
device, pseudo=8
window, 0, colors=256
print, d.n_colors
> 5. Can one open a single (large) graphics window with scroll bars?
> (Not the same as the SLIDE_IMAGE command, but along the lines of the
> scroll window which is incorporated into that)
base = widget_base()
xsize = 1024 & ysize = 1024 & x_scroll_size = 512 & y_scroll_size = 512
draw = widget_draw( base, xsize = xsize, ysize = ysize, $
x_scroll_size = x_scroll_size, y_scroll_size = y_scroll_size )
widget_control, base, /realize
widget_control, draw, get_value = window_id
> 6. Suppose one opens a datafile which contains an ascii header and then
> a bunch of binary junk which ends in an ascii-readable tag. Following
> the header is a bunch of binary data. I'd like to piece thru the file
> until i find the final ascii-readable tag which denotes the start of the
> actual data.
Try the following with your own ASCII string tags:
function findtag, file, string
; Return the start byte of the first occurence of
; a string within a file. Return value is -1 if
; the string is not found.
; read the entire data file as a byte array
openr, lun, file, /get_lun
info = fstat( lun )
data = bytarr( info.size )
readu, lun, data
free_lun, lun
; convert string to a byte tag
tag = byte( string )
tagsize = n_elements( tag )
if tagsize lt 1 then goto, finish
; find first occurence of tag within data
loc = where( data eq tag( 0 ), count )
start = -1
if count lt 1 then goto, finish
for i = 0, count - 1 do begin
byte1 = loc( i )
byte2 = byte1 + tagsize - 1
compare = data( byte1 : byte2 ) - tag
tmploc = where( compare eq 0B, null )
if null eq tagsize then begin
start = byte1
goto, finish
endif
endfor
finish:
return, start
end
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
