Microsoft has promised that VB6 code will continue to work on Windows 7, but has anyone noticed any gotchas specific to running VB6 code in the Windows 7 RC?
And for that matter, any issues with COM objects and ActiveX controls outside of VB6? I remember Microsoft saying that they'll ensure THEIR controls continue to work and end it at that; so I'm wondering what sort of under-the-hood change this entails...
We have a oodles of legacy controls which we need to migrate out--VB6 and C++--but it takes time to make it happen.
Thanks.
I've noticed one, but it's minor and probably not what you are looking for.
If you change the DPI to something other than 96, the checkbox control looks really odd, like someone cut it and it's showing you its guts. The same applies to the checkbox on the ListBox/ListView.
I have not encountered anything in terms of VB6 issues that is new since Vista.
Of course if your programs try to parasitize users' email profiles via MAPI, CDO, or something be aware that Win7 has no Outlook Express or Windows Mail at all.
DPI issues exist in Both Vista and Win7, and the cure is the same: you need to declare DPI awareness via an application manifest (and of course code for varying DPI when sizing and placing controls, fonts, etc.).
Related
There are no start menu icons showing up for my programs. This is a standard vs2010 setup project for a winforms project. I have set the icon for each start menu shortcut in the setup project's file system window, each executable has it's icon manifest set. The icons appear in windows explorer. I have recreated the setup project from scratch, didn't help. This used to work. Nothing I have tried today has fixed this it doesn't make sense. Any ideas appreciated.
Microsoft Visual Studio 2010
Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework
Version 4.0.30319 SP1Rel
I've experienced this once quite some time ago, but frankly don't recall the exact cause right away - two things come to mind:
Icons can come in a wide variety of both size and color depth, so maybe you have chosen a combination of formats within the ICO file which doesn't cover the required formats for the particular version and/or configuration (color/dpi) of Windows you are using currently? Here are some resources:
The Icons section within the Windows User Experience Interaction Guidelines, specifically Color and saturation and Size requirements - please be aware of section For high dpi in particular.
Creating Windows XP Icons, which is definitely outdated, but still provides some useful insights regarding the respective Windows (Explorer) defaults, see e.g. Icon Design Overview.
Update - the following doesn't seem to apply here as per your comment: Another association is triggered by your statement each executable has it's icon manifest set: There could be an issue with 32 vs. 64 bit handling here, insofar Windows might pull all sorts of magic regarding respective executable treatment, e.g. regarding a 32 bit executable o a 64 bit host etc.
I'll try to dig further and recall my specific experience, but maybe this can provide some ideas for further exploration on your side already.
Good luck!
We have a legacy VB6 app, which is critical to our business. We're working on re-writing it in .NET, but that's going to take a long time.
Over the last few years, this old VB6 app has had problems with third party controls that we purchased about 10 years ago, when we wrote the VB6 app. These problems are getting progressively worse. For example, the application will suddenly crash. When it does I'll check the user's event log to see what happened, and almost all cases one of the third party controls failed, and took the application down with it. Sometimes this causes the user to lose data.
We've done the best we can to mitigate this and that's helped tremendously, but haven't been able to prevent all cases of these failures. A few years ago, when this problem first started to show itself, I did some investigation into why these crashes were occurring and I remember some people saying that some of these problems were due to the service pack we had our application at. Our VB6 app is currently at service pack 5. I learned that Microsoft had come out with service pack 6, for VB6, and asked about that, back then, and people advised me to not upgrade to SP6 for VB6 due to incompatibility issues with our third party controls, so we've left things alone.
However, now these crashes are occurring more frequently. It's occurred to us that perhaps the issue is some recent updates to Windows may have already moved VB6 to SP6. Or, perhaps the advice I was given years ago about leaving our application at SP5 for VB6 was wrong. In any case, we need to find out if we can move our application to SP6 for VB6, and thereby hopefully reduce, if not eliminate, the number of fatal crashes these old third party controls are giving us.
Here's the list of third party controls that our application is currently using. Does anyone know if these controls will work with VB6 SP6?
Crystal ActiveX Report Viewer Library 11.5
Crystal Reports ActiveX Designer Design and Runtime Library 11.5
Crystal Reports ActiveX Designer Run Time Library 11.5
WSpell Spelling Checker Control version 1.0
Sheridan Data Widgets 3.0 A (in particular their Data
Grid, Data Combo and Data DropDown controls. It is these controls
which are at the root of all of our app's fatal crashes.)
I've used WSpell with VB6 SP6. Crystal was always pretty tightly in bed with Microsoft so I would expect that those work. Sheridan, well, I can't help you there.
That said... why ask? Just test it. You can always roll back if it doesn't work, right?
I can't give any advice about the Sheridan controls but we are using Crystal ActiveX Report Viewer and Runtime Library 10.0 with our VB6 app (using SP6) and this has no crashing issues.
We have multiple VB6 apps using Sheridan Data Widgets 3.1, mainly the grid but the dropdown a bit these days too. Everything ran fine on Vista and 7 but once a few people upgraded to 10 (we ignored/avoided 8) problems emerged quickly.
Loading the grid started making the app crash, but it was strange. I could call the load function (it populated the grid) when initially displaying information, and it was fine. Other functions would change the data and reload the grid, and most worked except for one. Nothing special or different about it, but the grid took a special dislike to it. What was annoying was if I threw in a MsgBox every time before a line was added to the grid (we use AddItem mode) the silly thing didn't crash.
Had a similar problem once with the grids, found I had to divert focus to a new form that appears for less than a second. Might be something to do with how the grid draws? Or judging by the function that causes it to crash when no others do, perhaps certain sequences of events cause the crashes.
Looking at the event log on Win10 it's telling me the faulting module name is USER32.dll, exception code alternates between 0xc0000005 and 0xc000041d.
Where can I find the orginal vb6 ( or windows ) icon? (.ico files)
I need, error, warning, question, and information icons which come up on the messagebox.
Thanks a lot.
As the icons can differ for each OS version, you can get the icons from Windows using LoadIcon() passing one of the standard icon IDs.
See http://msdn.microsoft.com/en-us/library/ms648072.aspx for details.
If you want them as .ico files, you can extract them (on your development machine) from user32.dll using a resource editor.
(Updated with corrected info from Cody Gray)
The standard Windows message box icons have changed many times across the various versions of Windows. They're included with a couple of the system DLL files, but you shouldn't try and extract them dynamically yourself. As I mentioned in a comment to another answer, the ID numbers are undocumented for a reason: namely because it's possible for them to change in future versions of Windows or even in future Windows updates. There's absolutely no reason to go through the effort trying to extract them, either. Windows will already retrieve them for you, if you ask nicely.
The nice way of asking is to use the LoadIcon function, and specify the IDI identifier of the icon you want. Windows will return an HICON value, or a handle to an icon resource.
Since you mention that you're using VB.NET, you can also use the SystemIcons class, which has static properties to return any of the common icons. This is a .NET wrapper that saves you from having to P/Invoke the LoadIcon function from the Windows API yourself.
Better yet, if you just want to display a message box containing one of the icons, all you have to do is call the MessageBox API function. Tell Windows the MB_ICON value that you want, and you're off. As before, this has already been wrapped for you by the .NET Framework in the identically-named MessageBox class.
The benefit of both of these functions is that they'll always return the correct icons regardless of the current version of Windows. A comment made attempting to clarify the question seems to suggest that you want to use the old icons on a current version of Windows. But of course, you do not want to do this. The icons have been updated throughout the Windows shell for a good reason, and your application should take advantage of them. The new icons are more clear and fit in better with the overall system theme. Additionally, if your app still uses the old icons, it will be confusing to users and look very out of place. It's always best to follow standard platform conventions, rather than trying to do "something else", even if you think your "something else" is "better" for whatever reason than the platform default. Your users will not agree, and your application will reflect your shoddy craftsmanship.
Since people who ask this type of question inevitably disagree with me and insist that they must do it anyway, and that it is a "requirement" (whatever that means), I'll point out that the old icons are not available in the newer versions of Windows. The icons have been completely replaced throughout the system for a reason. It's also strictly forbidden by the licensing agreements to extract icons from system DLL files and redistribute them with your application. Don't do this.
Also, before deciding on which icon you should display in your message box, be sure to consult Microsoft's Windows User Experience Interaction Guidelines, which provide some very handy rules on selecting the proper icon to convey the right message and fit with the Windows tone. I provide more information on that in my answer here; very much recommended reading for any Windows application developer.
Edit: It's like pulling teeth to get any more details on this question. I'm not sure why you're so secretive about what you're trying to accomplish, but note that in the future, you'll have a lot better luck including these things in your question to start with, rather than hoping people will pull it out of you. Most people aren't nearly as persistent as I am.
Anyway, you finally mention that you're doing some type of interop between VB 6 code and .NET code. That should not be relevant in the case of the message box icons used. The VB 6 MsgBox function is 100% equivalent to the Win32 API MessageBox function and the .NET MessageBox class that I discussed earlier. All of them are going to use the current system icons, and it shouldn't require any extra work to make them look the same. Ensure that you've passed the same icon specifier to all of the functions. Here's a table for convenience:
VB 6 "MsgBox" Icon Constant | VB.NET "MessageBox" Icon Identifier
---------------------------------------------------------------------------------
vbCritical | MessageBoxIcon.Error
vbQuestion | MessageBoxIcon.Question (DEPRECATED -- do not use)
vbExclamation | MessageBoxIcon.Warning
vbInformation | MessageBoxIcon.Information
Note that the "Question" style icon has since been deprecated and you should not use this value. If you're still using it in the VB 6 code, you should change that code to use a different icon (or no icon at all). The above-linked Windows User Experience Interaction Guidelines provide more details on why this icon has been deprecated and how to choose a suitable replacement.
I'm working on an VB6 app and I'd like to get rid of the old Sheridan controls and replace them with built in VB6 controls.
However, some of those controls have some nice properties, like the ForeGround on the ssCommand button. The standard VB6 command button doesn't have a foreground property.
I know that VB6 potentially has lots of other controls that I can enable but I'm not clear on which ones are fairly "standard" (i.e., not third party controls). I'd like to keep this app as plain vanilla as possible and not create dependencies. (Yes, I know that any components for VB6 have long sense become abandonware. I just anticipate a higher level of compatibility from a built in VB6 control since it was probably used more and thus "pounded on" more and it's flaws would be more known.
Any suggestions?
In my opinion threed32.ocx (the Sheridan SSControls) should be dropped because it has a number of problems. It's no longer supported, all the controls grab the focus when made visible including panels and frames (!), it's hard to upgrade to VB.NET - there are more. For my company these are strong enough to outweigh the extra functionality it gives - we're droppping it from all our programs.
Some of the discussion is too pessimistic IMHO. VB6 is not abandonware yet - we're not all doomed - though no doubt we will have to upgrade the code one day. Microsoft say:
The VB6 runtime is supported for the
full lifetime of Windows Vista,
Windows Server 2008 and Windows
7, which is five years of mainstream
support followed by five years of
extended support.
Microsoft are still supporting a number of their VB6 controls. Check the online list and only use the controls that they do support. These are the standard, tested, supported controls Clay is looking for in the original question. If you want to use third-party components, check whether they are still supported by the vendor. I would agree that you should always think hard about how much benefit you're getting before you introduce dependencies, which can be a support headache. If you use special components, try to wrap them in an abstraction layer. It might save some pain later if you need to replace them. You can hide all the fancy features except the ones you really need.
A final word - don't use the ForeColor property in the SSCommand. There's no corresponding BackColor property, so you have no guarantee that your special foreground colour will contrast with the system background "button face" colour. Just like Raymond says.
Sometimes a little ingenuity will go a long way. For instance, I wanted my VB6 command buttons to have custom background and foreground colors even though that violates the 'Windows standard look'; however, I wasn't ready to put out lots of bucks for that functionality since my projects are not commercial. So I tried a few things and finally settled on what, for me, is a very workable solution: I overlaid my buttons with label controls and now have multi-colored buttons that look absolutely authentic. I can control the button colors programatically to reflect various states of operation even going beyond a simple 'click / no-click' combination. One of my applications uses a group of five buttons which assume various colors depending on the combined button values.
I think keeping an app as 'plain vanilla' is a worthwhile goal. Certainly simplifies deployment.
I'd say the best way to find standard components for VB6 is to install VB6 (plus service packs) on a clean machine. All available components will be standard.
If you're unable to do this, for each checked Component or Reference in your project, research the file (dll, ocx, etc) referenced.
In this scenario, you're in for an uphill battle. Trying to eliminate dependencies on long-dead components is probably a good idea, but in a case like this, you're already on an abandoned technology. It's clear to me that rebuilding the app in more modern technology (EG, .NET) is not viable, so that leaves you with a limited set of options.
Replace the Sheridan controls with the existing VB6 controls which are a closest match, then update the code accordingly. This will be an intricate, difficult process, and you are correct in assuming that in many cases there won't be a match -- Sheridan (now Infragistics) built their business by providing UI capabilities which weren't in-box on VB6. In many cases, your UI will have to be seriously adapted to support this.
Consider writing "good enough" versions of the controls in VB6 yourself, or even .NET (the latter using advice from this StackOverflow question).
Consider replacing those controls with (likely long-since abandoned) open source VB6 controls. Google will be your friend here. The reason I recommend this route is that many UI elements have been represented in ActiveX over the years, as open source -- and if they're open source, you can at least "support yourself" on them.
I know you're going for a plain-vanilla out-of-box VB6 deployment, but for some UI elements, that may not be feasible. If you can rebuild your UI to #1 specs, then go for it, but you may have so much work cut out for you there that it might be time to consider going for the gusto and rebuilding on a modern, supported platform.
I've been through this, and you'll be long at it, and IMHO not very happy with the results.
VB6 can't be a long term solution anyway. Why not leave them in there? Yes they're abandoned, but I used them and never needed support anyway. (Plus it went to hell after the first time they were bought.) My experience was that they are pretty darn reliable. I'd just go with it, and if you have spot problems, provide spot workarounds.
I have to disagree with your reasoning. One might expect better support from someone whose living depends on you being a happy customer.
It's also likely to be the case that any vendor depending on VB6 sales is likely so go broke soon.
Why bother? If your product works then don't worry about it. I have found the Sheridan controls to be quite solid. If you're not experiencing any issues with them then leave them alone.
From a desktop application developer point of view, is there any difference between developing for Windows XP and developing for Windows Vista?
User Interface
Looking at the Windows Vista User Experience Guidelines you can see that they have changed many UI elements, which you should be aware of. Some major things to take note of:
Larger icons
New font (Which affects some custom UI constistency)
New dialog box features (task dialogs)
Altered common dialogs (like File Open, Save As, etc.)
Dialog text style and tone, and look and feel
New Aero Wizards
Redesigned toolbars
Better notification UI
New recommended method of including a search control
Glass
64-bit
Vista has a 64-bit edition, and although XP did too, your users are more likely to use Vista 64 than XP 64. Now you have to deal with:
Registry virtualization
Registry redirection (Wow6432Node)
Registry reflection
Digital signatures for kernel modules
MSI installers have new properties to deal with
UAC
User Account Control vastly affects the default permissions that your application has when interacting with the OS.
How UAC works and affects your application (also see the requirements doc)
Installers have to deal with UAC
New APIs
There are new APIs which are targeted at either new methods of application construction or allowing new functionality:
Cryptography API: Next Generation (CNG)
Extensible Application Markup Language (XAML)
Windows Communication Foundation (WCF)
Windows Workflow Foundation (WF)
And many more smaller ones
Installers
Because installations can only use common runtimes they install after a transaction has completed, custom actions will fail if your custom action dll requires the Visual C++ runtimes above the VS 2005 CRT (non-SP1).
Do not ever assume your user has access to certain key areas of the disc (i.e. program files, windows directory etc). Instead the default user account will only be able to write to a small section of their application data. Also, they won't be able to write to global areas of the registry - only the current user section.
You can of course elevate their privileges, but that in itself is a task.
Generally programming for Vista is the same as XP, it's just the new account restrictions you have to be wary of.
Have a look at this page with regards to making your application "UAC aware"
http://www.codeproject.com/KB/vista-security/MakingAppsUACAware.aspx
There can be, but that's a conscious choice you make as the developer. You can use new Vista stuff, like UAC and CommandLinks and Aero and so forth. But you don't have to (even UAC can be programmed around -- just don't do anything that needs admin privileges). If you choose to ignore all of the Vista stuff, then there's absolutely no difference between the two.
If you do want to include that stuff in your app, it makes a difference. But I'd say not a huge one. And if you abstract away the differences (for example, write your own function that shows a TaskDialog for Vista, but which dumbs down the input you give it into a MesssageBox on XP), then you'll only be writing against your own code, and the differences will seem like almost nothing.
Also, a lot of Vista's new stuff (for example, UAC or Aero) is stuff that you worry about once, when you create the first piece of functionality that uses it, get it working, and then never think about again while you're developing the app.
By far the most painful part of moving an application from XP to Vista (from my point of view) is dealing with the numerous services and IPv6 stuff that uses ports which were previously free, and dealing with the Wireless Provisioning -> Native WiFi transition.
The UAC stuff is basically a moot point; there is very little the application developer needs to do.