| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hi, I'm trying to ILV-encode the equivalent of OPTIONAL fields in ASN.1. These fields are part of a RECORD structure. If I omit the field, the FCL PM is quite tolerant about it and simply displays the specified fields (which is what I want). Unfortunately, the Iconic Map doesn't seem to like this too much and pops up an error windows which says "IMPM Internal Error", and leaves the window in which my attributes should be displayed completely blank. Is this fixed in some way in V1.2 ? Is there any other way to encode something optional ? I tried to ILV_PUT a null length field, a null address but these just give an Invalid descriptor status. Regards, Philippe.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3336.1 | VERNA::V_GILBERT | Fri Jul 10 1992 10:23 | 7 | ||
Philippe, The Iconic Map always expects to receive ALL fields of a record. The concept of returning only some of the fields is simply not implemented in V1.2. All fields are required. Verna | |||||
| 3336.2 | CCIIS1::ROGGEBAND | _ �hili��e _ | Fri Jul 10 1992 11:51 | 10 | |
Verna,
This means that it is virtually impossible to implement optional
information. If the FCL can handle it, why can't the Iconic Map simply
put out a "Field not returned" message next to the field name ? It can
do it for attributes, so I don't believe it would be that complex to
implement it for individual fields.
�hR.
| |||||
| 3336.3 | VERNA::V_GILBERT | Fri Jul 10 1992 16:09 | 17 | ||
Phillippe, First of all, the FCL and the Iconic Map handle outp in different ways. FCL simply displays what is returned in outp whereas the Iconic Map prepares a form with what it expects to be returned (prior to decoding outp). Then after all is decoded, it adds messages for extra information returned and for information expected but not returned. So somewhat different philosophy for each PM. As far as adding the functionality, no one said it would be "that" complex, but nonetheless it is one more thing to be coded, tested, etc. If it is very important to your project, that information should be passed on to the appropriate people (Gail Ferriera, Dan Carr among others). At this point, we have not added a task for the above. Verna | |||||
| 3336.4 | We're not talking about V1.2 any more | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Fri Jul 10 1992 16:14 | 6 |
And for the record, V1.2 is safely in SSB, so there will be no further changes until the next version. But since planning for follow-on versions is in progress, now is the time to provide input (see Verna's reply). -- Erik | |||||