LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

displaying ssize_t value in table cell

Solved!
Go to solution

Hello,

 

I want to display a number of type ssize_t in a numeric table cell. In the UI editor, the cell has been set to intptr_t.

 

Running the code in debug64 works fine, in debug I receive the error message:

 

FATAL RUN-TIME ERROR:   Invalid argument type: found 'int', expected '__int64'.

 

I have to add: in the UI editor I have created the table with one row only, I add more rows programmatically using InsertTableRows (but the cell types should be inherited). The error only shows up when filling the cell of the last row.

 

Ideas?

 

 

0 Kudos
Message 1 of 13
(5,656 Views)

OK, let me add some more details:

 

1) I have designed a table in the UI editor which consists of 1 row and 11 columns

2) the number of rows gets adjusted at run time:

2a) by setting the number of visible rows (e.g. to 3)

2b) by inserting table rows (e.g. to 3-1: one row already exists)

3) Finally I populate the table using SetTableCellAttribute (,,,ATTR_CTRL_VAL, value );

 

if I run this code in debug 64, everything is fine, while in debug 32 the last call to TableCellAttribute (,,,ATTR_CTRL_VAL, value ); gives a fatal run time error.

 

If I modify 2b) by generating a table that has one more row, (inserting one more row), the code works fine as well: the last row is not used.

 

So obviously something goes wrong when a new table row is inserted AND the cell type is intptr_t AND CVI is in debug32 mode.

 

Since intptr_t is new I suspect it's a bug Smiley Wink

 

 

0 Kudos
Message 2 of 13
(5,634 Views)

Hi Wolfgang,

 

do you have a little example project to reproduce the issue?

You use LabWindows/CVI 2013 on Windows 7 64-bits?

 

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 3 of 13
(5,628 Views)

Hi Suse,

 

I am using CVI2013SP1 on Windows 7 64 bit.

 

Concerning the example... yes, in principle I could provide one but I was hoping that my description is detailed enough for NI to reproduce it. Smiley Wink

0 Kudos
Message 4 of 13
(5,625 Views)

Hi Wolfgang,

 

to have all the properties like you have it would be great to get your example.

 

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 5 of 13
(5,618 Views)

Hi Suse,

 

I have prepared a demo, I hope it will work for you, too.

 

It behaves as described above: ok for debug64, but with a crash in debug32

 


Concerning the work-sharing... For CVI2013 alone I have reported almost 20 bugs, lets assume each one 'costs' me half a day... I am not getting paid for it and I did not get any discount on CVI...

0 Kudos
Message 6 of 13
(5,599 Views)

Hi Wolfgang,

 

The problem is this:

 

  1. The table in the UI editor already has one row. The data type of its cell under column 5 is "int64".
  2. Column 5 of the table is configured such that any new cells created under it will have the data type "intptr_t"
  3. Programmatically, you add two additional rows to the table. You add these two as the first two rows of the table. The previous single row becomes the new third row.
  4. You set the value of the cell in row 2 to a ssize_t variable. This succeeds because the cell in row 2 is also ssize_t / intptr_t.
  5. You set the value of the cell in row 3 to a ssize_t variable. This fails because the cell in row 3 is set to int64, and in a 32-bit program, these are different data types.

You can fix everything by simply replacing the third argument passed to InsertTableRows with -1.

 

Luis

 

Message 7 of 13
(5,578 Views)

Hi Luis,

 

thanks a lot for your analysis. I would almost agree... but

 

I do not understand you first statement... Where do you see that

The data type of its cell under column 5 is "int64".

 

And if so, how do I change this? (seems I am not so familiar with tables...)

 

cell.png

0 Kudos
Message 8 of 13
(5,556 Views)

I see it here:

 

tablebug.png

 

It's okay for you to have intptr_t for the column. That, in conjunction with the fact that the table is in column mode, should ensure that all future cells under that column inherit intptr_t as their data type. However, the (5,1) cell that you already have still has int64. This must be because you created that row before you changed the data type for future cells.

 

Luis

0 Kudos
Message 9 of 13
(5,539 Views)

@LuisG wrote:

 

However, the (5,1) cell that you already have still has int64. This must be because you created that row before you changed the data type for future cells.


Hi Luis,

 

thanks - you are correct (of course Smiley Happy)

 

But...

 

If I change the default values there is a popup that tells me exactly this.... But it also seems to offer applying those changes to the existing cell. However it appears that clicking Yes has no effect...

 

 

cell.png

 

I agree that it is my fault, I misunderstood this statement - it does not promise to actually apply the value, it only asks if I would like to... Smiley Wink

0 Kudos
Message 10 of 13
(5,533 Views)