[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Send_Event warning
- Subject: Send_Event warning
- From: Phillip & Suzanne David <pdavid(at)earthling.net>
- Date: Tue, 29 Sep 1998 20:28:46 -0700
- Newsgroups: comp.lang.idl-pvwave
- Organization: little to none
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:12319
All;
I discovered a nasty gotcha today. If you are using the Send_Event keyword to
Widget_Control, you need to be VERY careful about the events you send. I was
writing a code that sent a WIDGET_LIST event to a list I created, and I
originally wrote the event like this:
listEvent = {WIDGET_LIST, id:0L, handler:0L, top:0L, index:0, clicks:0}
All looked fine to me, but alas not all was well. First, it turns out that I
had switched the handler and top fields. However, IDL internally expects the
top field to come BEFORE the handler field, and the event wasn't even getting
sent properly! Once I figured this out, I was still observing a strange
behavior. The index of the selected item was showing up in the clicks field,
not the index field. Index was showing a zero value, and the number of clicks
wasn't showing up anywhere.
After filing a bug report with RSI, I discovered (by creating a list, then
printing out the event that arrives at it from a DIFFERENT IDL session) that
both the index and the clicks fields are expected to be long integers. Thus,
when IDL inserts the index into the index field, it was writing a long integer
into a standard integer, but wasn't performing an appropriate cast to the
smaller type. Instead, it was overwriting the clicks field.
The correct event was:
listEvent = {WIDGET_LIST, id:0L, top:0L, handler:0L, index:0L, clicks:0L}
The moral of this story is that you must be VERY careful when defining
structures of types IDL defines internally, because your definition may
override the IDL pre-determined definition with an incorrect definition,
thereby causing no end to your grief.
Personally, I'd like to see RSI change this so that all structures they use
internally are pre-initialized properly at the beginning of the session. In
the meantime, the warning stands.
Phillip David