Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/21/2011 in all areas

  1. I just checked and it's available in VIPM, now Great work, OpenG team!
    1 point
  2. You could use the following code to set all cells of mclb to the same format. This not a "clear formatting" method, but it works and it's efficient. Regards, Olivier FormatAllCells.vi
    1 point
  3. No way, say it's ain't so. In other news, the sky is still blue. Well on Earth anyways, most of the time... I'm still pumped about this topic. Granted I got to spend zero time on implementing something like this this year (still very disappointed about that), but 2012 will be different. Yeah, that's it, different. What can I say, there's still a bit of foolish youthful optimism in me.
    1 point
  4. QUOTE (Eugen Graf @ Jun 24 2008, 05:08 PM) You can create a flattened cluster string in C++ and then write a custom unflatten routine for your class that can parse the string and populate the fields of your class. But if you want to use the Unflatten From String primitive, then you'll have to format the data like a LabVIEW class gets flattened. What does an LVClass look like when we flatten it? The string has four parts: "NumLevels" The first 4 bytes represent a uInt32. This tells us how many levels of the hierarchy are recorded herein. SPECIAL CASE: If NumLevels is zero, absolutely nothing else follows. Zero indicates that this is an instance of LabVIEW Object, the ancestor of all classes which has no fields, no methods and inherits ex nihilo. "ClassName". The next several bytes represent the fully qualified name of the class. First there is a single byte that tells the length of the qualified name of the class. This is followed by a sequence of Pascal strings , each one representing one segment of the qualified name. The last Pascal string is a length byte of zero. This section of the flattened string includes enough zero pad bytes to increase the class name section to a multiple of 4 bytes. "VersionList". The next series of uInt16s that represent a list of version numbers. Each version number is 4 uInt16s, usually written in the format W.X.Y.Z, where W, X, Y and Z are each a uInt16. There are NumLevels of version numbers. The first version number is the version of ClassName class, followed by the version number for ClassName's parent, and so on to the version of the oldest ancestor (not including LabVIEW Object). SPECIAL CASE: If NumLevels == 1 and the version == 0.0.0.0, then this is the default data of the class. Skip section 4 -- no further data follows in this special case. If version is zero for any other value of NumLevels, the string is considered corrupt and the unflatten functions will return an error. "ClusterData" -- This is a series of flattened clusters, one for each level of the hierarchy. The first cluster is the oldest ancestor class. Pay attention: The version numbers start at the descendant class and go up the hierarchy. The cluster data starts at the oldest ancestor and goes down the hierarchy. Each block of data starts with 4 bytes interpreted as an int32. This int32 represents the number of bytes in the data that follows. If this number is zero, then we use the default default data for this level of the hierarchy. If this number is non-zero then this is the standard flat data representation for the cluster at this level of the inheritance hierarchy. After each cluster there are enough pad bytes to get the length of the string back to a multiple of four. Here, for example, is a flattened class object (I put the string into slash notation to make this "easier" to parse): 00021210Bacteria.lvclass000506070b0100000t0000000f0004abcd0000 The first 4 bytes are NumLevels. NumLevels in this case is 2. So we have a class that has one ancestor between it and LabVIEW Object.Next is the PStr that is the name of the class: Bacteria.lvclass. After that are 2 NULL pad bytes to get the length back to a multiple of four.Next is the first version number: 5.6.7.8. That's the version number for Bacteria.lvclass.Next is the second version number: 1.0.0.11. That's the version number for Bacteria's parent class. We'd have to have Bacteria in memory to ask it "Hey, who was your parent class back when you were version 5.6.7.8?"Next come the data blocks.The first data block has data size 0. That means that we'll just assume that the parent cluster was the default default value.The second data block has data size 15. So the next 15 bytes are a flattened cluster of the cluster of Bacteria when it was version 5.6.7.8. Remember that the Bacteria.lvclass currently in memory might be a much later version of the class -- LabVIEW will automatically handle the conversion for you (which you can read all about here). In this case, it looks like those 15 bytes of data contain a string ("abcd") and a couple other cluster elements. Just write code in C++ to generate this string and you can have LV unflatten it. Contrariwise, you can have LV flatten the string and you write the C++ function to parse it. IMPORTANT NOTE: The flattened form of LV data is readable on *any* endian platform. We always flatten int32s, uInt32s and other data types into little endian order. If you are on a big endian machine, make sure that your custom write function takes care of reversing the bytes.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.