License Delivery maintenance is expected to occur on Saturday, November 30, between 8 AM and 11 AM CET. This may cause a short 3-hours outage in which license-related tasks: license key upload, download, update, SSA validation, access to the license pool and Graphisoft ID authentication may not function properly. We apologize for any inconvenience.
Archicad C++ API
About Archicad add-on development using the C++ API.
SOLVED!

Dynamic size of UserData

Lk__
Participant

Hello,

 

I want to attach (and than read) some user data to attributes I'm creating in my add-on.

The thing is the data is actually an array of strings of various lengths and sizes. 

 

Technically, I know the size of the entire data buffer when creating the handle for saving, but what about reading?

I assume that Archicad knows how many bytes it allocated for the handle when retrieving data, but how do I get that?

 

Should I attach this information in the data itself? Or is there another, more 'proper' way of dealing with this?

1 ACCEPTED SOLUTION

Accepted Solutions
Solution

Hi TK!

 

You can get the size of the entire data buffer when reading with BMGetHandleSize.

 

Assuming you are storing a list of strings, I think it would be best to read and write the single entries delimited with a null character "\0". When you read the data, you'd iterate through the characters until you hit the \0 character and that would mark the end of the current string entry.


An alternative would be to work on a bit higher level and use GS::IChannel/GS::OChannel. You can see an example of their use in AddOnObject_Manager example project. I think one could adapt that approach to be used for element user data.

 

Hope that helps! Let me know if in case you need more information on this.

Bernd

View solution in original post

2 REPLIES 2
Solution

Hi TK!

 

You can get the size of the entire data buffer when reading with BMGetHandleSize.

 

Assuming you are storing a list of strings, I think it would be best to read and write the single entries delimited with a null character "\0". When you read the data, you'd iterate through the characters until you hit the \0 character and that would mark the end of the current string entry.


An alternative would be to work on a bit higher level and use GS::IChannel/GS::OChannel. You can see an example of their use in AddOnObject_Manager example project. I think one could adapt that approach to be used for element user data.

 

Hope that helps! Let me know if in case you need more information on this.

Bernd

Hi Bernd, 

 

This looks exactly what I was looking for.

 

Thanks!

Didn't find the answer?

Check other topics in this Forum

Back to Forum

Read the latest accepted solutions!

Accepted Solutions

Start a new conversation!