my backgrounds are C/python/pyqt, and I was forced to use MFC for GUI programming(by my boss, in the consideration that he can assign this job to others in the future). and I encountered this problems:
how to create a tab control (found one solution on internet)
how to create a table view
how to use json, sqlite or other third party library
how to embed a web browser
how to draw plot by using double buffer
how to do exception/assert/unittest/profile/
So is there a book or site collect stuff in this subjects?
The website with most MFC stuff is www.codeproject.com.
Books on MFC are a bit thin on the ground these days. The standard work was by Jeff Prosise (Programming Windows with MFC, or Programming Windows 95 with MFC according to what issue you got) but that's out of print. Amazon has second hand copies for sale.
The answer to your questions tends to vary whether you're using Documents and Views or dialog based applications. I suspect the easiest way to do a tab control would be to put a tab into a dialog resource and create a CFormView. Same with a web browser, though the browser controls that shipped with MFC were a bit primitive, last time I checked (that was a few years ago though). The SQLite issue is addressed in this question
Related
I'm in the process of creating a silverlight app which will run in the browser and uses some data visualization stuff provided by ComponentArt. At some point I'd also like to create a a WinRT xaml/c# version so it can run as a windows store app all editions of Windows 8 including WindowsRT.
My question is how can I approach this to get maximum code-reusage between the 2 versions. I see no other way than having 2 versions (as I am tied to using componentart and can't use a html/js approach). In particular how portable will the xaml used in the silverlight app be to the windows store app?
Your XAML is as portable as the features you use. You can't reuse same XAML files since they use different namespaces and xmlns URI schemes and also you will most likely want to make the UI slightly different since Silverlight is primarily Mouse+Keyboard UI and WinRT/XAML is primarily touch.
Make sure you use MVVM to be able to reuse a lot of the non-XAML code. When selecting which controls to use - make sure they are available in WinRT/XAML or have good alternatives. Some of the missing things I saw were WriteableBitmap.Render() method, RadialGradientBrush, TypeConverterAttribute, Style/Setter bindings, TreeView, DataGrid or GridSplitter controls. Though there are open source versions of a lot of the missing controls - you will most likely want to use alternative UI design approaches for Windows Store Apps since these don't work well with touch.
For reference - I spent around 2-3 hours porting the TreeView control from Silverlight Toolkit to WinRT, around as much for the Calendar control and 20-30 hours to port the Chart control with its many kinds of data points and series - and that's on top of the original port by Mahmoud Moussa. Depending on the complexity of the features you use - the required effort will obviously grow. If you just use Buttons, TextBoxes, TextBlocks, RadioButtons, CheckBoxes etc. - you can mostly do copy&paste to port the XAML. I would also avoid retemplating the controls since template parts and visual states/visual state groups are slightly different between these platforms, so you would need to either redo the work or spend time correcting the templates.
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
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.
I was playing a bit with Windows Vista (still using XP) and I liked how the standard Control Panel worked. Do you think this design is good also for normal applications?
I like the idea of showing main topics with large fonts + icons. Details within each main topic are displayed using a small font and are immediatelly accessible without the need to browse the menu. Probably everybody knows Vista, but anyway, here is the Control Panel layout.
Compared to a classic layout of icons for main topics and menu for minor topics, the Control Panel GUI seems to be good at first sight.
I haven't seen any app using this kind of GUI, so I don't know if I should rather use the common approach with icons and menu for a common application? Maybe this Control Panel GUI is suitable only for setting some options, other than working with any data?
I think it's suitable for certain types of applications. As usual with usability related questions, "it depends". I would guess one class of application this is good for is one that you don't use very often, and/or might be used by different people at different times. It is similar in concept to a wizard in that it presents you a list of choices, and selecting a choice takes you to a new page.
Whether this sort of thing is suitable for your application, it's hard to say. The best way to answer that question is to mock up your application and do some hallway usability testing. I would guess, though, if you're thinking of using this for an application people will use a lot, this sort of interface will be annoying. If you're dealing with perpetual beginners or casual users it might be a fine way for someone to start using your program.
I'm on the fence on this. The old Windows XP layout got cluttered quickly with programs adding their own control panel applets, while the new Windows Vista layout can be annoying to process visually at first. The search feature really helps (though not nearly as slick as Mac OS X's search) but I'm not a fan of visually laying out something that's better seen in a list into two distinct columns containing the same type of data. In list/details form it's intuitive for a user to sort the items through different attributes. I find this new presentation in the IIS 7 management applet to be particularly troublesome.