byte array dataref question

[tkyler]

in a module I have declared a struct:

struct xs_timer_data{
    int         hours;
    int         minutes;
    float       seconds;
    timer_mode  mode;
    char        timer_text[9];
};

and allocated some storage on the heap and have a ptr to this storage. I then stuff the struct with some stuff

        struct xs_timer_data*   inRefcon = (xs_timer_data*) malloc(sizeof(struct xs_timer_data));

        inRefcon->hours          =   00;
        inRefcon->minutes        =   00;
        inRefcon->seconds        =   00;
        inRefcon->mode           =   STOP;
        strcpy (inRefcon->timer_text, "00:00:00");

I register a dataref with a "read byte array" callback and here's my read callback..write callback is NULL:

long    xs_getTimer_CB(void* inRefcon,  void* outValue, int inOffset,   long inMaxLength)

{
        xs_timer_data* ptr = (xs_timer_data*)inRefcon;
        strcpy((char*)outValue, ptr->timer_text);
        return inMaxLength;
}

To be honest, I really don't know what's going on here byte wise and I'm sure that's my problem. I'm not fully a programmer, but certainly feel like I'm walking a glass laden path on the way there. In xplane, this code produces a dataref of type int with the value zero. I just need some help reconciling how the bytes allow xplane to know if something is an int or data..and how this is manifested at the keyboard (i.e. where do I type in such values).

[twinpropflyer]

Hi Tom,

you may find this post helpful: http://forums.x-plane.org/index.php?showtopic=37383&view=&hl=byte%20array&fromsearch=1 

Cheers

Jan

[tkyler]

Crap....I was registering it as type Int myself....THAT would explain why I was getting an int back....everything else is done correctly I think though I have yet to test.  Thanks Jan for mentioning that "extra" bit about the XPLMDataType...a bad habit of cutting/pasting code in this case.

AHHHH...thanks again Jan.  Worked with that simple data type change.  It's always the littlest things.

[tkyler]

Well the datarefs works.....but doesn't show up in a generic text instrument.  I note that you have some..."+ length" after your dataref in your memcpy line...what is this for Jan?..what's getting added after your text and why?  I suspect I need to familiarize myself a bit more with the byte array and length.

[twinpropflyer]

Hi Tom,

the "Datab" (or Byte-Array I called it for me ;-)) is used like the other array type datarefs. You need to reserve a memory area for your data, e.g. char MyText[10]. Then, when the user of your dataref calls your provider function, he provides a pointer to a reserved memory area of its own (void* outValue), an offset to your pointer, from which he want to get the data from (int inOffset) and finally the count of data elements he want to get (long inLenght).

In your provider function you now just copy the content from your memory area to the memory area of the user, where inOffset defines the starting point from your pointer and inLength defines the size of the copied memory block. In case of the Datab ref, inLength is always the size in bytes already, for other types you have to calculate the bytesize like "sizeof(int) * inLength" for an integer array.

Example: "memcpy(outValue, MyRefText + inOffset, inLength)", where inOffset is "0" and inLength is "10", this will copy 10 bytes starting from MyText + 0 to the provided memory pointer "outValue". Of course, you would have to make sure, that inOffset and inLength are always in the allowed range of your reserved memory, otherwise the memcopy function could cause crashes ;-).

Thats the solution that works for me and it came straight out of the examples of the SDK, but there may other working solutions too. Also I just realized, that the range checking code in the example from the .org thread is not very robust, so I will have to change my provider functions a bit.

Cheers

Jan

[tkyler]

Thanks Jan.  Still can't get it to work with the generic instrument.  I can use Sandy's dataref inspector to view the output..and that comes out working great, but just can't seem to get the output into a generic text instrument...maybe you can see something funny.

Here's the struct definition:

 struct xs_timer_data{
    int         hours;
    int         minutes;
    float       seconds;
    timer_mode  mode;
    long int         timer_int;
    char        timer_text[9];
};

and the struct declartion and memory from the heap:

        struct xs_timer_data*   inRefcon = (xs_timer_data*) malloc(sizeof(struct xs_timer_data));

and the registration:

	XPLMDataRef myDataRef = XPLMRegisterDataAccessor(myDataRefName, xplmType_Data, 1,
										 NULL, NULL,
										 NULL, NULL,
										 NULL, NULL,
										 NULL, NULL,
										 NULL, NULL,
										 xs_getTimerChar_CB, NULL,
										 inRefcon, NULL);

and the callback:

long    xs_getTimerChar_CB(void* inRefcon,  void* outValue, int inOffset,   long inMaxLength)

{
        xs_timer_data* ptr = (xs_timer_data*)inRefcon;
        memcpy(outValue, ptr->timer_text, 9);
        return 9;
}

This says to me....copy 9 bytes from ptr->timer_text to outValue....no offset.

Below is a screenshot in sim showing the issue.  I'm beginning to think it's not the code, but perhaps my use of the generic text instrument or sloppy UV mapping...I'm having trouble getting ANYTHING to show in that generic text instrument

[tkyler]

Something weird is definitely going on here.  I can't even display something as simple as the tail number in this generic text instrument.  I'm going to quit focusing on the code and investigate other stuff. 

[tkyler]

YEE-HA!  I just lost a stupid number of hours trying to solve a problem that turned out to be a bug in xplane and not any fault of my own after all....uh...other than that incorrect XPLM type....*cough...*cough..thanks Jan.

Anyhow....the problem is that generic text is not working when used with ATTR_cockpit_region in the cockpit object.  I switched back to ATTR_cockpit and everything just worked.

[Jack Skieczius]

good luck tom on getting this to work.

just looking over your thread here makes my head hurt, so i can just image what your feeling.

[twinpropflyer]

YEE-HA!   I just lost a stupid number of hours trying to solve a problem that turned out to be a bug in xplane and not any fault of my own after all....uh...other than that incorrect XPLM type....*cough...*cough..thanks Jan.

Anyhow....the problem is that generic text is not working when used with ATTR_cockpit_region in the cockpit object.  I switched back to ATTR_cockpit and everything just worked.

Hi Tom,

good to hear you figured it out  

However, I see no reason why the generic text should not work with ATTR_cockpit_region. I just using some generic text instruments which work flawlessly in a 3d pit with 1 region for the entire panel and a dedicated 3d panel setup in planemaker.

Cheers

Jan

[tkyler]

Of course the "qualifiers" keep going Jan...so the proper answer is:    " generic text with ATTR_cockpit_region ...AND...the lighting mode of the generic text set to "mechanical", which is the default setting".

Because almost every generic text in existence represents some type of LED output...it's 99.9% (if not 100%) of the time going to have it's lighting set to glass, in which case, folks would see no problem....but leave it to me to have it set to mechanical and bang my head against the wall.  Either / or, Ben confirmed the bug and it'll be fixed for the next version...not that anybody except a bozo like me would ever deal with it.

I'll presume your generic text instruments are set to lighting mode "glass".  Set them to mechanical and see if you have the same problem.

[twinpropflyer]

Ah..., yeah, got it . But it's not a bug, it's X-Plane  ;D