Thanks Rkaye for reviewing this. Again, I think that this is a great routine.
The issue we are having appears to be related with saving off and restoring the data sessions. I note that if I comment out the code in the SetClassDataSession and SetDefaultDataSession procedures in the class that I do then have access to all the control source settings in the passed grid object. However, if I comment out the code in these procedures, I then get messages asking if I would like to overwrite the working XML files that are setup in the WriteSupportXMLS procedure (such as CORE.XML). There appears to be some issue with saving off and then resetting the default data sessions.
PS. Like you, we are placing the class directly on the form itself and then calling if from a button on the form.
PPS. It would also be nice if there were some procedure type call to actually cause the XLSX file that was created, be it from the grid or the table, to be activated and displayed to the screen. At present (unless I am missing something), it creates the XLSX field but doesn't actually access it.
BTW. The reason we are using the grid to extract the data from, rather than just a table, is that we have developed our grid processing so that the end users can dynamically amend the grid layouts, (the header caption, the individual fields, setup new fields etc) and as we want the XLSX workbook to reflect the details of the grid as displayed on the screen rather than the underlying cursor, we need to export the details of the grid.
↧
