We are developing an ASP.NET application. We retained an outside UI design firm, and for the most part have been very pleased with their work. Their "deliverable" to us was clickable screens -- Visual Studio solutions with ASPX files, images, master pages, etc. The screens were not connected to any data source. They had dummy data so that we could see how the UI worked.
One problem we've run into is that our developers are used to using Visual Studio design mode. The pages we receive from the UI firm have problems sometimes when we pull them up into design mode. The consultant's developers coded these screens without using design mode.
We assumed they'd be using design mode, but this wasn't specified in the contract. Was this too much to assume? Is there a lot of ASP.NET development work that never goes through VS design mode?
Third party edit:
Suggestion: people responding to this question should specify which
version of Visual Studio they're
using, as Microsoft trashed the code
base that was in the VS2005 and
earlier designers, and replaced it
with the one they purchased when they
purchased the Expression products. The
two are totally unrelated, and the new
one is far better. - John
Saunders
The more and more you work with Visual Studio, the less and less you rely on Design Mode. Complicated UIs tend to make the design view look atrocious.
I (and peers) never use Design Mode, for two reasons:
I learnt in VS 2003 not to touch Design Mode because your HTML was managled by VS. (Not anymore though since 2008, but once bitten ...)
It can take ages to render.
Much quicker to drag-drop from toolbox and hand-code.
I actually find that ASP.NET developers that do use the designer to be quite rare. The Visual Studio designer is notoriously bad at generating clean markup.
I never use design mode, probably because it used to mess my markup so much. Plus I do a lot of dynamic rendering, so there is no point. And I use exclusively CSS for formatting, I don't want VS messing around.
Many never use it, because of bad past experiences. I have found little trouble with Design mode in VS2008, when using modern controls, which are up to date and have good designer support.
On the other hand, because of the earlier problems, a lot of custom server controls do not have good designer support, so are much less useful in design mode now that the earlier designer code base has been replaced with a good one.
I almost never use design mode. It typically creates ugly HTML, and call me anal, but I really like to have clean HTML. If that means hand-coding it, so be it.
I prefer doing it manually, I like to have control.
If I want to look at the result, F5.
I almost never use design mode. For me, the biggest reason is because I learned web design/development in Notepad, so I was used to (and comfortable) working with code. Design mode makes me uncomfortable because I'm never sure exactly what decisions VS will make with regard to HTML, etc. Additionally, I can't imagine that a developer would learn nearly as much about ASP.NET and VB/C# using design mode.
The only time I use design mode is to automatically configure a GridView or something like that like.
Design Mode is taking quite a beating here, but let me point out that it is great for learning about new controls. When you are new to ASP.NET, or are using a new library of controls, Design Mode is a godsend for two reasons:
You can modify properties on the Property Editor and see them reflected immediately. This is particularly true for list-container type controls, where the entire layout may depend on one property. Running your application five times to see all five layouts is very tedious.
Controls with complex behavior (and lets face it, thats why you're using a control, right?) often have a lot of configuration built into their Smart Tags. Notice the little [>] arrow in the top right of the control? Click it. It'll probably help you out big time. This is particularly true for configuring DataSources, whose syntax is very meticulous.
When I was first learning to use Telerik controls, I relied heavily on the Smart Tags they provide, which are very robust and complete. From that, you can see what kind of ASPX markup is generated and learn to work outside of Design Mode. I am a learn-by-doing kind of guy, so I much prefer this approach to looking at the documentation when using something for the first time.
I'm using VS2008, and I never use the design view. I find the code view to just be easier and more responsive than the designer.
Y'know, I never even realised I use the source screens 100% of the time. I usually develop in VS2005.
Whenever I do actually open the design mode, it's by accident, and I try and hit the source view before it renders. I've never been impressed with the design mode, and find it slow as well as adding a lot of unnecessary markup. I also find that intellisense and the properties window mean that I don't need a GUI to develop.
The design mode can also be a nightmare when you're trying to add any nested items. Because we've been developing for a customer using IE6 we've been using tables for formatting so we don't need different DIV definitions. Just clicking in an empty cell can be difficult, and resizing a column can take far too long.
For things like Template Fields in grids, I don't even know how I'd go about setting this up in design view!
Having said that, design mode every time for windows apps!
Design mode is getting better and I'd say that it's likely to become more prevalent as time goes on and the design mode tools continue to improve. I design all my components for design mode, but I still do the large majority of my code by hand - it allows greater control of code layout and doesn't end up creating an auto-formatted mess that I then have to dig through to figure out what changes need making. I know that in future my components are likely going to be used by developers that do most of their design by drag/drop and it's easier to cater for that now than have to come back and do it after the event.
Granted I'm doing MVC stuff, but I never use it - I "grew up" with PHP and code editors, and it still does me just fine.
I'm using two different versions of .NET (2003 & 2005). Some of the forms that were written in 2003 can no longer be edited in 2003 and the installation requires that they be maintained in 2003, so I use KEDIT to edit those forms.
Some of the forms in one application are too big for the .NET editor and I prefer a strong editor anyway.
I have no problem working in design mode. One exception is asp:Repeaters, which are not supported, or GridViews which tend to override my manual column definitions.
The other is if VS tries to do a full project scan if I rename a control, and then fails.
We primarily use the code view. The design mode is quite buggy we've found in VS 2008. XML controls tend to barf random character sets out for some reason, and VS will generally run slow whilst trying to render everything on screen. I mainly use the code-view.
Traditionally WYSIWYG designers produced poor code and render CSS and #INCLUDEd files poorly so they were of limited use, so developers tended to code by hand. In addition, these tools allowed you to go a certain distance without real knowledge of what you were doing, which was fine for web tutorials and personal homepages, but as soon as you wanted an extra degree of control you became unstuck - when meant you had to resort to looking 'under the hood' anyway.
Although tools have improved over time, many developers are so comfortable with hand-coding that they all but forget about the Design View - I certainly can't remember last time I used it. I'm sure there are a number of situations where such tools could be genuinely useful, but we are doing fine without and don't want to be bothered with figuring when & where such features can best be used.
Our UI is complicated and it is impossible for us to use design mode with VS2005.
The only time I have touched design mode is to do a quick and dirty prototype or an internal app.
How often do I not use design mode? 99% of the time.
Related
There are many applications for Windows these days that don't use native windows controls, don't have standard window frames and generally look different. What are some recommended techniques for creating such interfaces?
There are good reasons not to. Like that you will most likely not do a better job than Windows does. (Maybe it will look better (in your opinion), but will it behave?). Or that it's not what most users expect. Or that it will look like s**** on Windows 2011.
That said, it's not hard. You simply handle the WM_NC* events like WM_NCPAINT or WM_NCHITTEST. NC stands for Non Client (window area). And of course, there is a trick on Vista/Win7 (you have to announce it to the DWM).
From an implementation aspect, you could employ WPF (Windows Presentation Foundation) assuming you code for .NET :) It has pretty bunch of skinnable controls, that may look like native and may not.
From a design aspect, if your interface isn't going to follow documented standards (like the Windows UI guidelines), it has to be intuitive. I think the new generation of Windows applications will go through a growing phase in a manner similar to the early days of the Web. After a time, some standards or common themes will evolve.
Can you give us some sample applications? Some apps that don't use native windows controls use cross-platform GUI libraries, like Qt for C++ or Tkinker. These maintain the same look across different platforms.
I wouldn't really recommend making your user interface different deliberately. You don't stand to gain much. Your controls are almost always going to be buggier than native controls, and you are requiring the user to learn something new. Now, if you're controls add a large enough value to be worth the users' time it can be okay. But making them get used to different looking buttons is rarely worth it.
I`m not sure if this answer your question.
You can use third party skinning controls like from Infragistics, or SkinSoft for example.
But like Bubba said I`d recommend going for WPF.
Model-View-Controller! It's as valuable here as in web apps or anywhere else. Be sure to keep the part of your program that generates the custom UI separate from the part of your program that flashes the BIOS.
I know this question is 10 years old but none of the answers mention using an option in visual studio, dont know if it existed at the time.
Theres an option to remove the border of the window in visual studio (called borderStyle). Thats the easiest way to do it, using C#. After removing the border, all you have to do is create a new interface. If you're looking to do it in C++, i think you need to use DWM. I will let an example i found here.
https://github.com/melak47/BorderlessWindow
Another example (maybe without DWM? didnt test):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b98c4c06-9581-44d3-8e5a-4adb2316e653/win32-about-styles-how-can-i-do-a-borderless-window?forum=vclanguage
There is a lot of people disencouraging to do it in this thread but there's no reason to not do it, if you know what you're doing your application can look great.
I have been playing around with php-gtk recently and in the past I have experimented with Java to make GUI 'hello world' apps.
However both these types of applications have had a bit of a clunky (almost childish) look and feel to them. I cannot deny that they are handy for making apps for in-house use (and I totally respect the amount of community effort that goes into these projects). But I would not necessarily be proud to sell it as a commercial application with a price tag of, say, £450 or £1,000.
If I wanted to make an application that had the look and feel of, say, Firefox for Windows, or Adobe xyz, what GUI/language should I use?
Is the 'professional sheen' or smart look and feel 100% down to the designers or is it the case that, no matter how good a designer is, picking the right GUI framework is essential to get that look?
There are a few aspects to having a polished UX for a piece of software.
Using the most native framework for the platform. Win32/WPF for Windows, Cocoa for Mac etc.
Application's visual artefacts are coherent - this includes images, graphics, toolbar icons etc.
Following the platforms guidelines and best practices.
It's overlapping a bit with Igor's reply, but here's my take:
Native Control Look - UI controls today have a rather complex appearance. There are many visual cues we instinctively derive from them, and even if it's a white rectangle with some frame, with the wong shadow it looks strangely out of place. A context menu often doesn't just open today, it slides in from some direction, or fades in.
Native Control Behavior - Even more complex than UI, there's a lot of detail to behavior: different context menus depending on click position, different "hot" areas when selecting or dragging items, keyboard shortcuts, etc.
Attention to detail - There's a lot of consistent UI behavior to discover on any platform. Just the way arrow keys work in a tree control WRT selecting, opening and closing nodes.
Just look at Windows: Most non-native toolkits get the basic keyboard navigation wrong - Arrow keys, Home, End, PgUp and PgDown, behavior modified with Ctrl, extending selection with Shift gives up to 32 behaviors. Copy & Paste is traditionally with Ctrl+C/Ctrl+X/Ctrl+V and Shift+INS,Shift+DEL, and missing. Mouse double click often selects a word, mouse triple click sometimes a sentence, line or paragraph.
Response time and Muscle Memory - There are, basically, two UI operation modes:
act-look loop, where you wait for the response before deciding the next step,
playback from muscle memory, which is much faster and requires less mental processing ressources.
There are, however, two requirements for that: response must be uniform and "instant", and the next action must be registered correctly immediately (at least within 10 ms)
Often enough, with non-native toolkits, this gets hard by the response lagging behind one or two actions (the mind locks on the discrepancy), and by toolkits that take 50ms or more to show a menu, in which time a click isn't registered as intended.
A polished UI takes long to get right - A good control library can solve most of the per-control issues, but there's some final 10% taking 90% of the time, and you have control interactions. You have to try different approaches, you have to expect users with FPS-trained reflexes, you have to try all kinds of workflows.
Cross-Platform toolkits can't get it perfectly right - they are stuck between a rock and a hard place: They can opt for internal consistency independent of the platform, or being consistent with platform they currently run on. To get it right, the latter often requires platform-dependent code in the calling code, the actual thing you are trying to avoid.
Always try to use the GUI framework that's used by your desktop environment. .NET's libraries are probably the best for creating Windows apps. GTK+ is always the best on GNOME, while Qt works well on KDE - even though all three work on each other's systems, their visual appeal decreases with their lack of visual integration.
The GUI API/language used is utterly irrelevant to UI design, although some APIs make it easier or fasterto implement.
Good UI is about:
Good graphic design/artwork (visual balance and symmetry, complementary colours, visually 'pleasing' shapes and layouts, visual consistency within your app and with the other apps around it - consistent positioning, sizes, gaps, colours, etc)
Understanding the user's workflows and making what they want to do easy and intuitive. This often means implementing 3 or 4 ways of achieving the same action (e.g. "Copy and paste" can usually be achieved by: main-menu->copy/paste, context-menu->copy/paste, ctrl+c/v, button:copy/paste, drag-and-drop)
Keeping everything simple. Remove as much as possible to cut the UI back to just what the user needs and no more.
Being intuitive and not surprising the user. Controls should look like the controls the user knows, work like the controls the user knows, and be located in the places a user expects given their previous experience with the computer.
Following the conventions (position OK/Cancel buttons in the standard locations, use the OS-defined colours for highlighting selected objects etc)
To get this, you need to look at lots of "good" applications and dissect what makes them good. Get a good artist/graphic designer to draw you good icons etc. And spend a lot of time thinking about the user's workflows.
Make sure you separate the business logic from the UI - this will allow you to re-skin the app easily to improve the UI. And usually the data the program needs is not related to the way the user needs to use the application - don't be tempted to just expose your x,y,z variables in editable fields! UI is the layer that hides your implementation and makes it usable!
I don't care for the way Java application GUIs tend to look using the usual toolkits. If you like the way Firefox looks, you might look into XUL and the GUI framework shared by most Mozilla applications. Komodo Editor/IDE use the same tools (along with several other applications). GTK is very powerful, and I really doubt it is what is preventing your applications from having that professional sheen. Keep exploring it's features, and rethinking the best way to display your components, and I'm sure you'll stumble upon an arrangement that feels better.
On the other hand, it isn't all about the toolkit. Good interface design is an art, and interfaces like Firefox have evolved through endless amounts of feedback. The best thing to do is talk to users and find out what will make them more comfortable using your application. I've found that software tends to look good when it is also functional.
I would recommend spending a lot of time in software that you find pleasant to use. Make notes of the way things are done, and look for commonalities among interface elements. Most software sticks to a pretty common set of principles that make using the software easier, and the more you explore the software you find appealing, the sooner patterns will start to emerge.
Good luck!
We are currently an Infragistics NetAdvantage Select customer and have been for a few years. Their controls are ok but not what I would call great but the time invested in learning them to date is the main reason we stick with them. We use both ASP.NET and Winnform controls.
As we are due to renew, we are considering DevExpress as an option as they seem to offer much of the same functionality.
For anyone that has made this move fro mInfragistics to DevExpress, how have you found it? A step forward or back? Pros and Cons to doing so?
My company is using DevExpress and we are very satisfied with their suite. We have never used the Infragistics suite, so I can't talk about the process to switch from Infragistics to DevExpress.
Generally, I find the DevExpress controls very easy to use and implement in our applications. Some controls have a small learning curve like the DevExpress TreeList but it is not a huge issue.
One thing I dont like with some of their controls is the property "Properties". This property is used to set additional options to the control.
Per example to set the max length of a textedit (textbox of devexpress) :
textEdit.Properties.MaxLength instead of textEdit.MaxLength
So, their controls are great and have a great look but I think the main quality of DevExpress is their support. You can ask a question on the support page and you will receive a answer within one day, maybe two days if the question is complex.
So, if you are not statisfied with Infragistics, try DevExpress. You can download a trial version so you have nothing to lose.
I will second that you should give Telerik a look. Their support is top notch in the industry. They give you good real world examples and their documention I feel is second to none.
I took on a contract with a company entrenched in the controls you're considering and I wouldn't use them if they were free.
The reasons I make this statement is their documentation in my opinion was bad. When I spend money on a RAD type control suite, it's to make my work easier and faster to production. I found in some cases it was easier to just figure out how to make built-in controls do what you want versus trying to figure out the problems I was having with their controls.
Their samples are kind of like Microsoft samples used to be. They are fluff based for Tech sales to show at a seminar "how easy something is to setup" but in real world if you used the techniques and monitored viewstate and traffic their examples generated, you'd be less than impressed.
I didn't have an account to submit support tickets but I had 4 over the course of a month submitted through the account holder and to my knowledge didn't get an answer back on any of them. (That could have been a break down with the person I had to go through but I doubt it.)
When it comes to Telerik's, Rad controls for Ajax, very seldom I can't figure out what I need to do by either looking at the sample Visual Studio sample web solution that get's installed combined with their documentation.
Good luck in your search and even if you don't consider Telerik, I would strongly suggest you look for other options.
Slightly unrelated but you might also want to evaluate the Telerik controls. We have been using them for years. Exceptional controls and support. And their controls work with ASP.NET MVC as well.
Just a happy customer here.
Not related to controls, but with DevExpress suite you get superb VS addins for free - CodeRush and RefactorPro.
Like Francis, I haven't made the move from infragistics to devexpress, I started with devexpress. I can speak to the learning curve. Depending on the controls you're going to use, and how you intend to use them, there can be very little learning curve.
The data manipulation controls (xtragrid, xtrascheduler, xtracharts, etc.) are extremely easy to use when binding to a database. Less so when binding to persistent objects. Their XPO, oddly enough, isn't as easy/intuitive as it could or should be when databinding though also not incredibly hard.
The major benefit for me was documentation. Their documentation site as well as their tutorial videos are top notch and really get to the point without using trivial, nor overly-complex examples.
As Francis said, the response time on tickets, and the (usual) clarity and detail of the replies - they often include small projects showing what you're supposed to do, or will alter your project that you submit with a ticket - is second to none imo.
Moving from Infragistics to Devexpress is tough! I have been using Infragistics for past 2 years as a Windows and a Web developer and now I am using Devexpress at a different place.
It is slightly difficult for the developer to use the Devexpress control due to its versatile properties. If you take a example of grid in DevExpress (in case of Windows) there are 2 parts:
The main display part and
The view part so you can manage them during the binding
On the other hand there was no such thing in Infragistics, so it was plain and simple to use.
Similarly there are lot of such difference between Infragistics and Devexpress controls.
Now What I feel is if you are interested in having some complex functionality with lot of tedious logic then Devexpress is good for you! Or if you want to keep the things simple with decent functionality then Infragistics is good for you.
So as you know it is very difficult to tell which one of these is really superior - we have to choose them based on our own requirements.
Stick to Developers Express. They have much better upgrade path and almost all breaking changes are in written.
I have been using them since 2003 and still ahven't found a better match.
I migrated from Infragistics to DevExpress. Will never go back to Infragistics as their objects are much heavier and performance is not too great. Documentation is terrible and their examples are very juevenile. Infragistics data grid inline editing (Excel like) is a nice feature which is not available in DevExpress. Other than that, data grid, master, detail setup, data grid dropdown list declaration and other feature are much more streamlined in DevExpress.
I have been using Telerik RAD Controls since several years. I am very satisfied with the ASP.NET Ajax and WinForms controls. I have not used DevExpress or Infragistics controls before but I had a look at both when I took the decision to use Telerik.
This is probably too late, but as I found this post while asking the same question I thought I would add my comment with respect to Telerik. I have previously used Infragistics, which I found OK, but I thought the performance wasn't great. Recently I worked a contract with a company who were using Telerik for Winforms and what we discovered was that there were a number of bugs in their controls. There support was great and they were quick to respond to questions or comments, but unfortunately most of the time when we raised a question on why something wasn't working, the answer was that it was a bug in their control. also their documentation states explicitly that their controls are not intended to be inherited, so while building your own custom control off the top of their control seems to work in most cases, it isn't recommended.
There are many more technologies and tools available to build the front end for an application.
Which is the best technology/tool/platform available using which I can build a better GUI, by which I'll be able to build a nice looking as well as an efficient GUI?
Definition of "better" includes factors such as efficiency,user friendliness,better content control mechanism, navigation and many more.
I know this is a question about which GUI toolkit you should use, but your first technology for producing a user-friendly UI is pen and paper. Sketch out some mock-ups. Draw buttons and menus on construction paper, cut them out, and glue them together. Then try your mockups on about a half-dozen people. You'll quickly find out what makes a good UI.
It doesn't matter how good the UI looks or whether it uses the latest snazzy effects -- if your users can't figure out how to use it, they'll go elsewhere. You need to learn what works for your target audience before you write a single line of code.
Read Don't Make Me Think to learn how to make mock-ups and do user testing.
If' you're tracking an IP address, you'll definitely want to create your GUI Interface in Visual Basic.
Use the .NET framework in Visual Studio 2005/2008/2010 Studio. I haven't developed in any other environment, but I have been able to create nice looking apps in this IDE / Framework.
"Best" depends on what your evaluation function is.
For ease of development, and high quality UI, in a non-web based app it's hard to beat C#/VB or any other .NET language and environment for a windows-based app. Depending on the quality of the UI, MPF will give you greater flexibility and control, whereas windows form will make it easier to develop.
Having used Windows Presentation Foundation for a while now i would highly recommend it. There is a pretty big learning curve and, to be honest, MSFT should have included some controls (the datagrid being the biggest one) that were not included by default (but will be in .NET 4.0). Where WPF and XAML exceed is providing a foundation from which you can build just about anything. You can style ANY part of ANY control and build your own composite controls from scratch. A lot of thought went into binding and value converters and once you get used to the declarative nature of XAML you wont want to turn back. The company I work for has been using it for a couple of years now and the difference between the GUIs we used to develop (mainly winforms and asp.net) and what we develop now are night and day in terms of both look-and-feel and functionality. My two cents anyway...
It depends.
What device will the GUI be used on, hand held, PC, Mac?
What platform Windows, Linux, Web?
What kind of application will it be, accounting, email client, web application?
What audience will be using the application (a GUI aimed at a child may be different than one aimed at an adult)?
All of these things must be taken into account before even starting to formulate an answer to your question.
You have several choices for developing a GUI.
first, if cross platform is an issue consider using Java or Python.
you can also use Adobe AIR and develop the gui in Flex.
If you direct the product to windows only users .NET WPF is the best solution, with a very rich set of control and examples.
You can also use .NET with mono for cross platform compatibility, but WPF isn't currently supported.
Desktop, Mobile, Windows, Linux, Database, OpenGL: Nokia Qt. Wiht Python - PyQt development process is shortest and easy. Application containing all required python & qt libraries and modules is around 30MB with Inno Setup installation is 8MB and will work on Windows 2000 and newer for Python 2.6.x, Python 2.5.x based application will run from Windows 95 to Windows 7.
I think all the attributes you list -- efficiency, user friendliness, etc -- are attributes of a good design rather than a good toolkit. Just about any toolkit can be used to meet those goals. I think the question might be different if you were asking about eye candy, fancy multi-media, etc. There are definitely some toolkits that do that better than others.
If you're interested in usability first (and it sounds like you are), focus on the design then pick whatever toolkit meets your current abilities and can handle your design. For example, if you require 3D images that might narrow your choices; likewise if you need to show videos, that will influence which toolkits you can choose from.
So, start with a good design. From that, create a list of requires for the toolkit -- rich editing controls, video, 3D, etc. And then look for a toolkit that provides what you need.
The best toolkit in the world won't make up for poor design.
Personally after having used Win32, Forms and WPF then going to Mac/iPhone GUI development, I very much prefer the flexibility and high quality of visuals in the Mac/iPhone GUI.
One of the most useful examples is the fact that in NSTable/UITable controls (ListViews or similar in Windows), every cell is a fully customisable View (a Control in Windows).
Where in a ListView you have very little customisation for each cell/item in the view since you only provide details, not an actual control, an NSTable/UITable asks you for a table cell which you can add anything to, such as buttons, switches and image views.
Mac OS GUI development to me is a LOT more flexible and more consistently flexible in that regard. Everything is a View so I can my own contents to anything.
Have you considered Silverlight?
It can be used to create internet applications, but it can also be run out of browser to create desktop applications. It's has significant overlap with WPF though there are differences which might catch you out when swapping from one to the other.
Expression Blend 3 is a very good visual designer and the code it produces is quite efficient.
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.