Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: getMeter() function

  1. #1
    Junior Member
    Join Date
    Apr 2006
    Posts
    27

    getMeter() function

    Have you tried it ?

    I'm experiencing pbs...

    I want to get the scale by doing this :

    Code :
    /* Unit */
    if(thisAsset->getUnit() != NULL)
    	unit = (f32) thisAsset->getUnit()->getMeter();
    else
    	unit = 1.0f;

    But I get bad values like 3.5E10-37
    I don't understand because when I check the source code of the DOM it's quite simple.

    Regards,

  2. #2
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    Hello,
    I am unsure of exactly why you are getting the problem you are but this is what I found out as I looked into it.

    getMeter() returns a domFloat, which is actually a c++ double. When casting it to a float you sometimes get some error. The file I tested this on used meter="0.01" and the value I got after the cast was 0.009999999998.
    But tests with the value of 0.0 or 1.0 there was no inaccuracy.

    I really don't know why you are getting such an odd value.

    -Andy

  3. #3
    Junior Member
    Join Date
    Apr 2006
    Posts
    27
    Apparently, the object is badly initialized. If I put a setMeter(1.0f) just before the getMeter() I get a good value.

    It's weird !

  4. #4
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    I don't know what to tell you. I cannot recreate this issue you are having.

    If the <unit> element is not in the document being loaded you would get NULL in that check. If the <unit> is specified but the "meter" attribute is ommitted the default value should be set to 1.0. If the "meter" attribute is specified then it should read it without any problems. I tested all 3 of these cases and they all worked correctly.

    This is all auto-generated code from the schema. It gets handled in a generic manner. If this didn't work here then there would be the same problem everywhere.

    I'm sorry I don't know how to help you any further but if you figure out exactly what is causing this I would be interested in hearing about it.
    -Andy

  5. #5
    Junior Member
    Join Date
    Apr 2006
    Posts
    27
    Well, I just work on this problem again. The solution I found is to invert
    Code :
    	xsNMTOKEN attrName;
    and
    Code :
    domFloat attrMeter;
    It's not the ultimate solution but it's work for now.

  6. #6
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    What do you mean by "invert"? Did you change the order of declarations in the header file?

    Andy this implies there might be a memory overrun on attrName. Better check its initialization.

  7. #7
    Junior Member
    Join Date
    Apr 2006
    Posts
    27
    Yes, that what I did.

    When I debug the value is good, it's just that the function doesn't return the good value. Ther is a shift of 4 bytes I think when I look in the in the assemblor code.

    As it works now, I'm not sure i want to spend hours to find a solution.

  8. #8
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    Quote Originally Posted by marcus
    Andy this implies there might be a memory overrun on attrName. Better check its initialization.
    Its just a pointer to a string. That wouldn't overrun any other memory,
    unless the reflection is wrong and the compiler is generating the wrong offset and storing the pointer in the wrong place.

    jairbubbles, what OS are you running? and anything else not typical on your system? are you running a 64bit OS?

    -Andy

  9. #9
    Junior Member
    Join Date
    Apr 2006
    Posts
    27
    I'm running Win XP SP2, using VS 2003 on a 32 bit system. Quite an usual system...

  10. #10
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by jairbubbles
    Ther is a shift of 4 bytes I think when I look in the in the assemblor code.
    This happens to be the difference in size between a C float and double. Andy perhaps there is an offset bug in the daeMeta for this field?

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •