Re : [LV2013SP1] Strange cluster ordering from a database

[Kochise]

Hello,

I'm not an expert in LabView since I come from the

embedded world (C/C++) yet I found something

quite strange when reading from a database.

Here's attached some screen captures of the

database content and structure, then the LabView

diagram with the probe output (yeah, had to stretch

it wide because there is no word wrap option).

Finally there is a little Excel snapshot of the result.

The database reading is performed with a certain

column ordering, the "casting" cluster do mirror

the same order and datatype, yet 'Variant to Data'

scramble things.

And even though I do use dis/assemble cluster

by name to avoid confusion, the resulting cluster

at probe 20 is right. Go figure...

Could someone help and explain what's going

on under the hood ? At least with C/C++ you have

a little grasp on how memory is ordered, but

LabView really bogs me...

David

[Kochise]

And the remaining two snapshots...

David

PS : update the LabView's UI to something more up to date, avoid the windows-on-top, avoid messing the task bar with dozens of buttons, share to place and use your own tab bar, do something for the probe and breakpoint windows, etc...

[altenbach]

I am not really sure what you are asking, but the ordering of elements in a cluster is defined by the cluster order (changeable by "right-click...reorder controls in cluster"). It is not defined by the  cosmetic arrangements of elements in the cluster container.

[Kochise]

I do have ordered the clusters, not just moved things inside. BTW the clusters automaticaly display the right order when displayed vertically.

The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"

Simple question calls for simple answer.

David

[nyc_(is_out_of_here)]

---

@Kochise wrote:

The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"

Simple question calls for simple answer.

---

And how are we suppose to know????

You have not posted any of your code as in a VI. A PNG file doesn't count.

Frankly I don't give a hoot what your Access database looks like.

[altenbach]

---

@Kochise wrote:

The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"

---

Until just now, you haven't mentioned probe 19 and that it is "wrong" (whatever that means), just that probe 20 is right.

This is impossible to troubleshoot from pictures alone, but did you notice that the wire on probe 20 causes a coercion dot at the next function, indicating a type mismatch?

[aputman]

Looks like to me that probe 16 is a variant array.  You pass this into the variant conversion VI with a cluster as the new type.  Maybe this is causing the reordering.  or the ordering of cluster controls in this constant is wrong.

[Kochise]

Ok, I've found the bug in LabView 2013 SP1.

The 'Pdt_D' cluster had suffered several modifications and

reordering, but 'Variant to Data' doesn't follow the cluster

virtual ordering but the cluster's memory ordering.

In short, if you create a cluster one way, delete members,

add some more, adapted and reorder, the 'Variant to Data'

VI will take the members' order in which they were added

to the cluster, regardless of the hypathetic ordering you

might have specified afterward.

Probably a problem of chained list, one listing the members

as they are added, one listing the members in the specified

ordering, perhaps the bug comes from pointing the wrong

list.

If you delete the 'Pdt_D' cluster, create a brand new cluster

constant, then add one by one the members of the right

datatype, 'Variant to Data' works like expected and dispatch

the variant's data into the belonging members.

There's is no use providing you with a snapshot because

it will all look the same that I have already provided you with,

just that the cluster has been recreated from scratch and

not been reordered. That's a rather annoying spurious bug

you'd better be strong hearthed to deal with.

And for the VI, it's a rather complex proprietary application

I cannot disclose, but I'll create an example VI further in

time so that you can witness it by yourself.

Sorry for not being specific enough with my problem.

David

[altenbach]

If you think you found a real bug, please report it to NI so it can be fixed.

[Kochise]

Will further investigate and create a sample

demonstration beforehand, then if confirmed,

a but report will be issued.

Thanks for your attention.

David