Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Reporttable crashing OI
I have a window that has four reporttables on it.
One of them is giving me grief so I'm looking for any and all thoughts/suggestions no matter how absurd.
I initialise the table the same as I do all the others. In fact, it is identical to one of the others on the window.
The only difference between the two is the source of the data.
They both consist of just four visible columns; a date, a time, a hyperlink for deleting the row and another hyperlink to view the corresponding record. There is also a hidden column.
I can load the list properties of both tables without issue.
The issue arises when I try to reset the list property of just the one reporttable. It doesn't matter what the content of the data is because even just setting it to null crashes OI.
Set_Property(ole_sql_errors$, 'OLE.List', null$)
Make the same call to the other table and it works as expected.
I renamed the offending reporttable. I removed it and saved the window, then readded it (actually copied and pasted the working control) and saved the window again. Still crashes.
If I change the progid to an edittable; it works. Not very elegantly mind you because I didn't initialise the edittable in any way but it still displays the first column of data each time I set the list property.
Change it back to a reporttable and it crashes again.
Confusing me because as an edittable it works. An identical table on the same window can be set and reset numerous times without an issue.
Happy to resave it whilst blindfolded and standing on one leg if anyone thinks that might help.
Here's the table displaying data loaded on the create event.
Then after clicking the 'Refresh' button above the table, the set_property mentioned above executes and then this happens
One of them is giving me grief so I'm looking for any and all thoughts/suggestions no matter how absurd.
I initialise the table the same as I do all the others. In fact, it is identical to one of the others on the window.
The only difference between the two is the source of the data.
They both consist of just four visible columns; a date, a time, a hyperlink for deleting the row and another hyperlink to view the corresponding record. There is also a hidden column.
I can load the list properties of both tables without issue.
The issue arises when I try to reset the list property of just the one reporttable. It doesn't matter what the content of the data is because even just setting it to null crashes OI.
Set_Property(ole_sql_errors$, 'OLE.List', null$)
Make the same call to the other table and it works as expected.
I renamed the offending reporttable. I removed it and saved the window, then readded it (actually copied and pasted the working control) and saved the window again. Still crashes.
If I change the progid to an edittable; it works. Not very elegantly mind you because I didn't initialise the edittable in any way but it still displays the first column of data each time I set the list property.
Change it back to a reporttable and it crashes again.
Confusing me because as an edittable it works. An identical table on the same window can be set and reset numerous times without an issue.
Happy to resave it whilst blindfolded and standing on one leg if anyone thinks that might help.
Here's the table displaying data loaded on the create event.
Then after clicking the 'Refresh' button above the table, the set_property mentioned above executes and then this happens
Comments
By "other" table you are referring to the ReportTable with the identical configuration? As a way of troubleshooting the situation did you modify your code so that the identical ReportTables are swapped? I don't mean just swap their names in the form itself but in the code. What I am trying to confirm is that the actual ReportTable and name is irrelevant and it is all related to the data being populated and/or perhaps some code that is unique to this specific usage. This will also tell us if tab order is relevant.
Based on your description, I'm betting that the dataset is triggering some kind of error. If that is the case, I'm going to need that particular dataset in order to recreate the issue on my end and fix it. Would it be possible to create a stand-alone form with one report table that is setup and populated in exactly the same way? You would have to save off the dataset (i.e., OSWrite whatever you first pass to the OLE.List property) so I could load the exact same data on this end. I know it's asking a bit of time from you, but it's the best way to show that it can be repeated, at which point it would take me very little time I'm sure to fix it.
That was the kind of prompts I was really looking for. (I tried the standing on one leg thing and it didn't fix it).
Don,
Not sure whether I 100% followed what you meant but I did this.
Initialised both reporttables the same as I had before but set the list property for table 1 using the data for table 2 and vice versa. Subsequently setting each table to null still crashed on table 2.
Kevin,
I went about making a packaged example of just the one reporttable and refresh button.
I used a copy of the same commuter to make sure I was doing everything the same.
Didn't crash.
In the commuter however, I had commented out some "unrelated" code to keep it simple and to the point.
When I reinstated the commented code, the crash presented itself.
So I will step my way through the "unrelated" stuff to work out what else is interfering before I decide whether you need to work your magic. I'll let you know either way.
I can't give you the exact specifics but the general issue was this.
I have one routine to initalise all reporttables and I just pass in certain parameters as arrays. Eg an array of column headers, column widths, visibility settings etc. The setup routine takes the fm arrays and sticks all the right bits in all the right places. Straight forward.
Why did it screw up?
I was initialising the two like reporttables one after the other with essentially the same command.
The problem was the widths and visibility arrays were being passed in to the setup routine correctly as fm arrays, being changed into vm arrays within the setup routine and then being passed back in to the setup for the second table as vm arrays.
So having either a column width or a visibility flag as an mv array will cause a crash when setting the list property.
Don't know whether it was the width or the visibility because I didn't debug to that level.
Also strange that it didn't crash the first time I set the list property but just if I tried to reset it.
At least that's why it seemed like "unrelated" code. The cause was in the initialising of the table but the symptom presented itself at a later time for a different event.
In the end, rookie error on my part.
Always glad to see when the pilot catches his own error. Did you ever figure out what I was trying to recommend? Whether you understood me or not, I think you ended up following my suggestion to some degree.
The problem from my end was the widths variable, not the visibility variable.
By passing in the widths as a vm array, the subsequent putting all the pieces together created extra columns I didn't need nor did I know they were there.
Here's the two columnlist properties. The top one is the correct one. The two should be identical but the offending table was ending up with the columnlist down the bottom. I don't know why this would cause a crash when setting the list property a second time but maybe there's something in there that means something to you guys.
Don, to some degree was good enough for me. :-D