Jump to content

byte array dataref question


tkyler
 Share

Recommended Posts

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

post-4-131369575976_thumb.jpg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

post-890-131369575998_thumb.jpg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...