hatman
Well-known Member
- Joined
- Apr 8, 2005
- Messages
- 2,664
I have been developing/evolving a pretty complex xlsm for the last 5 years or so. The whole manufacturing organization uses it on the a daily basis, across multiple business units, thousands of users in-all. Well, while working my latest update, I managed to break it in a way that I cannot fix or understand.
The update involves the code that is discussed in this thread. Turns out when I saved the file following my latest code developement, one of the very hidden worksheets that contains several dozen graphic objects loses the pointer to the images within the xlsm zip archive. The big complication is that these images are the source for configurable icons in teh ribbon, so the GetImage callback for the ribbon involves code that gets the icon name from an Access database, then grabs the corresponding object from the worksheet and massages it into a format that the GetImage function can return to the ribbon. This means the ribbon comes up all wrong (no icons). When I try to save this already corrupted file, Excel tells me there is unreadable content (the images in the Media folder of teh zip archive), and wants to repair the file by removing content... which also removes the CustomUI folder from the zip archive.
After a bunch of time consuming trial and error investigation with a backed-up copy preceding my changes, I narrowed it down to the CreateItem keyword in the line "Set oMsg = olApp.CreateItem(olMailItem)". Turned out that in the previous version of teh file, I can simply add the text CreateItem (preceded by a single quote, to comment it out) to any existing code module, save it, and when I re-open it, the images in teh worksheet are no longer linked up (they show up as boxes with red X's in them). Shows me that there is latent corruption that hasn't expressed itself in teh version.
Next I experimented backwards with various previous versions to see how far back I needed to go to re-build my file... turns out that any of the versions from the last year will get corrupted when I add the Outlook Code referenced in teh other thread, though the keyword seems to be something othe rthan CreateItem (I can;t be bothered to figure out which word sets off which version).
I went so far as to view the zip archive of a stable file and a corrupted file, to see what I could find in the relationships files... turns out that through visual inspection, I can't find a difference in any of the constituent files. But get this: when I copy the icons worksheet from a corrupted version to a new workbook, save it and look at the zip archive, the media folder is absent, and the xl\drawings\_rels\drawing1.xml.rels file contains NO pointers to the images in the media folder. This is interesting, because in teh corrupted file, the media folder is full of all of the proper images, and the drawing1.xml.rels file points to all of them properly.
Just for kicks, I tried copying an uncorrupted version of the icon worksheet to a new file, and saved it, then added the "trigger" code and re-saved... I could not find a configuration or sequence that corrupted the new file containing the icon worksheet.
Lastly, I tried copying the uncorrupted icon worksheet into the corrupted file, change all of teh code references to the new worksheet, and the ribbon builds itself propely on an invalidate, grabbing teh images from teh new worksheet as expected. Deleting the old corrupt icon sheet does not, however, allow me to save the book... at all. I am surmising that not all of teh content related to teh worksheet is being purged (because it seems to be orphaned in some fashion), so when Excel tries to save it, there are files it doesn't know what to with when building the zip archive...
Rebuilding from scratch is about as painful as rebuilding from a version that is more than a few months old... and it involves around 15 userforms, 20 standard modules, and 35 class modules... I could ALMOST have done it by now in the time I have spent trying to understand teh problem.
Of course, when I rebuild from scratch, I always get lazy and export the userform objects... meaning that the problem could re-assert itself.
Before I get ip-deep in re-build, does anyone have any words of wisdom? I'm game....
The update involves the code that is discussed in this thread. Turns out when I saved the file following my latest code developement, one of the very hidden worksheets that contains several dozen graphic objects loses the pointer to the images within the xlsm zip archive. The big complication is that these images are the source for configurable icons in teh ribbon, so the GetImage callback for the ribbon involves code that gets the icon name from an Access database, then grabs the corresponding object from the worksheet and massages it into a format that the GetImage function can return to the ribbon. This means the ribbon comes up all wrong (no icons). When I try to save this already corrupted file, Excel tells me there is unreadable content (the images in the Media folder of teh zip archive), and wants to repair the file by removing content... which also removes the CustomUI folder from the zip archive.
After a bunch of time consuming trial and error investigation with a backed-up copy preceding my changes, I narrowed it down to the CreateItem keyword in the line "Set oMsg = olApp.CreateItem(olMailItem)". Turned out that in the previous version of teh file, I can simply add the text CreateItem (preceded by a single quote, to comment it out) to any existing code module, save it, and when I re-open it, the images in teh worksheet are no longer linked up (they show up as boxes with red X's in them). Shows me that there is latent corruption that hasn't expressed itself in teh version.
Next I experimented backwards with various previous versions to see how far back I needed to go to re-build my file... turns out that any of the versions from the last year will get corrupted when I add the Outlook Code referenced in teh other thread, though the keyword seems to be something othe rthan CreateItem (I can;t be bothered to figure out which word sets off which version).
I went so far as to view the zip archive of a stable file and a corrupted file, to see what I could find in the relationships files... turns out that through visual inspection, I can't find a difference in any of the constituent files. But get this: when I copy the icons worksheet from a corrupted version to a new workbook, save it and look at the zip archive, the media folder is absent, and the xl\drawings\_rels\drawing1.xml.rels file contains NO pointers to the images in the media folder. This is interesting, because in teh corrupted file, the media folder is full of all of the proper images, and the drawing1.xml.rels file points to all of them properly.
Just for kicks, I tried copying an uncorrupted version of the icon worksheet to a new file, and saved it, then added the "trigger" code and re-saved... I could not find a configuration or sequence that corrupted the new file containing the icon worksheet.
Lastly, I tried copying the uncorrupted icon worksheet into the corrupted file, change all of teh code references to the new worksheet, and the ribbon builds itself propely on an invalidate, grabbing teh images from teh new worksheet as expected. Deleting the old corrupt icon sheet does not, however, allow me to save the book... at all. I am surmising that not all of teh content related to teh worksheet is being purged (because it seems to be orphaned in some fashion), so when Excel tries to save it, there are files it doesn't know what to with when building the zip archive...
Rebuilding from scratch is about as painful as rebuilding from a version that is more than a few months old... and it involves around 15 userforms, 20 standard modules, and 35 class modules... I could ALMOST have done it by now in the time I have spent trying to understand teh problem.
Of course, when I rebuild from scratch, I always get lazy and export the userform objects... meaning that the problem could re-assert itself.
Before I get ip-deep in re-build, does anyone have any words of wisdom? I'm game....