VB6 File not found: 'C:\Users\???\AppData\Local\Temp\VBB685.tmp'
-
I'm not one to hate on VB6, but today's gonna be an exception. Also I want this message to be on the internet so the next poor swine who gets this message might be lucky enough to see this post. I recently added some functionality to an OCX in our legacy VB6 system. The OCX compiled without errors, but any program that used it could no longer load it. When I tried to reference it in a new project, I got the error "File not found: 'C:\Users\???\AppData\Local\Temp\VBB685.tmp'". About a week of tearing my hair out followed. I'd just upgraded to windows 10, I'm still not sure if that's relevant. The thing is, I added a property. Removing it fixed the bug. Adding ANY property broke it again. Eventually I broke compatibility, made two functions which were Public but could/should have been Private .. um, Private, and added my property again. Now it's all good. I can only assume there's some sort of really small limit on the number of exposed properties of a VB6 OCX. If this is/was common knowledge, well then what the hell google :p
-
I'm not one to hate on VB6, but today's gonna be an exception. Also I want this message to be on the internet so the next poor swine who gets this message might be lucky enough to see this post. I recently added some functionality to an OCX in our legacy VB6 system. The OCX compiled without errors, but any program that used it could no longer load it. When I tried to reference it in a new project, I got the error "File not found: 'C:\Users\???\AppData\Local\Temp\VBB685.tmp'". About a week of tearing my hair out followed. I'd just upgraded to windows 10, I'm still not sure if that's relevant. The thing is, I added a property. Removing it fixed the bug. Adding ANY property broke it again. Eventually I broke compatibility, made two functions which were Public but could/should have been Private .. um, Private, and added my property again. Now it's all good. I can only assume there's some sort of really small limit on the number of exposed properties of a VB6 OCX. If this is/was common knowledge, well then what the hell google :p
There is no limit on the number of properties. I would guess, however, that it had something to do with your compatibility setting in the project. I'm not going to try and guess what because it's been about 15 years since I last touched VB6. Yay me!
A guide to posting questions on CodeProject
Click this: Asking questions is a skill. Seriously, do it.
Dave Kreskowiak -
I'm not one to hate on VB6, but today's gonna be an exception. Also I want this message to be on the internet so the next poor swine who gets this message might be lucky enough to see this post. I recently added some functionality to an OCX in our legacy VB6 system. The OCX compiled without errors, but any program that used it could no longer load it. When I tried to reference it in a new project, I got the error "File not found: 'C:\Users\???\AppData\Local\Temp\VBB685.tmp'". About a week of tearing my hair out followed. I'd just upgraded to windows 10, I'm still not sure if that's relevant. The thing is, I added a property. Removing it fixed the bug. Adding ANY property broke it again. Eventually I broke compatibility, made two functions which were Public but could/should have been Private .. um, Private, and added my property again. Now it's all good. I can only assume there's some sort of really small limit on the number of exposed properties of a VB6 OCX. If this is/was common knowledge, well then what the hell google :p
By adding a property you broke the "contract" between the OCX and it's clients. Forcing the break compatibility is the only way (AFAIK) to get around it without supplying another interface. You will probably also have to rebuild any project that uses the OCX