Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Zero Width/Height Widget Errors Solved


Has the handling of XtGetValues changed in recent versions of AIX? We saw something akin to this in the linux drops at one point.

McQ.



<johnrose@xxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx

12/13/2001 06:58 PM
Please respond to platform-swt-dev

       
        To:        <platform-swt-dev@xxxxxxxxxxx>
        cc:        
        Subject:        [platform-swt-dev] Zero Width/Height Widget Errors Solved



I have discovered the source of the zero width/height errors and am now
running Eclipse on AIX5.1.  The SWT code for Motif JNI calls has at least
one little-endian dependency in swt.c.  I saw Boris's note saying that
Eclipse currently runs on AIX, but this problem seems like it would show
up on any Power system.

XtGetValues is a Motif call that queries resource information about
widgets.  XtGetValues expects an argument list of the form:

[Requested Resource 0]
[Address 0]
[Requested Resource 1]
[Address 1]

Where Requested Resource is one of the names defined in
<X11/StringDefs.h>, and Address is a pointer to a location where the value
for that resource will be stored.  The problem with our implementation is
that the address always points to a member of an integer array.
Internally, XtGetValues performs a byte copy of the requested values to
the requested address.  In the case that a resource has a type that is
smaller than an int, strange things happen on big-endian platforms.

Consider a request for XmNwidth, which is stored in Motif as a short.  Our
JNI implementation will pass XtGetValues the address of an zeroed-out int:

hw1   hw2
0000  0000

Now XtGetValues writes 2 bytes at the address that it is given:

hw1   hw2
0012  0000

On little endian systems, this entire integer is "0x00000012."  On big,
this is "0x00120000."  My temporary workaround involves comparing the
requested resource names to XmNwidth, WmNheight, XmNx, and XmNy.  In the
case that these match, the integer member of the values array is cast
appropriately when assigned back to argList1.

The OS.java file contains several widget resource names that are sorted by
their sizes.  I think that the appropriate way to solve this would be to
associate the size with the resource name (by appending it to the string,
or in some other way.)  The JNI function could check for non-integer
sizes, and cast accordingly.  I know that this deviates form the
"one-to-one" idea of the JNI calls, but it would be better than having to
consider these issues every time the XtGetValues call is made in the Java
code.  Besides, the use of the Zeroes and Values arrays already deviates
from the idea.

Any suggestions?

John


----------------
John Rose

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Back to the top