Kind of stumped - I have an application I've built (it's an old Visual FoxPro app) that won't pin to the Windows 7 task bar. Before you jump and say - FOXPRO is at fault - I have several other FoxPro apps running the same exact environment and they pin to the taskbar just fine. VFP 9 apps are EXEs with a runtime dependency but otherwise act like any other Windows exe.
I duplicated the behavior on another machine as well with a full installation package, but the app just will not pin.
I'm stumped and have no idea what could be the problem.
A couple of things i've tried that didn't work:
Remove the icon from the EXE in case
there's some Windows Icon convention
problems
Remove manifest and config files use
with app
Ran from shortcut - ran from EXE
directly
http://www.west-wind.com/weblog/posts/32765.aspx
Here's the blog post your wrote about this shortly after you asked this question. I thought I'd post it in case others are having the same problem. Unfortunately there must be other reasons this can happen because I'm having issues with pinning notes.exe to the taskbar and looking around the net, others are too.
Related
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
I have a windows mobile project in VS2005. Initially I could not get any breakpoints to enable on windows mobile 6 device but they worked on PocketPC2003 Emulator. It's a new computer at work and after a while I realised I had no installed any SDK's beyond 2003. Having now installed SDK's for windows mobile 5.0 6.0 and 6.5.3 I now have SOME of my breakpoints active.
My solution consists of a main application under which there are a few screens and associated code. There are also a series of other classes each of which compiles to a separate DLL. It seems the issue I have is that any breakpoints in these separate classes
work perfectly now. However any breakpoints in the main application class give an error "The breakpoint will not currently be hit. No symbols have been loaded for this document." I've tried a number of things including deleting the bin\debug and obj folders to clear old debug information. The PBD files appear to be created ok for the exe files as well as the class DLL's but only the Dll's work correctly in debug.
Any ideas guys. I really have to get this working as it needs to work on a device not just an emulator. I have an external DLL I need to use as part of testing that is very specific to a brand and model range of hardware. I wont explain why here, just suffice it to say I really need to get this sorted.
I'm still learning VS2005 So please be specific with suggestions as I might not yet know where to locate certain functionality.
I should probably add it works fine in windows mobile 5.0 emulator but I don't have a windows mobile 5 device to test with
Thanks in anticipation.
Well I don't know exactly what I did but it is now working. I read an article on here about enabling the module tab in the debug menu and after doing that it worked however I had done a couple of other things prior to doing that and hadn't tested it so not sure which it was that fixed it.
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).
I have an old VB6 application that uses an ImageList control from COMCTL32.OCX ("Microsoft Windows Common Controls 5.0 (SP2)") to provide icons for TreeViews and ListViews.
The app won't even launch on Windows 7.0 64 bit. The minute it tries to load the form that has the ImageList on it, it crashes (well, actually, the app winks out, exiting without a trace).
Removing the ImageList from the form solves the problem.
Any ideas?
I resolved this problem by replacing all instances of COMCTL32.OCX, which came with VB5, with MSCOMCTL.OCX, which came with VB6.
Microsoft KB article 190952 has instructions for doing this. It was pretty much just a global-search-and-replace operation.
Report a bug to Microsoft. The VB6 runtime is still supported on 64-bit Windows 7. COMCTL32.ocx isn't installed with Windows 7, but it is explicitly listed as supported on Windows 7.
Your solution is OK.
But COMCTL32.OCX should work fine on Win64 anyway (Vista or 7).
Just a little advice:
If using MSCOMCTL.OCX you won't be able to apply to your listview or treeview the XP/Vista/7 style and your app might look alien. Manifest won't have any effect on MSCOMCTL.OCX controls.
A workaround would be to subclass the MSCOMCTL.OCX controls, and since they still contain a COMCTL32.DLL header you could manipulate how it paints.
(I would've posted as a comment, but I still can't)
It's possible you're running into an issue with Data Execution Protection (DEP). Test it out by disabling DEP:
bcdedit.exe /set {current} nx AlwaysOff
Reboot after entering the above in a command line. Remember to turn it back on as it's the equivalent of running Windows with your pants down.
Edit: The command above works on Vista. I haven't tried it on Windows 7.
A less drastic DEP tweak is go into the computers performance dialog (advanced tab of system properties) and add the apps exe to the list of exceptions on the DEP tab.
BTW, are you sure this doesn't belong on serverfault.com. :P
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.