A strange problem, please help me to analyse the code.

QNX DEVELOPERS GUI Programming
1

Hello everyone,

I am encountering a strange problem. I built a photon application. And there is a callback of a button wrote as below:

typedef struct Position3dStruct
{
float x;
float y;
float z;
} Position3d;

/* QUATERNION Structure */
typedef struct QuatRotationStruct
{
float q0;
float qx;
float qy;
float qz;
} QuatRotation;
typedef struct
{
unsigned long
ulFlags,
ulFrameNumber;
QuatRotation
rotation;
Position3d
translation;
float
fError;
}TransformInformation;
TransformInformation Xfrms[0xFF];

typedef struct QuatTransformationStruct
{
QuatRotation rotation;
Position3d translation;
} QuatTransformation;

void QuatRotatePoint( QuatRotation *RotationQuaternionPtr,
Position3d *OriginalPositionPtr,
Position3d RotatedPositionPtr )
{
Position3d
UCrossV; / The cross product of the vector part of the rotation
quaternion with the original position vector */

if( OriginalPositionPtr->x < MAX_NEGATIVE ||
OriginalPositionPtr->y < MAX_NEGATIVE ||
OriginalPositionPtr->z < MAX_NEGATIVE )
{
RotatedPositionPtr->x =
RotatedPositionPtr->y =
RotatedPositionPtr->z = BAD_FLOAT;

return;
} /* if */

UCrossV.x = RotationQuaternionPtr->qy * OriginalPositionPtr->z

  • RotationQuaternionPtr->qz * OriginalPositionPtr->y;
    UCrossV.y = RotationQuaternionPtr->qz * OriginalPositionPtr->x
  • RotationQuaternionPtr->qx * OriginalPositionPtr->z;
    UCrossV.z = RotationQuaternionPtr->qx * OriginalPositionPtr->y
  • RotationQuaternionPtr->qy * OriginalPositionPtr->x;

RotatedPositionPtr->x = float(OriginalPositionPtr->x

  • 2.0 * ( RotationQuaternionPtr->q0*UCrossV.x
  • RotationQuaternionPtr->qy*UCrossV.z
  • RotationQuaternionPtr->qz*UCrossV.y ));
    RotatedPositionPtr->y = float(OriginalPositionPtr->y
  • 2.0 * ( RotationQuaternionPtr->q0*UCrossV.y
  • RotationQuaternionPtr->qz*UCrossV.x
  • RotationQuaternionPtr->qx*UCrossV.z ));
    RotatedPositionPtr->z = float(OriginalPositionPtr->z
  • 2.0 * ( RotationQuaternionPtr->q0*UCrossV.z
  • RotationQuaternionPtr->qx*UCrossV.y
  • RotationQuaternionPtr->qyUCrossV.x ));
    } /     QuatRotatePoint */

int mycallback(Ptwiget…)

{
…
…

return(Ptcontinue);

}
The application is no problem, when I finished write these code, and the result is also right. But after I closed the project, and re-open it, there are problems:

In file included from /root/20081201/sercheck/src/abmain.cc:37:
/root/20081201/sercheck/src/proto.h:26: error: variable or field ‘QuatRotatePoint’ declared void
/root/20081201/sercheck/src/proto.h:26: error: ‘QuatRotation’ was not declared in this scope
/root/20081201/sercheck/src/proto.h:26: error: ‘RotationQuaternionPtr’ was not declared in this scope
/root/20081201/sercheck/src/proto.h:26: error: ‘Position3d’ was not declared in this scope
/root/20081201/sercheck/src/proto.h:26: error: ‘OriginalPositionPtr’ was not declared in this scope
/root/20081201/sercheck/src/proto.h:26: error: ‘Position3d’ was not declared in this scope
/root/20081201/sercheck/src/proto.h:26: error: ‘RotatedPositionPtr’ was not declared in this scope
cc: /usr/qnx640/host/qnx6/x86/usr/lib/gcc/i386-pc-nto-qnx6.4.0/4.2.4/cc1plus error 1
make[2]: *** [abmain.o] Error 1
make[2]: Leaving directory /root/20081201/sercheck/x86/o-g' make[1]: *** [all] Error 2 make[1]: Leaving directory /root/20081201/sercheck/x86’
make: *** [all] Error 2

I checked the proto.h, there is a declarer about the function:
void QuatRotatePoint( QuatRotation *RotationQuaternionPtr, Position3d *OriginalPositionPtr, Position3d *RotatedPositionPtr ),
if I delete this declarer, the project is ok, compiled, executed all ok. But after I close the project and re-open it. The same problem appears again.
and the previous declarer appears again in the proto.h…
what’s the problem?

Thanks a lot,

Jason

2

The problem is, proto.h is read in before your “typedef struct”-Declarations, so your functioncalls including this declarations will void-declare the structs given.
Our workaround has been putting up a-struct-proto.h with structure information, which will be read before proto.h. Then proto.h-Function-Declarations will already know
of the struct given as parameter.

In the end we solved this, by having a global typedefinition/structdefinition place within our globals.h (all global Variables / Structs / typedefs / whatever) wich is called by the first 2 lines of our proto.h. We create the proto.h in the following manner (but remember we needed this for compatibility reason back to qnx4.25 watcom and currently running 2 forks with a Windows-hosted IDE):

proto:
-rm -f …/proto.h
-echo “#if !defined(_PROTO_H)” > …/proto.h
-echo “#define _PROTO_H” >> …/proto.h
-echo “#include “globals.h”” >> …/proto.h
c:/Programme/QNX630/host/win32/x86/usr/photon/appbuilder/approto -p $(ABSRC) $(MYSRC) >> …/proto.h
-echo “#endif” >> …/proto.h

3

This is not strange, I fact this is the expected behavior. Every time you re-generete your app. proto.h file is overwritten. Because you are declaring new types, proto.h doesn’t know yet those types when you compile your application.

AFAIK there are two solutions (maybe there are better ones)

1st) Every time you re-generete your application go to proto.h and delete thos prototypes that contain your own data defined types.

2nd) And better. In your AppBuilder, go to Project->Properties->Generate Options, and unmark “Scan sources for Prototypes”. After that, you must add all your prototypes in your code (.h or .c, it depends) , just the same you do in a normal program. The disadvantage of this method is that you have to write your prototypes every time you create you own functions, but this is not what we do all the time?, maybe a 2nd thing to consider is that maybe someone else who will work with your application in the future, should also know about this option because is not the default.

Anyway, I prefer the 2nd approach.

Regards,
JM

4

Oh, yes, what micro said could be a 3rd solution. Actually.

5

^^ would i have known there are other answers i would not just have edited ^^

6

Ok, understood…thank you very much. It is a good news for me to known that there is no problem with my own code. :wink:

7

Yes… 2nd option it’s a bit more elegant :smiley:

8

yes…I think I will use this solution. Thanks…