| Re: Porting to VM [message #37301 is a reply to message #37295] |
Thu, 11 December 2003 08:55   |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 10 Dec 2003 20:19:59 -0700, David Fanning wrote:
> JD Smith writes:
>
>> I've been trying to get a large application working in the new IDLVM,
>> and have run into trouble: apparently, in all calls like:
>>
>> XManager, /NO_BLOCK
>>
>> the NO_BLOCK is ignored, and the call blocks anyway. I suppose this
>> makes sense, since IDL's non-blocking functionality is provided by the
>> command-line, which isn't there in the VM. Why would you care about
>> blocking if there's no command line to interact with? For my purposes,
>> the distinction between blocking and non-blocking is whether calls
>> which invoke XManager return immediately, or wait until the managed
>> widget dies. This isn't mentioned in the "Restrictions" on the VM FAQ
>> page. Anyone managed to deal with this issue?
>
> In SAVE files I've made recently, I've had to add JUST_REG keywords to
> all the XMANAGER calls before the last one, which will block and get
> everything else going.
I heard from an RSI engineer who directed me to a mention of this
issue in the manual, hidden in a note under XManager:
NO_BLOCK is ignored by IDL Runtime. If a main procedure uses
XMANAGER with the NO_BLOCK keyword set, IDL Runtime defers
subsequent processing of the commands following the XMANAGER
call until the widget associated with the call to XMANAGER is
destroyed.
What this doesn't say is that *subsequent*, deeper calls to
XManager,/NO_BLOCK will be respected; it's on the "main-level" call
which otherwise would have yielded to a non-existent active command
line which is ignored. The moral is, for full VM/Runtime portability,
don't rely on anything which happens *after* the very first call (or,
more correctly, any top-level call) to XManager executing right away.
Hopefully this can get added to the IDLVM FAQ.
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
