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.
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
So I've recently been looking into the Control Panel, to try to see how I might be able to create a custom applet for it, like sometimes you get a custom one when you use a printer, and I just can't seem to figure out how to make one. I've tried opening one of them in a code editing software, and assume that they are compiled as all I get is a bunch of random characters, but I'm not quite sure whether it is or not. I've looked for anything related to it, but the closest thing to an answer I have is something about trying to make the applet show up, but it doesn't say how it's made, so its not really useful.
Thanks in advance.
There are two types of control panel applets:
.Exe files. These are normal applications and can be written in any language.
.Cpl files. These are actually normal .DLL files and can be written in anything that can produce a PE DLL with a named exported function (C/C++, Delphi or if you must, C#).
Support for .Exe applets started in Vista and is now the preferred method according to Microsoft.
I've been trying to search for ways to change the way windows controls look.
For instance change the OpenFileDialog UI at a windows level, or completely turn the file copy/delete/move dialog into something else, like a series of disks or a bucket filling up with liquid.
Looking around i found that i could write a com app that could be used instead of the default windows ones. But i have no idea where or how to start with these, or even how i could see what i would have to implement to achieve this, nor how i would be able to tell windows to use my custom ones instead of the default ones.
Have tried looking in the microsoft documentation, and i'm 99% sure i'm either unable to search for what i need or it's undocumented.
I know there are some apps from Stardock that could do this where i could just make the graphics, but where's the fun in that?
Anybody able to point me in the right direction?
Interested only in being able to achieve this for windows 10.
You could in theory write your own implementations of IFileOpenDialog and IFileSaveDialog and overwrite the Windows registrations in HKCR\CLSID. This might not affect older applications that use the older open/save common dialogs.
There is also CLSID_ProgressDialog and some progress related interfaces you could take over but I don't know if Explorer actually uses these or its own custom version.
This could obviously break your system so you really have to know what you are doing if you go down this path.
While you are developing this you could choose to selectivity inject into a limited set of processes and hook CoCreateInstance instead.
Changes to existing dialogs (adding/moving/hiding controls and images) can be done with Resource Hacker. This was pretty easy in the 90's but it is more problematic these days because some files are protected and Windows updates are more common.
For some time I've noticed how much the File Open and File save dialogs vary between Windows itself and Applications. In Delphi for example (which I use) you can use the built-in dialogs (which have a folder tree) and direct calls to the Windows API which produce variants of the Windows version, with or without large buttons for 'Desktop', 'My Computer' etc (At least on XP).
As an application developer I'm interested in providing the User with a clean, simple way of loading and saving files. Typically, this requires that I propose a preferred folder where my Application data files are stored but that I allow the User to access other folders - often the desktop and other local drives, and sometimes the network - without difficulty if required.
With the introduction of Vista, we seem to be favouring a 'bits missing' folder navigation tree for Windows dialogs and now, Windows 7 has another 'line-less tree' for navigation. I suspect that if one conforms to Microsofts assumptions and stores everything in ~/documents it's not a big problem. However, if one has to start at the root of a drives tree and there are many directories then it's a right pain - there is no horizontal scrolling so directory names get truncated.
My question is - what do other Application developers use? I wonder whether I should be following this Windows lead or simply sticking to a simple cut-down version of File dialogs over which I full control but risk falling into the past....?
Thanks
Brian
Always use the OS defaults - it'll be what your users are used to, and what they expect. Whatever you do, don't astonish the user. Whatever you do, please don't write your own file-open/file-save dialog.
FWIW, I'm not a great fan of Vista's file-open dialog (why do I have to work so hard to navigate my folders?), but I'd rather that than have to get to grips with something new. The less things your users have to learn, the easier your product is to use.
Since I am currently only coding for customers with Windows XP (in a corporate environment that isn't upgrading just yet) I use the standard dialog boxes.
When we do upgrade, I will most likely continue to use the standard old fashioned dialog boxes, until our customers are ready for a change.
In all honesty, I involve at least a few users in the development process, and I won't start new features unless I can bring one in to sit in front of my development PC to see how it works, and they sign off on it.
For those apps that we write for our web site, we tend to be conservative as well... Focus on clean, understandable design, and introduce fancy new features only when there is a compelling reason, and even then, we tend to involve focus groups.
So all that was a long way of saying "Ask your customers". Give them what they want.
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.