In our program we used to have this very advanced feature allowing users to add icons or logos to 2 or 3 kinds of objects. It worked, more or less. In fact, for one kind of the objects it didn't work at all, since the gooey had just a text block, rotated (who knows why) by 45 degrees, saying "Logo" - the original developers perhaps wanted to add it later, but - most likely because of haste - somehow they left it like that.
Ten years passed [sound of crickets...], and I found this text block and laughed and thought bad things about these guys and girls. And not thinking too much, since thinking in the baroque world of WPF gives me headache, I managed somehow to:
(a) add the apropriate table to the database, and
(b) the corresponding "view model" or "field info" of one class, and then
(c) copy and adapt the window for adding icons.
It seemed to work after some struggle, whining, cursing and other Muttley-like grumpy sounds (without the laugher, sadly). So I happily removed that lousy "logo" text block, made a button and even made it refresh its content when some data grid selection changed, etc.
One and a half year later [sound of crikets...], person temporarily responsible for the formidable task known as QA, said that adding or changing these icons doesn't work. What the fsck... Weeks after becoming hero of the day by removing the problem of Windows' "security" policy (the VirtualStore directory, security my foot...) the problem of "rotting code" struck again. It's so frustrating when someone says, "Well, perhaps you changed something, and that's why it's not working." I didn't change anything there, but it's just hard to tell them to go quickly and far away.
It seems that even upgrading to the newer version of .Net Framework is not responsible for this dirty trick (yes, we were using 4.0 client or so, up until August 2022, but the logo/icon issue is older than a month).
Anyway, I located the error - more or less, and discovered that some of the knuckleheads before used this beautiful method of handling errors: if(... == null) return;. And something (BitmapImage's StreamSource or SourceStream) magically started to be null, out of nothing, just because something else went out of scope or whatever the reason. (Yeah, reason on Windows OS.) Then I went through the dire hell of looking for "solution", and some good soul's clever post on OS provided the desired result. I don't understand it and I don't even want to try to learn it. Tons of stuff, weird objects, their life cycles, wisely named functions. Give me a break... It's better to practice some reflection-related stuff and events and threads and stuff.
Long story boring: if turning BitmapImage to byte[] fails with some closed stream exception, it seems you have to read the image to the memory stream again and convert that. Why you didn't have to do that before and when the change happened and what it was - I couldn't care less, at least now. And it's time to forget it and push forward. (Esp. in the spirit of some M. Judge's ex-employer, see https://www.youtube.com/watch?v=ckNKhfgHwh8)
No comments:
Post a Comment