LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Table Control function generating General Protection Fault

The table control function "DeleteTableColumns" is generating a GPF. I've stripped down my program to nothing (included as file attachments), to see exactly what is going on. To summarize:
* Only happens with large size tables (50x50 works fine - but 130x127 doesn't).
* In this sample program the table is resized when the operator
1). Selects the command button on the screen to resize. Or,
2). Right clicks on a cell and selects the resize menu option. Or,
3). Presses the enter key when a cell is selected.

Each of these methods will redraw the table by first Deleting all rows and columns, then inserting rows and columns. The program will generate a GPF on the DeleteTableColumns ca
ll *ONLY* if the operator used method 2 or 3 above to resize the table. And *ONLY* if a cell in row number 1 has been selected. It sounds a lot more complicated than it is. Is there a limit on how large the table can be? Surely 130 x 127 is not too large. The attached code is very simple - please someone check it out and tell me how to fix this.
Thanks!
Download All
0 Kudos
Message 1 of 6
(3,748 Views)
I have looked at the code for some time now, and am unable to find what is causing the fault. It looks as if you have a lot of experience in writing code, as this is some of the best that I have seen. I as well only get an error when the table has a large size. Also, when the table is of a large size, no GPF is reported if the active cell is not in the first row!? of the table. Again the errors I am getting are as you reported, in only the right click, and the "enter" keypress. I think the problem is somewhere in the deleting and refreshing of the table, not in the size. I will continue to look at it, and update this post when I find an acceptable answer.
0 Kudos
Message 2 of 6
(3,748 Views)
Well... you've found a bug in the table control. We've detected the source of the problem and fixed it. The fix will be in the next release. In the meanwhile, here's a workaround:

The code containing the bug will not execute if the table is hidden or inactive at the time the columns (or rows) are deleted. Temporarily hiding the table, for example, would be enough for the problem to not occur, and as long as events aren't processed while the table is hidden, no flashing should take place.

Let me know if you have other questions

Luis Gomes
NI
0 Kudos
Message 3 of 6
(3,748 Views)
Thanks for your help. I'll try hiding the table control.
0 Kudos
Message 4 of 6
(3,748 Views)
Was this fix implemented? I'm getting the same problem with CVI 6.0.0 (105) running on NT4 SP6. Hiding the table does seem to work, but I'd rather not have to.

On the subject of GPFs, are there any known problems with the PrintCtrl function. I'm using it to print a graph control to a Laserjet 4000N on our network and I'm getting frequent GPFs before the print starts. (same system as above)

Stephen Lomas
0 Kudos
Message 5 of 6
(3,748 Views)
An update to my previous post...

I tried the table workaround with the PrintCtrl function (i.e. hiding the graph temporarily) and it seems to cure the problem!!!

Perhaps PrintCtrl is calling the same code as the table control, or code with a similar bug.

Hope this helps,

Stephen Lomas
0 Kudos
Message 6 of 6
(3,748 Views)