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

IDL Runtime
type: item
description: Hi there! Is there anyone using IDL runtime licenses? I guess this is a RTFM, we probably have some information about it somehere, but I didn't find any yet. The online help does not mention them, 'idl -h' tells nothing about command line parameters. What I found out is: IDL started with the command line parameter '-rt' looks for the file 'RUNTIME.SAV', restores it, and executes the procedure MAIN. But there must be other parameters, at least for specifying the filename, idl -rt -file ~/idl/myprogram.sav or something like this. Thanks for any insights! Alex -- Alex Schuster Wonko@weird.cologne.de alex@pet.mpin-koeln.mpg.de
creator: wonko
date: 1997-05-31T07:00:00-00:00

Re: IDL RunTime
type: item
description: Kelly Dean (krdean@lamar.colostate.edu) writes: > Does a Runtime version of IDL come with the CD distribution? > > I am making RecCDs with GOES satellite data and I would like to add an > IDL sav file with one of my routines to display these images. Incase a > borrower of these CDs does not have IDL on their machine, I would like > to allow them to use the "runtime" version of IDL to use my routine to > display the imagery. I'm not sure about UNIX installations, but every Windows CD-ROM I've ever installed has installed a run-time version of IDL along with the regular version. But since you *have* to install IDL to have either version available, the question seems moot to me. What difference would it make which version they ran your application in? Also realize that your IDL save file is going to be version specific. That will easily cut out a large faction of your potential users unless you provide save files for *all* expected IDL versions. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
creator: davidf
date: 2000-02-06T08:00:00-00:00

Re: IDL RunTime
type: item
description: In article <MPG.130788bbb3a619e3989a11@news.frii.com>, davidf@dfanning.com (David Fanning) wrote: > Kelly Dean (krdean@lamar.colostate.edu) writes: >> Incase a borrower of these CDs does not have IDL on their machine, I >> would like to allow them to use the "runtime" version of IDL to use >> my routine to display the imagery. I think someone is confused (maybe me). You *need* to have IDL installed on your machine (Runtime or Development version) in order to execute an IDL sav file. It is not a standalone executable. If a user has "runtime" IDL installed, then they have "IDL on their machine". Development licenses allow either the development or runtime configuration, whereas runtime licenses are strictly runtime configuration. Hope this helps. -- "They don't think it be like it is, but it do." Oscar Gamble, NY Yankees Sent via Deja.com http://www.deja.com/ Before you buy.
creator: wbiagiot
date: 2000-02-07T08:00:00-00:00

Re: IDL RunTime
type: item
description: Kelly Dean (krdean@lamar.colostate.edu) writes: > If ENVI, RiverTools, ION, etc... can be issued with "runtime" IDL, I was > just wondering if any of my tools could be issued with "runtime" IDL. You can issue any application you like, including your own, with IDL runtime licenses. (I do this all the time for clients.) You just have to be willing to pay for each one of them. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
creator: davidf
date: 2000-02-07T08:00:00-00:00

Re: IDL RunTime
type: item
description: I could be mistaken..... If ENVI, RiverTools, ION, etc... can be issued with "runtime" IDL, I was just wondering if any of my tools could be issued with "runtime" IDL. I thought I seen this done with an application developed under IDL 4.0 by one of my colleaques a long time ago. Kelly Kelly Dean wrote: > Does a Runtime version of IDL come with the CD distribution? > > I am making RecCDs with GOES satellite data and I would like to add an > IDL sav file with one of my routines to display these images. Incase a > borrower of these CDs does not have IDL on their machine, I would like > to allow them to use the "runtime" version of IDL to use my routine to > display the imagery. > > Kelly Dean > CSU/CIRA
creator: Kelly Dean
date: 2000-02-07T08:00:00-00:00

Re: IDL Runtime
type: item
description: Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: > I've developed a widget program which must now be run on IDL runtime. > Problem is that whenever a "Cancel" button is selected (which > should return execution to the initial menu options) the entire program > exits and IDL too! Does anyone know why this is? I'm using the RETALL > command in the program to return to the top level (which is XMANAGING > the menu) when "cancel" is pressed. It seems to be working fine with > the normal development license?? I think your main problem is that this program works at all, anywhere. Using RETALL to negotiate a widget program is one strange way to write a widget program! But RETALL will get you all the way back to the main program level (command line), which clearly doesn't exist in a run-time environment. I think I would be thinking about writing IDL programs in more conventional ways. :-) Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
creator: David Fanning
date: 2001-11-14T14:01:30-00:00

Re: IDL Runtime
type: item
description: Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: > Thanks for the replies re RUNTIME and RETALL. Oh, oh. I was afraid of this. :-( > Perhaps my problem is some confusion relating to how XMANAGER works. As > far as I can understand if I create a bunch of buttons under a TL base, > then call XMANAGER, the program is 'hung' in a loop checking whether > events are being processed. So far OK? Well, not exactly. There isn't any "loop" to get hung up in, really. I prefer to think that an officer of the court has been assigned to to "pay attention", but it's probably a matter of semantics, and it doesn't really matter which metaphor you prefer to use. > If one of the buttons is clicked, > then we jump to the event handler for that button; but suppose that the > event handler calls an event-processing routine that calls another, that > calls another etc. - so we end up a few levels deep in the processing of > the event. I have used modal prompts along the way in this event > processing so that the user can decide "Yes" "No" "Maybe" and so on. One > option I want to give them is "Cancel back to the bunch of buttons." > Retall seemed a useful way of getting back to main program level, which am > I right in saying will enter us back into the XMANAGER loop ready for the > next event?? No, I don't think so. I really think it is a minor miracle that your program works at all, but I believe it is because widget programs don't really need to use XMANAGER. (And I really don't want to get into any of this at all.) I think your program works, but for the wrong reason, I guess is what I am trying to say. > David says, "Try a more conventional way than using retall" - > what is the conventional way of returning from deep in event-processing > programs back to the menu buttons? The "conventional" way of writing widget programs is to get into and out of event handlers as fast as possible, not to spend the rest of the afternoon in there trundling around. But I guess I can see some sort of hie…
creator: David Fanning
date: 2001-11-14T23:31:44-00:00

Re: IDL Runtime
type: item
description: Andre Kyme wrote: ... > Retall seemed a useful way of getting back to main program level, which am > I right in saying will enter us back into the XMANAGER loop ready for the > next event?? ... I believe it will cause XMANAGER itself to exit. > ...David says, "Try a more conventional way than using retall" - > what is the conventional way of returning from deep in event-processing > programs back to the menu buttons? ... Use 'return'. If the wrong things happen when you return from the procedure or function, then there's a defect somewhere in your code; either in the procedure/function itself, or in one of the things that directly or indirectly calls it. > ... There are no widgets to destroy, I just > want to get back to the state the application was in when first loaded. That's the problem. RETALL returns to the state before the application was loaded. i.e.: no application. -- James Kuyper MODIS Level 1 Lead Science Data Support Team (301) 352-2150
creator: James Kuyper
date: 2001-11-14T23:49:20-00:00

Re: IDL Runtime
type: item
description: Hi David, Appreciate the reply, but as yet nobody has given me a good explanation of how XMANAGER works and I don't find the documentation provided by RSI insightful at all. I'm quite happy to adjust my program design - but I'm not sure exactly how to do this. People keep replying that "Your program must be so complicated..." but it is really quite simple! Or at least the IDEA is! I expect the idea would be a very typical widget programming endeavour! To briefly describe what my design structure is: About 5 widget buttons get created and realized to form a menu Each has an event handler I call XMANAGER to manage the created widgets I wait... Oh, button number 1 was pressed! Well we better do what event handler number 1 tells us to do. The event-handler is just a couple of programs that follow one after the other - is that complicated!! Some of them call other programs - But execution is just moving sequentially through the event handler routine. Pretty standard I think. The actual programs in the event handler involve the user drawing a region of interest (I don't use draw widgets, just a standard graphics window and a routine involving the cursor command) and involve moving it around, and also confirming they are happy with its location. Now suppose they get fed up with the whole business (like I'm feeling right now) and want to go and have a coffee - so when they are asked to confirm the region (I use dialogue_message with the /cancel keyword), they click "CANCEL" - Why should it be so complicated to just return to your menu options when I detect the cancellation? This would have to be a pretty standard widget application surely - menu, option, back to menu, option, back to menu...? What is the conventional philosophy for doing 'this'? So again, the design involves having options initially (menu). Some options aren't relevant initially such as "Save" and "Print", so if the user clicks on these I issue messages for the user telling them there's no point clicking th…
creator: Andre Kyme
date: 2001-11-15T00:22:24-00:00

Re: IDL Runtime
type: item
description: Andre Kyme wrote: > The event-handler is just a couple of programs that follow one after the other > - is that complicated!! Some of them call other programs - But execution is > just moving sequentially through the event handler routine. Pretty standard I > think. > The actual programs in the event handler involve the user drawing a region of > interest (I don't use draw widgets, just a standard graphics window and a > routine involving the cursor command) and involve moving it around, and also > confirming they are happy with its location. > Now suppose they get fed up with the whole business (like I'm feeling right > now) and want to go and have a coffee - so when they are asked to confirm the > region (I use dialogue_message with the /cancel keyword), they click "CANCEL" - > Why should it be so complicated to just return to your menu options when I > detect the cancellation? This would have to be a pretty standard widget > application surely - menu, option, back to menu, option, back to menu...? What > is the conventional philosophy for doing 'this'? Are you saying that you have *one* event handler that gets the user to draw a ROI, move it around, confirm that they're happy with it? If so, I would consider breaking these up into separate events. If you put all the code that handles button events in one routine, it could look something like this (I've assumed that you use a draw widget, even though you don't): case which_button of 'draw': begin ; make the draw widget start returning events: widget_control, info.draw_widget, /motion_events,$ /button_events ; (an event handler for the draw widget could ; store how the region of interest has been ; defined in the info structure) widget_control, info.confirm_button, sensitive=1 widget_control, info.cancel_button, sensitive=1 end ; draw 'confirm': begin ; don't pay attention to any more cursor ; events: widget_control, info.draw_widget, motion_events=0, $ button_events=0 widget_control, info.confirm_button, sensitive=…
creator: Kristine Hensel
date: 2001-11-15T01:20:01-00:00

Re: IDL Runtime
type: item
description: Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: > Appreciate the reply, but as yet nobody has given me a good explanation of how > XMANAGER works and I don't find the documentation provided by RSI insightful at > all. Yes, well, no one wants to commit themselves because no one is really sure *how* it works. The documentation was written in 1946. I think it's safe to say, however, that most of us are pretty sure it doesn't work the way you seem to think it works. :-) > I'm quite happy to adjust my program design - but I'm not sure exactly how > to do this. People keep replying that "Your program must be so complicated..." > but it is really quite simple! Or at least the IDEA is! I expect the idea would > be a very typical widget programming endeavour! It's the experience of this newsgroup (or, at the very least, this correspondent) that the hardest questions come from the simplest things. > To briefly describe what my design structure is: > > About 5 widget buttons get created and realized to form a menu > Each has an event handler > I call XMANAGER to manage the created widgets > I wait... > > Oh, button number 1 was pressed! > Well we better do what event handler number 1 tells us to do. > > The event-handler is just a couple of programs that follow one after the other > - is that complicated!! Some of them call other programs - But execution is > just moving sequentially through the event handler routine. Pretty standard I > think. Then, no problem. When you get to the end of all the sequential programs, you exit the event handler and you are ready to process the next event. (Which has already queued up, no doubt, because users are murder on slow event handlers. But that's another story.) > The actual programs in the event handler involve the user drawing a region of > interest (I don't use draw widgets, just a standard graphics window and a > routine involving the cursor command) and involve moving it around, and also > confirming they are happy with its location.…
creator: David Fanning
date: 2001-11-15T01:21:32-00:00

Re: IDL Runtime
type: item
description: Hi David, I wrote: > The actual programs in the event handler involve the user drawing a region of > interest (I don't use draw widgets, just a standard graphics window and a > routine involving the cursor command) and involve moving it around, and also > confirming they are happy with its location. You wrote: Well, IMHO, this is a huge mistake. And this part is going to have to be re-written if you want to run this as a run-time program, I think. Run-time IDL will not work with "hybrid" programs like this, it seems to me, although I haven't tried it. What do you mean a "hybrid program" ? You write: Here is the problem. How do you know when they are finished? What they are doing is not in your "widget space", so you can't get any feedback from them. What should be happening is that the user is generating events that you are handling in your widget program. Here they are working outside the box, and you can't get any feedback from them. I reply: The user clicks the "Analysis" button They have a group of images displayed before them They are asked to choose which one they want to draw an ROI on (dialogue_message) As soon as the dialogue is OK'd the cursor command is waiting Cursor waits until something in the graphics window is selected - clicks outside the window have no effect. They are asked for confirmation of the image (dialogue_message) They are then prompted to draw an ROI (dialogue_message) Cursor is waiting for the first point A right mouse click finishes the region They are presented with the next image and asked to move the ROI (that they just drew) over the new image (dialogue_message) Cursor is waiting for the first position to move it to And so on for the remaining images Eventually they are all done, but in the meantime the user has only had limited responses and I think I've been prepared for all of them?? Event-handler ends Ready for next event from button menu I can see that draw widgets and motion events might be 'nicer' but is it necessary. I'm jus…
creator: Andre Kyme
date: 2001-11-15T01:58:13-00:00

Re: IDL Runtime
type: item
description: How come cursor doesn't work with runtime? Andre
creator: Andre Kyme
date: 2001-11-15T02:45:46-00:00

Re: IDL Runtime
type: item
description: Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: > What do you mean a "hybrid program" ? I mean a program that is half-widget and half something else. You haven't indicated whether your program runs without the XManager call, but I suspect you are in the nether world between a widget event loop (whatever the hell that means) and the interpreter. (And where are all you guys (Pavel!) who are suppose to know something about this? I'm on my tippy toes here and I still feel like I'm drowning.) I think this ... whatever ... is what is causing your problem. I can assure you that if this program was a proper widget program (without any RETALLs, for sure) it would run as a run-time program. > The user clicks the "Analysis" button > They have a group of images displayed before them > They are asked to choose which one they want to draw an ROI on (dialogue_message) > As soon as the dialogue is OK'd the cursor command is waiting How does dialog_message return to you the window they want to draw in? > Cursor waits until something in the graphics window is selected - clicks outside the > window have no effect. > They are asked for confirmation of the image (dialogue_message) > They are then prompted to draw an ROI (dialogue_message) > Cursor is waiting for the first point > A right mouse click finishes the region > They are presented with the next image and asked to move the ROI (that they just > drew) over the new image (dialogue_message) > Cursor is waiting for the first position to move it to > And so on for the remaining images > Eventually they are all done, but in the meantime the user has only had limited > responses and I think I've been prepared for all of them?? > Event-handler ends > Ready for next event from button menu If this works, what is the problem? > I can see that draw widgets and motion events might be 'nicer' but is it necessary. > I'm just using cursor as part of my event-handling. Cursor has nothing whatsoever to do with event handling, at least not in any w…
creator: David Fanning
date: 2001-11-15T02:49:31-00:00

Re: IDL Runtime
type: item
description: Fancy that! You're right about cursor not working on runtime! Here I was thinking I was talking to some maniac bent on rubbisging a perfectly good routine. : ) Just kidding. Well, it looks like it's back to the drawing board. Thankyou to all those who have made some contribution to this very depressing of conclusions. Andre
creator: Andre Kyme
date: 2001-11-15T02:53:22-00:00

Re: IDL Runtime
type: item
description: Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: > Fancy that! You're right about cursor not working on runtime! Here I was thinking I was > talking to some maniac bent on rubbisging a perfectly good routine. : ) Whew! And I really was thinking I was just getting in deeper and deeper. :-) Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
creator: David Fanning
date: 2001-11-15T03:03:13-00:00

Re: IDL Runtime
type: item
description: "David Fanning" <david@dfanning.com> wrote in message news:MPG.165cdb22e9d9fcf4989778@news.frii.com... > Andre Kyme (nak@imag.wsahs.nsw.gov.au) writes: >> You must be getting tired of this nutter on the other end of your replies David! > > Are you talking about Logan? Oh ... you! I am not nuts and I am not tired of David's replies. Hope this clears things up for everyone. -L
creator: Logan Lindquist
date: 2001-11-15T13:27:12-00:00

Re: IDL Runtime
type: item
description: Dear Andre, dear David I am sorry that's I have not spent time last three weeks to read more detailed this issue Attached is a small example from our IDL widget lessons which shows a very nice functionality about starting an event while an event is already running. You have not to wait until UP is finished, you can directly press DOWN or QUIT. The trick for this is to call always as event_pro set by the widget definition "wid1_event". In the cases of 'wid1_UP' and 'wid1_DOWN' always a second own event manager "wid1_own_event" is started which did nothing else as asking for events from the buttons. If an event by a button is returned the event procedure "wid1_event" is runnind independent from the XMANAGER. This means the "wid1_event" runs many times started like child-processes and only if you have used pointers you know the variables in each process and they are the same. If you press "Quit" all of this child-processes of "wid1_event" are stopped at once. I have many of my widgets programmed in this way, but it is hard to reprogramm an existing one. Sometimes it is enough to give only a few buttons these functionality as an addition. If I should explain something in more detail please give me a note. David if you like you can add this widget to your tips page. regards Reimar > > So again, the design involves having options initially (menu). Some options > aren't relevant initially such as "Save" and "Print", so if the user clicks on > these I issue messages for the user telling them there's no point clicking > these ones yet. The most likely thing they will want to do initially is > "Analysis". "Analysis" is the button with the event handler I described above: > programs that just simply get executed one after the other. During execution of > the event-handler programs, the menu buttons can't be clicked, mainly due to > the fact that the region drawing/moving uses the CURSOR command - so the > computer is waiting for mouse clicks inside the graphics window. (You mi…
creator: R.Bauer
date: 2001-12-06T17:49:29-00:00

Re: IDL runtime
type: item
description: Wox, Thank you for your reply. Hopefully I answer all of your questions. > What keywords are you using in calling LMGR? I started with DEMO, then the rest below: IF LMGR(/DEMO) GT 0 THEN PRINT, "This runtime is in demo mode. Please contact xyz." IF LMGR(/CLIENTSERVER) GT 0 THEN PRINT, "Obtained client server." IF LMGR(/EMBEDDED) GT 0 THEN PRINT, "This runtime is in EMBEDDED mode. Please contact xyz." IF LMGR(/RUNTIME) GT 0 THEN PRINT, "This runtime is in RUNTIME mode." IF LMGR(/STUDENT) GT 0 THEN PRINT, "This runtime is in STUDENT mode. Please contact xyz." IF LMGR(/VM) GT 0 THEN PRINT, "This runtime is in VM mode. Please contact xyz." R = LMGR(LMHOSTID = HOSTID) PRINT, "Host ID: " + strtrim(HOSTID,2) R = LMGR(INSTALL_NUM=INSTALL) PRINT, "Install number: " + strtrim(INSTALL,2) R = LMGR(SITE_NOTICE=SITE) PRINT, "Site notice: " + strtrim(SITE,2) > > From the help: > "The fact that the IDL session is running in runtime mode does not > imply that a runtime license is in use." > > How did you check whether a license was found when running in runtime > mode? When I would execute the runtime, I would output the information from the code above first. It would then go about, and start it's image processing. Then I compared the runtime license number and site notice (for what it's worth) to the actual runtime license contract on file with ITT. I then verified it on the license server using, lmstat, that it is indeed using a runtime license. Everything seemed valid. I suppose it's just one of those oddities. Thanks again.
creator: Jon Sattelberger
date: 2010-10-20T14:14:47-00:00

Re: IDL runtime
type: item
description: On Oct 20, 10:14 am, Jon Sattelberger <jon.sattelber...@gmail.com> wrote: > Wox, > > Thank you for your reply. Hopefully I answer all of your questions. > >> What keywords are you using in calling LMGR? > > I started with DEMO, then the rest below: > > IF LMGR(/DEMO) GT 0 THEN PRINT, "This runtime is in demo mode. > Please contact xyz." > IF LMGR(/CLIENTSERVER) GT 0 THEN PRINT, "Obtained client server." > IF LMGR(/EMBEDDED) GT 0 THEN PRINT, "This runtime is in EMBEDDED > mode. Please contact xyz." > IF LMGR(/RUNTIME) GT 0 THEN PRINT, "This runtime is in RUNTIME > mode." > IF LMGR(/STUDENT) GT 0 THEN PRINT, "This runtime is in STUDENT mode. > Please contact xyz." > IF LMGR(/VM) GT 0 THEN PRINT, "This runtime is in VM mode. Please > contact xyz." > > R = LMGR(LMHOSTID = HOSTID) > PRINT, "Host ID: " + strtrim(HOSTID,2) > R = LMGR(INSTALL_NUM=INSTALL) > PRINT, "Install number: " + strtrim(INSTALL,2) > R = LMGR(SITE_NOTICE=SITE) > PRINT, "Site notice: " + strtrim(SITE,2) > > > >> From the help: >> "The fact that the IDL session is running in runtime mode does not >> imply that a runtime license is in use." > >> How did you check whether a license was found when running in runtime >> mode? > > When I would execute the runtime, I would output the information from > the code above first. It would then go about, and start it's image > processing. Then I compared the runtime license number and site notice > (for what it's worth) to the actual runtime license contract on file > with ITT. I then verified it on the license server using, lmstat, that > it is indeed using a runtime license. Everything seemed valid. I > suppose it's just one of those oddities. > > Thanks again. Hi Jon!! --Gray
creator: Gray
date: 2010-10-20T20:19:32-00:00